Skip to content
Alien Giraffe

Channels

Channels represent where and how data is accessed in the Alien Giraffe access control model. This component manages access pathways including SQL connections, API endpoints, web interfaces, CLI tools, and application integrations. Policies reference channels in their channels: field to specify access methods and operations (read/write).

Relationship to Policies

Section titled “Relationship to Policies”

Channels are one of the five core components that policies coordinate. When you define a policy, the channels: field specifies how subjects can access resources—through SQL queries, API calls, web UIs, or other methods. This component provides the infrastructure for managing those access pathways and the applications/services that use them.

Overview

Section titled “Overview”

Modern data access happens through multiple channels: direct database connections, REST APIs, web-based interfaces, command-line tools, notebooks, and automated services. Each channel has different security requirements, authentication patterns, and operational characteristics.

Applications and services are the primary users of channels:

  • Web applications serving customer requests
  • Backend microservices processing transactions
  • ETL pipelines moving and transforming data
  • Analytics platforms generating reports
  • Third-party SaaS tools integrating with your data

Alien Giraffe provides a centralized way to register, authenticate, and authorize these channels and applications, ensuring they have appropriate access while maintaining security and auditability.

Key Benefits:

  • Centralized Registry - Inventory of all applications accessing data
  • Service Account Management - Automated credential lifecycle
  • Scope Limitation - Restrict apps to specific datasets and operations
  • Audit Trail - Track which applications access what data
  • Compliance - Meet regulatory requirements for application access

Application Types

Section titled “Application Types”

Web Applications

Section titled “Web Applications”

Frontend applications that access data via APIs:

Characteristics:

  • User-facing interfaces
  • OAuth/OIDC authentication
  • API token-based access
  • Session management
  • Rate limiting

Examples:

  • Customer portal
  • Admin dashboard
  • Internal tools
  • Mobile app backends

Backend Services

Section titled “Backend Services”

Microservices and backend systems:

Characteristics:

  • Service-to-service communication
  • Long-lived credentials or certificate-based auth
  • Direct database connections
  • High throughput
  • Low latency requirements

Examples:

  • Payment processing service
  • Order management system
  • User authentication service
  • Notification service

Data Pipelines

Section titled “Data Pipelines”

ETL jobs and data processing workflows:

Characteristics:

  • Batch processing
  • Read from multiple sources
  • Write to data warehouses
  • Scheduled execution
  • Resource-intensive

Examples:

  • Nightly data warehouse sync
  • Customer analytics pipeline
  • Log aggregation system
  • Data lake ingestion

Analytics & BI Tools

Section titled “Analytics & BI Tools”

Business intelligence and reporting platforms:

Characteristics:

  • Read-only access
  • Complex queries
  • Dashboard generation
  • Scheduled reports
  • Data visualization

Examples:

  • Looker, Tableau, PowerBI
  • Jupyter notebooks
  • Custom analytics platforms
  • Data science environments

Third-Party Integrations

Section titled “Third-Party Integrations”

External SaaS services:

Characteristics:

  • OAuth-based authentication
  • Webhook integrations
  • API rate limits
  • IP restrictions
  • Vendor-managed

Examples:

  • CRM systems (Salesforce, HubSpot)
  • Customer support (Zendesk, Intercom)
  • Monitoring (Datadog, New Relic)
  • Security (SIEM, DLP tools)

Configuration Examples

Section titled “Configuration Examples”

Web Application

Section titled “Web Application”

Register a customer-facing web application:

apiVersion: v1
kind: Application
metadata:
  name: customer-portal
  namespace: production
  description: Customer-facing web portal
  owner: frontend-team
spec:
  type: web-application


  authentication:
    method: oauth2
    provider: okta
    clientId: customer-portal-prod
    scopes:
      - data:read
      - user:profile


  access:
    sources:
      - source: production-db
        datasets: [customers, orders, support_tickets]
        permissions: [SELECT]
      - source: production-api
        endpoints: [/api/v1/users/*, /api/v1/orders/*]


  network:
    allowedOrigins:
      - https://portal.company.com
      - https://app.company.com
    corsEnabled: true


  rateLimit:
    requestsPerMinute: 1000
    burstSize: 100


  monitoring:
    enabled: true
    alerts:
      errorRate: 5%
      latencyP99: 500ms

Backend Microservice

Section titled “Backend Microservice”

Configure a backend service with database access:

apiVersion: v1
kind: Application
metadata:
  name: payment-service
  namespace: production
  description: Payment processing microservice
  owner: payments-team
spec:
  type: backend-service


  authentication:
    method: service-account
    credentials:
      secretRef: payment-service-credentials
      rotation:
        enabled: true
        period: 90d


  access:
    sources:
      - source: production-db
        datasets:
          - payments
          - transactions
          - customer_payment_methods
        permissions: [SELECT, INSERT, UPDATE]


      - source: payments-redis
        datasets: ["*"]
        permissions: [GET, SET, DELETE]


  network:
    vpcId: vpc-12345678
    subnets: [subnet-abcd1234, subnet-efgh5678]
    securityGroups: [sg-payment-service]


  resourceLimits:
    maxConnections: 50
    connectionTimeout: 30s
    queryTimeout: 10s


  audit:
    level: standard
    logQueries: true
    logDataAccess: false         # Don't log actual data due to PCI compliance

ETL Pipeline

Section titled “ETL Pipeline”

Define a data pipeline application:

apiVersion: v1
kind: Application
metadata:
  name: analytics-etl
  namespace: production
  description: Nightly analytics data pipeline
  owner: data-engineering
spec:
  type: data-pipeline


  authentication:
    method: iam-role
    awsRoleArn: arn:aws:iam::123456789012:role/AnalyticsETLRole


  access:
    sources:
      # Read from production DB
      - source: production-db-replica
        datasets: ["*"]
        permissions: [SELECT]


      # Write to data warehouse
      - source: analytics-warehouse
        datasets: [raw_data, staging, analytics]
        permissions: [SELECT, INSERT, UPDATE, DELETE, CREATE]


      # Read/write to data lake
      - source: data-lake-s3
        paths: [/raw/*, /processed/*, /analytics/*]
        permissions: [s3:GetObject, s3:PutObject, s3:ListBucket]


  schedule:
    cron: "0 2 * * *"             # Daily at 2 AM
    timezone: America/New_York
    timeout: 6h


  resources:
    cpu: "4"
    memory: 16Gi
    ephemeralStorage: 100Gi


  notifications:
    onFailure:
      - slack: "#data-engineering"
      - email: data-team@company.com
    onSuccess: false

Third-Party Integration

Section titled “Third-Party Integration”

Configure a SaaS analytics platform:

apiVersion: v1
kind: Application
metadata:
  name: looker-integration
  namespace: production
  description: Looker business intelligence platform
  owner: analytics-team
spec:
  type: third-party


  vendor:
    name: Looker
    contact: support@looker.com


  authentication:
    method: api-key
    credentials:
      secretRef: looker-api-key
      rotation:
        enabled: true
        period: 180d


  access:
    sources:
      - source: analytics-warehouse
        datasets:
          - dashboard_data
          - aggregated_metrics
          - kpi_summary
        permissions: [SELECT]


  network:
    ipAllowlist:
      - 34.120.0.0/16            # Looker IP ranges
      - 35.190.0.0/16
    requireTLS: true
    minTLSVersion: "1.2"


  dataHandling:
    allowExport: false           # Prevent data export from Looker
    allowCaching: true
    cacheTTL: 24h
    piiHandling: mask            # Mask PII in query results


  compliance:
    dataProcessingAgreement: true
    contractExpiry: 2026-12-31

Data Science Environment

Section titled “Data Science Environment”

Configure Jupyter notebooks or data science platform:

apiVersion: v1
kind: Application
metadata:
  name: data-science-notebooks
  namespace: production
  description: Jupyter notebooks for data science team
  owner: data-science
spec:
  type: analytics-platform


  authentication:
    method: oidc
    provider: okta
    groupRestriction: [data-scientists, data-analysts]


  access:
    sources:
      - source: analytics-warehouse
        datasets: ["*"]
        permissions: [SELECT]


      - source: feature-store
        datasets: ["*"]
        permissions: [SELECT, INSERT]


  environment:
    baseImage: jupyter/scipy-notebook:latest
    packages:
      - pandas
      - scikit-learn
      - matplotlib
      - seaborn


  resources:
    cpu: "2-8"                   # Burstable CPU
    memory: 8-32Gi               # Dynamic memory
    gpu: "optional"


  storage:
    workspace: 100Gi
    shared: /mnt/shared-datasets


  session:
    maxDuration: 12h
    idleTimeout: 2h

Authentication Methods

Section titled “Authentication Methods”

Service Accounts

Section titled “Service Accounts”

Dedicated credentials for applications:

Features:

  • Long-lived credentials
  • No human interaction required
  • Credential rotation
  • Scoped permissions

Implementation:

authentication:
  method: service-account
  credentials:
    username: svc-app-name
    secretRef: app-credentials    # Stored in secret manager
  rotation:
    enabled: true
    period: 90d
    notifyBefore: 7d

OAuth 2.0 / OIDC

Section titled “OAuth 2.0 / OIDC”

Standard protocol for delegated authorization:

Features:

  • User consent flows
  • Token-based access
  • Refresh tokens
  • Standard protocol

Implementation:

authentication:
  method: oauth2
  provider: okta
  clientId: app-client-id
  clientSecretRef: app-oauth-secret
  scopes: [data:read, data:write]
  redirectUris:
    - https://app.company.com/callback

IAM Roles (Cloud Provider)

Section titled “IAM Roles (Cloud Provider)”

Cloud-native identity:

Features:

  • No static credentials
  • Cloud provider managed
  • Temporary credentials
  • Least privilege

AWS Example:

authentication:
  method: iam-role
  awsRoleArn: arn:aws:iam::123456789012:role/AppRole
  externalId: unique-external-id
  sessionDuration: 3600

GCP Example:

authentication:
  method: service-account
  gcpServiceAccount: app@project.iam.gserviceaccount.com
  workloadIdentity: true

API Keys

Section titled “API Keys”

Simple key-based authentication:

Features:

  • Simple implementation
  • Easy rotation
  • Scope limitations
  • Usage tracking

Implementation:

authentication:
  method: api-key
  keyFormat: Bearer
  secretRef: app-api-key
  scopes: [read:data]
  rateLimit: 10000/hour

Certificate-Based (mTLS)

Section titled “Certificate-Based (mTLS)”

Mutual TLS authentication:

Features:

  • Strong cryptographic identity
  • No shared secrets
  • Certificate lifecycle management
  • PKI infrastructure

Implementation:

authentication:
  method: mtls
  certificate:
    secretRef: app-tls-cert
    issuer: company-internal-ca
    validityDays: 365
    autoRenew: true

Access Patterns

Section titled “Access Patterns”

Read-Only Access

Section titled “Read-Only Access”

Limit applications to read operations:

access:
  sources:
    - source: production-db
      datasets: ["*"]
      permissions: [SELECT]      # Read-only
  enforcement: strict            # Reject any write attempts

Write Access with Audit

Section titled “Write Access with Audit”

Allow writes with comprehensive logging:

access:
  sources:
    - source: production-db
      datasets: [orders, inventory]
      permissions: [SELECT, INSERT, UPDATE]
  audit:
    level: verbose
    logStatements: true
    logData: false               # Don't log actual data
    alertOn: [DELETE, DROP, TRUNCATE]

Time-Restricted Access

Section titled “Time-Restricted Access”

Limit access to specific time windows:

access:
  sources:
    - source: production-db
  schedule:
    allowed:
      - days: [monday, tuesday, wednesday, thursday, friday]
        hours: [9-17]            # Business hours only
    timezone: America/New_York

Aggregated/Masked Data Only

Section titled “Aggregated/Masked Data Only”

Restrict to pre-aggregated or anonymized data:

access:
  sources:
    - source: analytics-warehouse
      datasets:
        - aggregated_metrics     # Only aggregated data
        - anonymized_users       # PII removed
      views:                     # Use database views to mask data
        - customer_summary
        - order_statistics

Best Practices

Section titled “Best Practices”

Register All Applications

Section titled “Register All Applications”

Maintain a complete inventory:

  • Document application purpose
  • Track data access requirements
  • Identify application owner
  • Record compliance requirements

Implement Least Privilege

Section titled “Implement Least Privilege”

Grant minimum necessary access:

  • Specify exact datasets, not wildcards
  • Use read-only access when possible
  • Limit permissions (SELECT vs INSERT/UPDATE/DELETE)
  • Restrict network access

Rotate Credentials Regularly

Section titled “Rotate Credentials Regularly”

Automate credential lifecycle:

  • Service account passwords: 90 days
  • API keys: 180 days
  • Certificates: 365 days
  • Emergency credentials: 30 days

Monitor Application Access

Section titled “Monitor Application Access”

Track application behavior:

  • Query patterns and volumes
  • Error rates
  • Latency metrics
  • Anomalous behavior
  • Failed authentication attempts

Separate Environments

Section titled “Separate Environments”

Use different configurations per environment:

  • Development: Permissive, test data
  • Staging: Similar to production, synthetic data
  • Production: Strict, real data

Document Data Flows

Section titled “Document Data Flows”

Map how applications use data:

  • Which datasets are accessed
  • How data is processed
  • Where data is sent
  • Retention and deletion policies

Implement Circuit Breakers

Section titled “Implement Circuit Breakers”

Prevent cascading failures:

  • Rate limiting
  • Connection pooling
  • Timeout configurations
  • Retry logic with backoff
  • Graceful degradation

Common Patterns

Section titled “Common Patterns”

Microservices Architecture

Section titled “Microservices Architecture”

Multiple services accessing shared databases:

# Service A
metadata:
  name: user-service
spec:
  access:
    sources:
      - source: production-db
        datasets: [users, user_profiles, authentication]


---
# Service B
metadata:
  name: order-service
spec:
  access:
    sources:
      - source: production-db
        datasets: [orders, order_items, inventory]
      - source: user-service-api  # Service-to-service call
        endpoints: [/api/users/*]

Data Lake Access

Section titled “Data Lake Access”

Pipeline writing to multiple zones:

spec:
  access:
    sources:
      - source: data-lake-s3
        paths:
          - /raw/                # Ingest raw data
          - /processed/          # Write processed data
          - /curated/            # Write curated datasets
        permissions:
          - s3:PutObject
          - s3:GetObject
          - s3:ListBucket

Analytics Platform

Section titled “Analytics Platform”

BI tool with read-only access:

spec:
  access:
    sources:
      - source: analytics-warehouse
        datasets:
          - public.*             # All tables in public schema
        permissions: [SELECT]


  network:
    ipAllowlist: [vendor-ip-ranges]


  dataHandling:
    allowExport: false
    rowLimit: 1000000            # Limit result set size
Section titled “Related Components”
  • Policies - Centralize channel definitions with other access control components
  • Subjects - Define which users/apps can use specific channels
  • Resources - Specify what data channels can access
  • Constraints - Set temporal limits on channel usage
  • Context - Provide authentication and organizational context for channels