AAP 2.6 Multi-Tenancy: Organizations, Teams, and RBAC at Scale
By Luca Berton · Published 2024-01-01 · Category: troubleshooting
Implement multi-tenancy in AAP 2.6 with organizations, teams, role-based access control, and resource isolation. Enterprise patterns for shared platform management across business units.
Why Multi-Tenancy in AAP?
Large organizations run a single AAP deployment shared across multiple business units, teams, and projects. Multi-tenancy ensures: • Resource isolation — Team A cannot access Team B's credentials or inventories • Self-service — Teams manage their own automation without platform admin help • Cost efficiency — One platform instead of many • Centralized governance — Consistent policies, auditing, and compliance • Scalability — Add teams without redeploying infrastructure
AAP Multi-Tenancy Model
AAP uses a hierarchical model:
Organizations
Organizations are the top-level tenant boundary. Each organization has its own: • Users and teams • Projects and inventories • Credentials • Job templates and workflows • Notification templates • Execution environments
Create Organizations
Organization-Level Settings
| Setting | Purpose | |---------|---------| | max_hosts | Limit total managed hosts per org | | default_environment | Default EE for job templates | | custom_virtualenv | Legacy venv path (deprecated) |
Teams
Teams group users within an organization:
Add Users to Teams
RBAC Roles
AAP uses a granular role system. Every resource has associated roles:
System Roles
| Role | Scope | Capabilities | |------|-------|-------------| | System Administrator | Global | Full access to everything | | System Auditor | Global | Read-only access to everything | | Normal User | Per-resource | Access based on granted roles |
Resource Roles
Each resource type has specific roles:
| Resource | Available Roles | |----------|----------------| | Organization | Admin, Member, Read, Execute, Project Admin, Inventory Admin, Credential Admin, Workflow Admin, Notification Admin, Audit | | Job Template | Admin, Execute, Read | | Workflow Template | Admin, Execute, Approve, Read | | Inventory | Admin, Use, Ad Hoc, Update, Read | | Credential | Admin, Use, Read | | Project | Admin, Use, Update, Read |
Grant Permissions
Multi-Tenancy Design Patterns
Pattern 1: Org per Business Unit
Each business unit gets its own organization:
Pros: Strong isolation, clear ownership Cons: Shared resources (like monitoring playbooks) must be duplicated
Pattern 2: Org per Environment
Separate organizations for dev, staging, and production:
Pros: Environment isolation, different credential sets Cons: Same team needs access to multiple orgs
Pattern 3: Shared Services Org
A central "Platform" org provides shared resources to all tenants:
LDAP/SAML Integration
Map external directory groups to AAP organizations and teams:
LDAP Group Mapping
SAML Group Mapping
Instance Groups for Tenant Isolation
Assign dedicated execution nodes to organizations:
This ensures Engineering jobs only run on dedicated execution nodes, providing: • Performance isolation — other orgs can't consume Engineering's capacity • Network isolation — Engineering exec nodes can be in a specific network zone • Compliance — certain workloads must run on dedicated infrastructure
Auditing Multi-Tenant Activity
Activity Stream Filtering
Compliance Reporting
FAQ
Can users belong to multiple organizations?
Yes. A user can be a member of multiple organizations and teams. Their effective permissions are the union of all granted roles across all organizations.
Can I prevent org admins from creating credentials?
Yes. Use the Credential Admin role instead of Admin. Org Admin has full access within the org, but you can create more granular roles by assigning specific resource-level roles instead of org-level Admin.
How do I share a project across organizations?
Create the project in a shared "Platform" organization and grant Use permission to teams in other organizations. Alternatively, create the same project in each organization (pointing to the same Git repo).
What is the maximum number of organizations?
There is no hard limit. Practical limits depend on database size and management complexity. Most enterprise deployments have 5-50 organizations.
Can I set quotas per organization?
The max_hosts setting limits the number of managed hosts per organization. There are no built-in quotas for job count, storage, or API calls. Implement custom quotas via API monitoring and alerting.
Conclusion
Multi-tenancy in AAP 2.6 enables a single automation platform to serve an entire enterprise. The combination of organizations, teams, RBAC roles, instance groups, and directory integration provides the isolation, self-service, and governance that shared platforms require. Design your tenant model early — reorganizing later is significantly harder than getting it right from the start.
Related Articles • AAP 2.6 RBAC and Gateway API • AAP 2.6 Architecture and Components: Complete Guide • AAP 2.6 Security Best Practices • AAP 2.6 Self-Service Automation Portal • AAP 2.6 Credential Management: Vaults, External Secrets, and Machine Credentials
Category: troubleshooting