Skip to main content
The Role-Based Access Control (RBAC) system in AWX provides granular permission management for resources, enabling secure multi-tenant automation environments.

​
Overview

AWX’s RBAC system has been moved to the django-ansible-base library, providing a standardized approach to access control across Ansible automation projects.
The RBAC implementation is now maintained in the django-ansible-base library: https://github.com/ansible/django-ansible-base

​
Core Concepts

​
Users and Teams

Users are individual accounts that can:
  • Be assigned direct permissions to resources
  • Belong to one or more teams
  • Have organization-level roles
  • Be designated as superusers (full system access)
Teams are groups of users that:
  • Share common permissions across resources
  • Simplify permission management for groups
  • Can have organization-scoped access
  • Support hierarchical permission inheritance

​
Organizations

Organizations are the top-level container for AWX resources:
  • Group related projects, inventories, and templates
  • Provide logical separation between different departments or customers
  • Enable multi-tenant environments
  • Have dedicated admin and auditor roles

​
Roles

Roles define what actions users or teams can perform on resources:

Admin

Full control over a resource including permissions management

Execute

Ability to launch jobs and workflows

Read

View-only access to resource details

Update

Modify resource configuration

Use

Use resource in job templates (for credentials, inventories)

Adhoc

Run ad-hoc commands against inventory

​
Resource-Level Permissions

​
Job Templates

Permissions control who can:
  • Admin: Modify template, manage permissions, delete
  • Execute: Launch jobs from the template
  • Read: View template configuration

​
Inventories

1

Admin Role

Full control including managing hosts, groups, and inventory sources
2

Update Role

Modify inventory structure and variables
3

Use Role

Select inventory when launching jobs
4

Adhoc Role

Run ad-hoc commands against inventory hosts
5

Read Role

View inventory details without modification

​
Credentials

Credentials use a restricted permission model:
  • Admin: Manage credential and grant access to others
  • Use: Utilize credential in job templates (cannot view secret values)
  • Read: View credential metadata (not secret fields)
Users with “Use” permission can leverage credentials without viewing secret values. Be careful when granting credential access as users can execute jobs with those credentials.

​
Projects

Project permissions determine access to source control repositories:
  • Admin: Full project management including SCM configuration
  • Use: Reference project in job templates
  • Update: Trigger project syncs
  • Read: View project details

​
Workflows

Workflow Admin Role enables:
  • Creating and modifying workflow templates
  • Managing workflow nodes and topology
  • Configuring approval nodes
  • Setting up workflow schedules
Workflow Execute Role allows:
  • Launching workflow jobs
  • Viewing workflow job results
Workflow Approval Role permits:
  • Approving or denying workflow approval nodes
  • Only applicable to workflows with approval steps

​
Organization-Level Roles

​
Organization Admin

Organization Admins have broad permissions within their organization:
  • Create and manage all resources (projects, inventories, templates)
  • Grant permissions to other users
  • Manage teams within the organization
  • Cannot access resources in other organizations (unless explicitly granted)

​
Organization Auditor

Auditors have read-only access across the organization:
  • View all resources and configurations
  • Monitor job execution and results
  • Cannot modify or execute anything
  • Useful for compliance and oversight

​
Organization Member

Basic membership in an organization:
  • No implicit permissions
  • Must be granted specific resource-level roles
  • Can view organization details

​
System-Level Roles

​
System Administrator

Superusers have unrestricted access to all AWX resources and settings across all organizations.
Capabilities include:
  • Full system configuration
  • User and organization management
  • Access to all resources regardless of organization
  • System-level settings and maintenance

​
System Auditor

Read-only access across the entire AWX instance:
  • View all organizations and resources
  • Monitor system-wide activity
  • Cannot execute or modify anything
  • Perfect for security audits and compliance

​
Permission Inheritance

Permissions follow an inheritance hierarchy: 
Organization Admin
    ↓
Resource Admin (e.g., Project Admin)
    ↓
Resource-Specific Roles (Execute, Update, Use, Read)
Inheritance Rules:
  • Organization Admins automatically have admin access to all resources in their organization
  • Resource Admins can grant lower-level permissions to others
  • Higher-level permissions include all lower-level permissions
  • Superusers bypass all RBAC checks

​
Common RBAC Patterns

​
Multi-Tenant Setup

1

Create Organizations

Set up separate organizations for each tenant or department
2

Assign Organization Admins

Designate admins who manage resources within their organization
3

Create Teams

Group users by function (developers, operators, auditors)
4

Grant Team Permissions

Assign appropriate roles to teams for required resources

​
Development/Production Separation

Development Teams

Grant Execute and Update permissions on dev inventories and templates

Production Teams

Restrict to Execute-only on production resources with change control

​
Credential Isolation

Leverage credential “Use” permission:
  1. Store sensitive credentials (cloud APIs, SSH keys)
  2. Grant “Use” permission to teams/users
  3. Users can launch jobs without viewing secrets
  4. Maintains security while enabling automation

​
Best Practices

Least Privilege

Grant minimum permissions required for users to perform their duties

Use Teams

Manage permissions at team level rather than individual users

Regular Audits

Periodically review and revoke unnecessary permissions

Separate Environments

Use organizations to isolate dev, staging, and production

​
API Access

RBAC applies to API access:
  • Users can only access resources they have permissions for
  • API tokens inherit the user’s permissions
  • OAuth2 tokens can have scoped permissions
  • Personal Access Tokens (PAT) support for API automation

​
Troubleshooting Permissions

​
User Cannot See Resource

1

Check Organization Membership

Verify user is a member of the resource’s organization
2

Review Direct Permissions

Check if user has any role assigned on the resource
3

Check Team Permissions

Verify if user’s teams have access to the resource
4

Parent Resource Access

Some resources require permissions on parent (e.g., project access may require organization access)

​
User Cannot Execute Job Template

To execute a job template, users need:
  • Execute permission on the job template
  • Use permission on associated credential(s)
  • Use permission on the inventory
  • Read permission on the project
Missing any of these permissions will prevent job launch.

​
Migration Notes

If migrating from older AWX versions:
  • Legacy RBAC settings are automatically migrated
  • Review permissions after upgrade
  • Test user access in non-production first
  • django-ansible-base provides enhanced flexibility

Build docs developers (and LLMs) love

Get started for freeTalk to us