Constraints

Constraints represent when and for how long access is granted in the Alien Giraffe access control model. This component manages temporal restrictions, session durations, approval timeouts, and just-in-time access patterns. Policies reference constraints in their constraints: field to specify time windows and duration limits.

Relationship to Policies

Constraints are one of the five core components that policies coordinate. When you define a policy, the constraints: field specifies temporal boundaries—business hours, maximum session durations, approval timeouts, and access schedules. This component provides the infrastructure for enforcing those time-based controls.

Overview

Just-In-Time (JIT) access is the primary implementation of constraints, providing temporary permissions that are granted only when needed and automatically revoked when no longer required. This eliminates standing privileges and reduces the attack surface.

Traditional access management grants users permanent permissions to data sources. Even if they only need access occasionally, they maintain these privileges indefinitely. This creates security risks—compromised credentials can be abused, and unused permissions accumulate over time.

JIT access flips this model: users request access when needed, receive temporary credentials, and have access automatically revoked when the session expires or their task is complete.

Core Benefits:

• Reduced Attack Surface - No standing privileges to compromise
• Least Privilege - Access granted only for specific purposes
• Automatic Expiration - No manual cleanup required
• Full Audit Trail - Every access request and session logged
• Compliance - Meets regulatory requirements for access control

How It Works

Request Flow

The complete JIT access workflow:

graph LR
    A[1. Request] --> B[2. Validate]
    B --> C{3. Approval<br/>Required?}
    C -->|Yes| D[Approve]
    C -->|No| E[4. Grant]
    D -->|Approved| E
    D -->|Denied| H[Reject]
    E --> F[5. Access]
    F --> G[6. Audit]
    G --> I[7. Revoke]
    H --> G

Loading diagram...

1. Request

• User requests access through web portal, CLI, or API
• Specifies: data source, datasets, purpose, duration
• Example: “I need read access to production-db for customer support for 2 hours”

2. Validate

• Alien Giraffe checks user identity and active policies
• Verifies request matches policy constraints
• Validates requested duration is within policy limits

3. Approve (if required)

• Some policies require explicit approval
• Manager or data owner notified
• Approver reviews purpose and scope
• Approval expires if not acted upon

4. Grant

• Temporary credentials generated
• Scoped to specific datasets only
• Set to expire at requested duration

5. Access

• User connects with temporary credentials
• All queries and operations logged
• Session monitored for anomalies

6. Audit

• Complete record of access created
• Includes: who, what, when, why, which queries executed
• Logs sent to SIEM or security monitoring

7. Revoke

• Credentials automatically expire
• Immediate revocation if session is terminated early
• Access removed from all active connections

Access Duration

Sessions have configurable time limits:

Short Sessions (15m - 1h):

• Sensitive data access
• Production write operations
• Emergency break-glass access
• Compliance-restricted data

Medium Sessions (2h - 4h):

• Customer support tasks
• Incident investigation
• Development work on staging
• Standard data analysis

Long Sessions (8h - 24h):

• Analytics and reporting
• Data science experiments
• Long-running ETL jobs
• Batch processing tasks

Users can request specific durations within policy limits. Policies can set minimum and maximum bounds.

Configuration Examples

Basic JIT Policy

Enable JIT access for customer support team:

apiVersion: v1
kind: Policy
metadata:
  name: jit-customer-support
  namespace: production
spec:
  subjects:
    - team: customer-support
  resources:
    - source: production-db
      datasets: [customers, orders, support_tickets]
  constraints:
    - timeframe: business-hours
    - duration:
        min: 30m
        max: 4h
        default: 2h
  channels:
    - name: sql
      operation: rw
  context:
    - customer-support
  jit:
    enabled: true
    approval: not-required

Approval-Required JIT

Require manager approval for production database access:

apiVersion: v1
kind: Policy
metadata:
  name: jit-production-with-approval
  namespace: production
spec:
  subjects:
    - team: engineering
  resources:
    - source: production-db
      datasets: ["*"]
  constraints:
    - duration:
        max: 2h
  channels:
    - name: sql
      operation: rw
  jit:
    enabled: true
    approval:
      required: true
      approvers:
        - role: manager
        - role: tech-lead
      timeout: 1h                    # Approval request expires
      escalation:
        after: 30m
        to: [senior-manager]
    notification:
      channels: [slack, email]
      message: "Production database access requested"

Emergency Break-Glass

Fast-track emergency access with strict auditing:

apiVersion: v1
kind: Policy
metadata:
  name: jit-emergency-access
  namespace: production
spec:
  subjects:
    - team: on-call-engineers
  resources:
    - source: production-db
      datasets: ["*"]
  constraints:
    - timeframe: "*"
    - duration:
        max: 1h                      # Short emergency sessions
  channels:
    - name: sql
      operation: rw
  context:
    - incident-response
    - outage
  jit:
    enabled: true
    approval: not-required           # Skip approval for emergencies
    breakGlass: true
  mfa:
    required: true                   # Still require MFA
  audit:
    level: verbose
    notify:
      immediate:
        - slack: "#security-alerts"
        - email: security@company.com
        - pagerduty: security-oncall

Self-Service JIT

Allow users to request access themselves:

apiVersion: v1
kind: Policy
metadata:
  name: jit-analytics-self-service
  namespace: production
spec:
  subjects:
    - team: data-analysts
    - team: data-scientists
  resources:
    - source: analytics-replica      # Read replica only
      datasets: ["*"]
      permissions: [SELECT]          # Read-only
  constraints:
    - timeframe: business-hours
    - duration:
        min: 1h
        max: 8h
        default: 4h
  channels:
    - name: sql
      operation: r
  jit:
    enabled: true
    approval: not-required
    selfService: true
    requestForm:
      fields:
        - name: purpose
          type: text
          required: true
        - name: ticket
          type: url
          label: "Jira ticket"
          required: true

Access Request Methods

Web Portal

Self-service portal for access requests:

Features:

• Visual interface for selecting sources and datasets
• Pre-populated forms based on user’s team memberships
• Real-time policy validation
• Purpose documentation
• Access history and active sessions

User Experience:

1. Navigate to Alien Giraffe portal
2. Click “Request Access”
3. Select data source from dropdown
4. Choose datasets (or all)
5. Specify purpose and duration
6. Submit request
7. Receive credentials or await approval

CLI Tool

Command-line interface for developers:

# Request access
a10e access request \
  --source production-db \
  --datasets customers,orders \
  --purpose "customer-support" \
  --duration 2h

# Output:
# ✓ Access granted
# Session ID: sess-abc123
# Expires: 2025-11-18 16:30:00 UTC
# Credentials: [saved to ~/.a10e/credentials]

# List active sessions
a10e access list

# Revoke session early
a10e access revoke sess-abc123

# Extend session (if policy allows)
a10e access extend sess-abc123 --duration 1h

API Integration

Programmatic access for automation:

# Request access via API
curl -X POST https://a10e.company.com/api/v1/access/request \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "source": "production-db",
    "datasets": ["customers"],
    "purpose": "customer-support",
    "duration": "2h"
  }'

{
  "sessionId": "sess-abc123",
  "credentials": {
    "host": "db.production.internal",
    "port": 5432,
    "database": "app_production",
    "username": "temp_alice_abc123",
    "password": "generated-secure-password",
    "expiresAt": "2025-11-18T16:30:00Z"
  }
}

Slack Integration

Request access directly from Slack:

/a10e access production-db for customer-support

Alien Giraffe bot responds with approval workflow or credentials.

Approval Workflows

Manager Approval

Request routed to user’s manager:

Approval Flow:

1. User submits access request
2. Manager notified via email/Slack
3. Manager reviews purpose and scope
4. Manager approves or denies
5. User receives credentials or denial notification

Approval UI:

Access Request from Alice Chen
─────────────────────────────
Source:      production-db
Datasets:    customers, orders, payment_info
Duration:    2 hours
Purpose:     Investigate payment issue for ticket SUPPORT-1234
Risk Level:  Medium (contains PII and financial data)

[Approve]  [Deny]  [Request More Info]

Multi-Party Approval

Require approval from multiple parties:

jit:
  approval:
    required: true
    approvers:
      - role: manager               # Requires manager AND data owner
      - role: data-owner
    strategy: all-must-approve      # Not just any one approver

Conditional Approval

Automatically approve some requests, require approval for others:

jit:
  approval:
    rules:
      - condition: datasets contains pii
        required: true
        approvers: [manager, data-privacy-officer]

      - condition: duration > 4h
        required: true
        approvers: [manager]

      - condition: time outside business-hours
        required: true
        approvers: [tech-lead, on-call-manager]

Credential Management

Temporary Database Users

Create short-lived database users:

PostgreSQL Example:

-- Created when access granted
CREATE USER temp_alice_abc123 WITH PASSWORD 'generated-password';
GRANT CONNECT ON DATABASE app_production TO temp_alice_abc123;
GRANT SELECT ON customers, orders TO temp_alice_abc123;

-- Revoked when session expires
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM temp_alice_abc123;
DROP USER temp_alice_abc123;

Credential Properties:

• Unique username per session
• Strong random password
• Permissions scoped to approved datasets only
• Automatic cleanup on expiration

Token-Based Access

Generate temporary API tokens:

credentials:
  type: token
  format: jwt
  scopes: [data:read]
  claims:
    user: alice@company.com
    session: sess-abc123
    source: production-db
    datasets: [customers, orders]
    expires: 2025-11-18T16:30:00Z

Cloud Provider Credentials

Generate temporary cloud credentials:

AWS Example (STS Assume Role):

{
  "AccessKeyId": "ASIATEMP...",
  "SecretAccessKey": "...",
  "SessionToken": "...",
  "Expiration": "2025-11-18T16:30:00Z"
}

Scoped IAM Policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::data-lake/customers/*",
      "arn:aws:s3:::data-lake"
    ],
    "Condition": {
      "DateLessThan": {"aws:CurrentTime": "2025-11-18T16:30:00Z"}
    }
  }]
}

Best Practices

Set Appropriate Durations

Match session length to task:

• Customer support inquiries: 2-4 hours
• Incident response: 1-2 hours
• Data analysis: 4-8 hours
• Emergency access: 30 minutes - 1 hour

Avoid excessively long sessions. If users regularly need full-day access, consider whether the data should be replicated to a less-sensitive environment.

Require Purpose Documentation

Always require users to specify why:

• Links justification to access
• Aids compliance audits
• Helps security investigations
• Provides context for approvers

Good purpose examples:

• “Investigating payment issue for customer ticket SUPPORT-5678”
• “Analyzing user churn for Q4 report”
• “Debugging production outage INCIDENT-1234”

Bad purpose examples:

• “Testing”
• “Work stuff”
• “Need access”

Implement Session Extensions

Allow extending sessions without re-requesting:

• User can extend active session
• Extension subject to same policy limits
• Requires re-authentication or approval
• All extensions logged

# Extend current session by 1 hour
a10e access extend --duration 1h

Monitor Access Patterns

Track JIT usage to identify:

• Frequently requested access (candidate for permanent read replica)
• Unused approvals (policy too permissive)
• Denied requests (policy too restrictive)
• Anomalous patterns (potential security issues)

Auto-Revoke on Inactivity

Revoke sessions that are idle:

jit:
  session:
    maxDuration: 4h
    idleTimeout: 30m             # Revoke if no activity for 30 minutes
    idleWarning: 5m              # Warn user 5 minutes before idle revoke

Test Emergency Procedures

Regularly verify break-glass access works:

• Conduct fire drills for incident response
• Ensure on-call engineers can access production quickly
• Verify approval workflows don’t block emergencies
• Test revocation procedures

Common Patterns

Developer Access to Production

Allow engineers to access production with approval:

spec:
  subjects:
    - team: backend-engineers
  resources:
    - source: production-db
      datasets: ["*"]
      permissions: [SELECT]      # Read-only
  channels:
    - name: sql
      operation: r
  jit:
    enabled: true
    approval:
      required: true
      approvers: [tech-lead]
    maxDuration: 2h

Self-Service Analytics

Enable data teams to access analytics databases:

spec:
  subjects:
    - team: data-analysts
  resources:
    - source: analytics-warehouse
      datasets: ["*"]
  channels:
    - name: sql
      operation: r
  jit:
    enabled: true
    approval: not-required       # Self-service
    maxDuration: 8h
    requestForm:
      requirePurpose: true
      requireTicket: true

Time-Bound Contractor Access

Grant temporary access to contractors:

spec:
  subjects:
    - user: contractor@external.com
  resources:
    - source: staging-db
      datasets: [project_data]
  constraints:
    - timeframe:
        start: 2025-11-01
        end: 2025-12-31          # Contract period
    - duration: 4h
  channels:
    - name: sql
      operation: rw
  jit:
    enabled: true
    approval:
      required: true
      approvers: [hiring-manager, security-team]

Related Components

• Policies - Centralize constraint definitions with other access control components
• Subjects - Define who receives time-limited access
• Resources - Specify what data is accessed temporarily
• Channels - Control how temporary access is granted
• Context - Provide purpose and justification for time-limited access