RBAC and Multi-Tenancy

Supporting 5 Teams with Different Access Requirements

Managing a single AAP instance for 5 different teams - each with different security requirements, compliance needs, and access levels - taught me that proper RBAC design is the difference between chaos and control.

Development team needed full access to Dev/QA, zero access to Production. Security team needed read-only everywhere for audits. Operations needed Production access but shouldn't modify job templates. Contractors needed specific, time-limited access.

Without RBAC, we either gave everyone admin (security nightmare) or managed access manually (operational nightmare).

Implementing AAP's RBAC model solved everything: Organization-level isolation, team-based permissions, resource-level access control, and complete audit trails.

What You'll Learn

• Enterprise RBAC model design patterns

• Organization and team structure strategies

• Resource-level permissions (granular control)

• Auditing and compliance reporting

• Instance groups for workload isolation

• Real-world multi-tenancy patterns

AAP RBAC Model

Permission Hierarchy

Global Level:
  - System Administrator
  - System Auditor

Organization Level:
  - Organization Admin
  - Organization Auditor
  - Organization Member

Resource Level (per resource type):
  - Admin (full control)
  - Execute (run jobs)
  - Update (modify settings)
  - Use (utilize in jobs)
  - Adhoc (run ad-hoc commands)
  - Read (view only)

Built-in Roles

System Roles:
  System Administrator:
    - Full access to everything
    - Manage organizations
    - Platform configuration
    
  System Auditor:
    - Read-only access everywhere
    - View all audit logs
    - Cannot modify anything

Organization Roles:
  Organization Admin:
    - Full control within organization
    - Manage teams and users
    - Cannot affect other organizations
    
  Organization Auditor:
    - Read-only within organization
    - View organization resources and logs

Resource Roles:
  Job Template Admin:
    - Modify template settings
    - Grant permissions to others
    
  Job Template Execute:
    - Launch jobs only
    - Cannot modify template

Designing Multi-Tenant Structure

Pattern 1: Team-Based Organizations

Organizations:
  Engineering:
    Teams:
      - Backend-Developers
      - Frontend-Developers
      - DevOps
    
    Inventories:
      - engineering-dev
      - engineering-staging
      - engineering-production
    
    Projects:
      - application-deployments
      - infrastructure-automation
  
  Operations:
    Teams:
      - Infrastructure-Team
      - Database-Team
      - Network-Team
    
    Inventories:
      - infrastructure-production
      - database-servers
      - network-devices

Real-world use: Complete isolation between Engineering and Operations organizations. Each manages their own resources independently.

Pattern 2: Environment-Based Organizations

Organizations:
  Development:
    max_hosts: 200
    teams: [all-developers, qa-team]
    access_level: unrestricted
  
  Staging:
    max_hosts: 100
    teams: [senior-developers, qa-team, ops-team]
    access_level: controlled
  
  Production:
    max_hosts: 500
    teams: [ops-team, sre-team]
    access_level: highly-restricted
    require_approval: true

Real-world use: Strict environment separation. Developers can't touch production by design.

Pattern 3: Customer/Project-Based

# MSP or multi-customer scenario
Organizations:
  Customer-A:
    teams: [customer-a-admins, msp-support]
    inventories: [customer-a-infrastructure]
    isolation: complete
  
  Customer-B:
    teams: [customer-b-admins, msp-support]
    inventories: [customer-b-infrastructure]
    isolation: complete
  
  MSP-Internal:
    teams: [msp-operations, msp-management]
    access: cross-organization-read-only

Team Permission Design

Example: Development Team

Team: Backend-Developers
Organization: Engineering

Permissions:
  Job Templates (development):
    - Execute: Yes
    - Update: Yes
    
  Job Templates (production):
    - Execute: No
    - Update: No
  
  Inventories (dev/staging):
    - Use: Yes
    - Read: Yes
    
  Inventories (production):
    - Use: No
    - Read: No
  
  Credentials:
    - Use: Yes (can use, can't view secrets)
    - Admin: No
  
  Projects:
    - Update: Yes (can sync from Git)
    - Admin: No (can't change SCM URL)

Example: SRE Team

Team: SRE-Team
Organization: Engineering

Permissions:
  Job Templates (all environments):
    - Execute: Yes
    - Update: Yes
    - Admin: No (can't delete)
  
  Inventories (all):
    - Use: Yes
    - Update: Yes
    - Admin: No
  
  Credentials:
    - Use: Yes
    - Admin: No
  
  Workflows:
    - Execute: Yes
    - Admin: Yes (full workflow management)

Example: Security Auditors

Team: Security-Auditors
Organization: (multiple via System Auditor role)

Permissions:
  All Resources:
    - Read: Yes
    - Execute: No
    - Update: No
  
  Special Access:
    - Activity Stream: Full access
    - Audit Logs: Full access
    - Job Output: Full access
    - Credentials: Can see names, not secrets

Resource-Level RBAC

Granular Permission Assignment

# Grant team permission to specific job template
awx roles grant \
  --team "DevOps" \
  --type execute \
  --job-template "Deploy Application"

# Grant user direct permission
awx roles grant \
  --user "[email protected]" \
  --type admin \
  --inventory "Production Servers"

# Grant organization-wide permission
awx roles grant \
  --team "Developers" \
  --type use \
  --credential "AWS-Development"

Permission Matrix Example

Resource: Production Deployment Workflow

Permissions:
  DevOps Team:
    - Execute: Yes
    - Approve: Yes
    
  Senior Developers:
    - Execute: Yes (with approval)
    - Approve: No
    
  Junior Developers:
    - Execute: No
    - Read: Yes
    
  Operations Manager:
    - Execute: Yes
    - Approve: Yes
    - Admin: Yes

Audit and Compliance

Activity Stream

Every action logged:

Logged Events:
  - User login/logout
  - Resource creation/modification/deletion
  - Job execution
  - Permission changes
  - Credential usage (not values)
  - Configuration changes

Log Entry Example:
  timestamp: "2026-01-05T14:30:00Z"
  actor: "[email protected]"
  operation: "update"
  object: "job_template: Deploy Application"
  changes:
    variables:
      old: "app_version: 1.0"
      new: "app_version: 1.1"
  ip_address: "10.0.1.50"

Compliance Reporting

Query Activity Stream:

# Who modified production templates last week?
awx activity_stream list \
  --object_type job_template \
  --operation update \
  --timestamp_gt "2025-12-29"

# All actions by specific user
awx activity_stream list \
  --actor "[email protected]"

# Credential usage audit
awx activity_stream list \
  --object_type credential \
  --operation associate

Real-world compliance use:

Monthly Audit Report:
  - All production job executions
  - User permission changes
  - Credential modifications
  - Failed login attempts
  - Cross-organization access (if any)
  
Export to:
  - PDF for compliance team
  - SIEM integration
  - ServiceNow incident records

Instance Groups for Isolation

Workload Isolation

Instance Groups:
  production-executors:
    instances:
      - exec-prod-01
      - exec-prod-02
    policy: Only production jobs
    
  development-executors:
    instances:
      - exec-dev-01
      - exec-dev-02
    policy: Only dev/staging jobs
  
  customer-a-executors:
    instances:
      - exec-customer-a-01
    policy: Customer A isolation

Organization-Instance Group Assignment

Organization: Engineering
  Default Instance Groups:
    - development-executors
  Allowed Instance Groups:
    - development-executors
    - staging-executors
    - production-executors (with approval)

Organization: Operations
  Default Instance Groups:
    - production-executors
  Allowed Instance Groups:
    - production-executors

Real-World RBAC Scenarios

Scenario 1: Contractor Access

Requirement:
  - 3-month contractor engagement
  - Needs development environment access
  - No production access
  - Time-limited
  
Implementation:
  1. Create user with expiration date
  2. Add to "Contractors" team
  3. Grant team permissions:
     - Job Templates (dev): Execute
     - Inventories (dev): Use, Read
     - Credentials (dev): Use
  4. Automated deactivation after 90 days
  5. Audit all contractor actions

Scenario 2: Cross-Team Collaboration

Requirement:
  - Database team needs to run jobs on infrastructure
  - Infrastructure team needs database automation
  - No cross-organization admin rights
  
Implementation:
  1. Create shared organization: "Shared-Services"
  2. Add teams from both organizations
  3. Delegate specific job templates:
     - DB Team: Execute infra playbooks
     - Infra Team: Execute DB playbooks
  4. Use separate instance groups
  5. Maintain separate audit trails

Scenario 3: Emergency Access

Requirement:
  - Break-glass access for incidents
  - Temporary elevated permissions
  - Full audit trail
  - Auto-revoke after incident
  
Implementation:
  1. Create "Emergency-Access" team
  2. Normally empty (no members)
  3. During incident:
     - Add responder to team
     - Team has elevated permissions
     - All actions logged
  4. Post-incident:
     - Remove from team
     - Review all actions
     - Report to security team

Key Takeaways

✅ Organizations provide complete multi-tenancy isolation ✅ Teams group users with consistent permission sets ✅ Resource-level RBAC enables granular control ✅ Activity Stream provides comprehensive audit trail ✅ Instance Groups isolate workload execution ✅ Design RBAC early - harder to retrofit later

What's Next

The next article covers Credentials Management in depth - custom credential types, external vault integration, credential rotation strategies, and security best practices.

---

Next Article: Credentials Management →

---

Part of the Ansible Automation Platform 101 Series