Policies

Policies are the foundation of access control in Alien Giraffe. They provide a declarative, version-controlled way to define who can access what data, when, and why.

Overview

Think of policies as the rulebook for data access. Instead of manually granting permissions each time someone needs data, you define the rules once, and Alien Giraffe enforces them automatically. Policies are written in human-readable YAML or JSON, making them easy to understand, review, and audit.

Key Benefits:

• Version Control - Track every change to your access rules
• Code Review - Peer review access policies before deployment
• Automation - Deploy policies through CI/CD pipelines
• Auditability - Clear history of who approved what access

Key Concepts

Formal Access Control Model

Every policy follows a formal access control model with five key components:

• Subjects - Which users or teams need access (e.g., customer-support team, alice@company.com)
• Resources - Which data sources and datasets they can access (e.g., production-db, customers table)
• Constraints - Time windows and duration limits (e.g., business hours, 4-hour sessions)
• Channels - Access methods and operations allowed (e.g., SQL with read/write, API with read-only)
• Context - The purpose or justification (e.g., customer-support, incident-response)

Policy Structure

Policies follow a consistent structure:

apiVersion: v1
kind: Policy
metadata:
  name: policy-name          # Unique identifier
  namespace: production      # Environment or organizational unit
spec:
  subjects: []               # Identity specifications
  resources: []              # Data source specifications
  constraints: []            # Temporal specifications
  channels: []               # Channel and operation specifications
  context: []                # Purpose specifications

Configuration Examples

Basic Policy

A simple policy granting customer support access to customer data:

apiVersion: v1
kind: Policy
metadata:
  name: customer-support-access
  namespace: production
spec:
  subjects:
    - team: customer-support
  resources:
    - source: production-db
      datasets:
        - customers
        - orders
        - support_tickets
  constraints:
    - timeframe: business-hours     # 9 AM - 5 PM in configured timezone
    - duration: 4h                  # Sessions expire after 4 hours
  channels:
    - name: sql
      operation: rw
    - name: api
      operation: rw
  context:
    - customer-support

Multi-User Policy

Grant access to specific individuals and teams:

apiVersion: v1
kind: Policy
metadata:
  name: engineering-database-access
  namespace: staging
spec:
  subjects:
    - team: backend-engineering
    - team: data-engineering
    - user: alice@company.com   # Individual access
    - user: bob@company.com
  resources:
    - source: staging-postgres
      datasets:
        - "*"                   # All datasets in this source
  constraints:
    - timeframe: "*"            # 24/7 access
    - duration: 8h
  channels:
    - name: sql
      operation: rw
  context:
    - development
    - testing

Time-Restricted Policy

Limit access to specific time windows:

apiVersion: v1
kind: Policy
metadata:
  name: weekend-maintenance
  namespace: production
spec:
  subjects:
    - team: sre
  resources:
    - source: production-db
      datasets:
        - schema_migrations
        - system_config
  constraints:
    - timeframe:
        days: [saturday, sunday]
        hours: [2-6]            # 2 AM - 6 AM
    - duration: 4h
  channels:
    - name: sql
      operation: rw
  context:
    - maintenance

Approval-Required Policy

Require manager approval for sensitive data:

apiVersion: v1
kind: Policy
metadata:
  name: pii-access-with-approval
  namespace: production
spec:
  subjects:
    - team: data-science
  resources:
    - source: analytics-warehouse
      datasets:
        - users_pii
        - payment_information
  constraints:
    - duration: 2h              # Short sessions for sensitive data
  channels:
    - name: api
      operation: rw
  context:
    - analytics
    - research
  approval:
    required: true
    approvers:
      - role: manager
      - role: data-privacy-officer
    ttl: 1h                     # Approval expires after 1 hour

Common Patterns

Read-Only Analytics Access

Grant data analysts read-only access to reporting databases:

spec:
  subjects:
    - team: analytics
  resources:
    - source: reporting-replica
      datasets: ["*"]
      permissions: [read]       # Explicitly read-only
  constraints:
    - timeframe: business-hours
    - duration: 24h             # Full-day sessions for analysis work
  channels:
    - name: sql
      operation: r
    - name: api
      operation: r
  context:
    - reporting
    - analytics

Emergency Break-Glass Access

Provide emergency access with stricter audit requirements:

metadata:
  name: emergency-access
  namespace: production
spec:
  subjects:
    - team: on-call-engineers
  resources:
    - source: production-db
      datasets: ["*"]
  constraints:
    - timeframe: "*"
    - duration: 1h              # Short emergency sessions
  channels:
    - name: sql
      operation: rw
  context:
    - incident-response
  audit:
    level: verbose              # Enhanced logging
    notify:
      - slack: "#security-alerts"
      - email: security@company.com
  mfa:
    required: true              # Require multi-factor auth

Third-Party Integration

Grant limited access to external services:

metadata:
  name: analytics-platform-integration
  namespace: production
spec:
  subjects:
    - application: looker
    - application: tableau
  resources:
    - source: analytics-db
      datasets:
        - aggregated_metrics
        - dashboard_data
  constraints:
    - timeframe: "*"
    - duration: 24h
  channels:
    - name: api
      operation: r
  context:
    - business-intelligence
  conditions:
    ip_allowlist:               # Restrict to known IPs
      - 203.0.113.0/24
      - 198.51.100.42

Best Practices

Start with Least Privilege

Grant the minimum access necessary:

• Specify exact datasets rather than wildcards when possible
• Use shorter durations for sensitive data
• Require approval for production data access

Use Namespaces for Organization

Organize policies by environment or business unit:

• production - Production data sources
• staging - Staging/QA environments
• development - Development environments
• finance - Finance team policies
• engineering - Engineering team policies

Version Control Workflow

Treat policies like code:

1. Create feature branches for policy changes
2. Submit pull requests for peer review
3. Test policies in staging before production
4. Use semantic versioning for policy releases
5. Maintain changelog of policy modifications

Monitor and Audit

Regularly review policy effectiveness:

• Track which policies are actively used
• Identify unused or overly permissive policies
• Review access patterns for anomalies
• Audit policy changes monthly

Document Why

Always include meaningful why tags:

• Helps audit teams understand purpose
• Makes it easier to review policies later
• Assists in compliance reporting
• Clarifies intent for future maintainers

Related Components

Policies coordinate the five core access control components:

• Subjects - Define who can access (referenced in subjects: field)
• Resources - Specify what data can be accessed (referenced in resources: field)
• Constraints - Set when and how long access is granted (referenced in constraints: field)
• Channels - Control where and how data is accessed (referenced in channels: field)
• Context - Provide why access is needed (referenced in context: field)