IAM and identity on Quake AI
Explanation · Updated Jun 2026
Coming from another cloud?
▸AWS·IAM Users
IAM Users
- AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
▸Azure·Microsoft Entra ID (formerly Azure AD)
Microsoft Entra ID (formerly Azure AD)
- Proprietary Microsoft identity platform with OAuth2/OIDC, MSAL libraries, Microsoft Graph API integration; OpenStack Keystone provides OpenStack-specific token auth with pluggable backends (LDAP/SQL).
- Entra ID supports external identities (B2B/B2C), social logins (Google/Facebook); Keystone focuses on domain/project/role auth, federation via SAML/OIDC possible but secondary.
- Integrated with Azure subscriptions (one tenant per sub); Keystone is deployment-wide, not subscription-scoped.
- Advanced features like PIM, app provisioning; OpenStack roles are simpler, assigned per project.
▸Google Cloud·Cloud Identity / IAM
Cloud Identity / IAM
- Role-based with predefined/custom roles (permissions as service.resource.verb); Keystone uses simpler flat roles assigned to user-project/domain pairs without granular permissions.
- Hierarchical inheritance across Org > Folder > Project; OpenStack Keystone assignments scoped per project/domain without automatic inheritance.
- Supports IAM Conditions for attribute/time-based access, deny policies, VPC Service Controls; no direct OpenStack equivalent.
- Principals include Google groups/service accounts/federated; Keystone uses local users/groups with federation add-ons.
IAM and identity on Quake AI
IAM on AWS, Cloud IAM on Google Cloud, and Microsoft Entra ID on Azure centralize users, roles, and API access for an entire cloud estate. On Quake AI identity flows through Rumble.com sign-in, organizations and projects, Keystone roles, and separate credential types for automation.
There is no single console named IAM. Map habits to the objects below.
Mapping IAM habits#
| IAM habit | On Quake AI |
|---|---|
| Root / billing account | Rumble.com identity + organization |
| Account / subscription partition | Project (quota and resource boundary) |
| IAM user for automation | Application credential scoped to a project |
| Short-lived API token | API token (Keystone) |
| IAM role attached to resource | Project role assignment (member, reader, etc.) |
| S3 access key | S3 credentials |
| Instance SSH access | Key pair |
Fine-grained policy documents per resource ARN are not the model. OpenStack uses project-scoped roles and service APIs enforce ownership on resources inside the project.
What to read next#
- Account model: organizations, projects, tiers, and team roles
- Credentials and tools: which credential each tool consumes
- Shared responsibility: identity and access boundaries
Was this page helpful?