Ansible Automation Platform RBAC: Role-Based Access Control for Enterprise Teams

Introduction

As automation scales across an organization, controlling who can run what, where, and when becomes critical. Ansible Automation Platform's Role-Based Access Control (RBAC) provides granular permission management through organizations, teams, roles, and credential isolation — enabling self-service automation without compromising security.

See also: AAP 2.6 Multi-Tenancy: Organizations, Teams, and RBAC at Scale

RBAC Hierarchy

AAP's permission model works through a layered hierarchy:

Organization (e.g., "Engineering")
├── Teams
│   ├── Platform Team (admin access)
│   ├── Dev Team (use templates, view inventory)
│   └── QA Team (execute jobs, read-only inventory)
├── Projects (Git repos with playbooks)
├── Inventories (host groups)
├── Credentials (SSH, cloud, vault)
└── Job Templates (preconfigured jobs)

Organizations

Organizations are the top-level container for isolating resources between business units:

Engineering Org          Finance Org
├── Platform Team        ├── FinOps Team
├── Dev Inventories      ├── Finance Servers
├── Dev Credentials      ├── Finance Credentials
└── Dev Templates        └── Finance Templates

Each organization has its own: • Users and teams • Inventories and credentials • Projects and job templates • Notification profiles

See also: Ansible for Compliance Automation: CIS Benchmarks, STIG, and PCI DSS

Built-in Roles

| Role | Scope | Permissions | |------|-------|------------| | System Administrator | Global | Full access to everything | | System Auditor | Global | Read-only access to everything | | Organization Admin | Org | Full access within their organization | | Organization Auditor | Org | Read-only within their organization | | Team Admin | Team | Manage team membership | | Team Member | Team | Inherits team's granted permissions |

Object-Level Permissions

Each AAP resource type supports granular role assignments:

Job Templates

| Permission | Can Do | |------------|--------| | Admin | Edit, delete, grant permissions | | Execute | Launch jobs | | Read | View template configuration |

Inventories

| Permission | Can Do | |------------|--------| | Admin | Edit, delete, manage hosts | | Use | Attach to job templates | | Ad Hoc | Run ad-hoc commands | | Read | View inventory and hosts |

Credentials

| Permission | Can Do | |------------|--------| | Admin | Edit, delete, grant access | | Use | Attach to templates (cannot view secret values) | | Read | See credential exists (not the secret) |

See also: Ansible Automation Platform: The Trusted Execution Layer for AI-Driven IT Operations

Enterprise RBAC Patterns

Pattern 1: Platform Team + Consumer Teams

# Platform Team — manages infrastructure
Platform Team:
  Organizations: Admin
  All Projects: Admin
  All Inventories: Admin
  All Credentials: Admin
  All Templates: Admin
# Application Dev Team — uses templates only
App Dev Team:
  Deploy Template: Execute
  Dev Inventory: Read
  Staging Inventory: Read
  # No credential access — templates handle it

Pattern 2: Environment Isolation

# Development
Dev Team:
  Dev Inventory: Use, Ad Hoc
  Dev Credentials: Use
  Dev Templates: Execute, Read
# Staging (more restricted)
Dev Team:
  Staging Inventory: Read  # No ad hoc
  Staging Templates: Execute
# Production (most restricted)
Dev Team:
  Prod Templates: Read  # Can see, cannot execute
  # Only Platform Team can execute prod jobs

Pattern 3: Self-Service Automation

# Workflow template with approval
Template: "Deploy to Production"
  Permissions:
    Dev Team: Execute
  Workflow:
    1. Deploy to staging (auto)
    2. Run tests (auto)
    3. Approval node (requires Platform Team member)
    4. Deploy to production (auto after approval)

Credential Isolation

One of RBAC's most powerful features: teams can use credentials without seeing them.

# Platform Team creates credential
SSH Credential: "prod-deploy-key"
  Owner: Platform Team (Admin)
  Grants:
    App Team: Use  # Can attach to templates
    QA Team: Use   # Can attach to templates
    # Neither team can view the private key

This enables: • Centralized credential management • Zero-knowledge consumption by application teams • Credential rotation without updating any team's workflow

API Access Control

RBAC extends to the REST API — API tokens inherit the user's permissions:

# User with "Execute" on template can launch via API
curl -X POST https://aap.example.com/api/v2/job_templates/42/launch/ \
  -H "Authorization: Bearer $USER_TOKEN"
# Same user cannot delete the template
curl -X DELETE https://aap.example.com/api/v2/job_templates/42/ \
  -H "Authorization: Bearer $USER_TOKEN"
# Returns 403 Forbidden

Audit and Compliance

AAP logs all RBAC-relevant events: • User authentication (login/logout/failed) • Permission changes (grants/revocations) • Job launches (who, what template, which inventory) • Credential usage (which credential, by whom) • Inventory changes (host additions/removals)

# Query activity stream via API
curl https://aap.example.com/api/v2/activity_stream/?actor__username=john

Best Practices

Use organizations to isolate business units — Never share credentials or inventories across orgs Teams, not individual users — Assign permissions to teams; add/remove users from teams Principle of least privilege — Start with Read, grant Execute and Use as needed Credential isolation is non-negotiable — Teams should Use credentials, never Admin them Workflow approvals for production — Use approval nodes in workflows for change control Regular access reviews — Quarterly audit of team memberships and permission grants System Auditor for compliance — Give security/audit teams System Auditor role Automate user provisioning — Integrate with LDAP/SAML for automatic team mapping

LDAP/SAML Team Mapping

# AAP Settings → Authentication → LDAP
# Map LDAP groups to AAP teams automatically
LDAP Team Map:
  "Platform Team":
    organization: Engineering
    users: "CN=platform-engineers,OU=Groups,DC=example,DC=com"
    remove: true  # Remove from team if removed from LDAP group
  "Dev Team":
    organization: Engineering
    users: "CN=developers,OU=Groups,DC=example,DC=com"

FAQ

Can I create custom roles?

AAP provides predefined roles per object type (Admin, Execute, Use, Read). You compose custom permission sets by combining these across different objects for a team.

How to handle contractors/temporary access?

Create a dedicated team with limited permissions. Remove contractors from the team when their engagement ends. Use LDAP integration for automatic provisioning/deprovisioning.

RBAC in AWX vs AAP?

AWX has the same RBAC model. AAP adds SAML/LDAP integration features and enterprise audit capabilities.

Conclusion

AAP's RBAC system transforms automation from a single-team tool into an enterprise-wide platform. By combining organizations, teams, and granular object permissions with credential isolation, you can enable self-service automation while maintaining complete security and compliance governance.

Related Articles

• What is Ansible AWX? • Ansible Automation Platform 2.6 • HashiCorp Vault Integration with AAP