Mastering OpenStack Multitenancy with Keystone and Neutron RBAC: a Guide to Secure Collaboration
As organizations adopt OpenStack to build flexible, vendor-lock-in-free, open-source cloud environments, managing identity and access control becomes a critical piece of the puzzle.
Whether you’re running a private cloud for internal teams or offering Infrastructure-as-a-Service (IaaS) to customers, you need a solid foundation for authentication, authorization, and resource sharing – securely and at scale.
This is where OpenStack Keystone and RBAC (Role-Based Access Control) step in.
In this post, we’ll walk you through:
- What Keystone is and how it structures identity
- The three levels of abstraction in Keystone (Domains → Projects → Sub-Projects)
- What RBAC is, why it matters, and how it works in OpenStack
- How OpenStack Neutron applies RBAC to networking
- Real-world use cases you can learn from
Understanding OpenStack Keystone
What is OpenStack Keystone?
OpenStack Keystone is the identity service used by the OpenStack cloud computing platform. It handles authentication and authorization for all the OpenStack services (like Nova for compute, Glance for images, Cinder for block storage, etc.). Keystone is essentially the gatekeeper that controls who can do what in your OpenStack environment. You can check out this article if you want to learn more about OpenStack Architecture.
Keystone provides:
- Authentication: Validates user credentials and issues tokens.
- Authorization: Determines what actions users can take.
- Service catalog: Lists available services and their endpoints.
- Multitenancy support: Enables secure isolation for multiple users and projects.
🗒️Keystone makes sure that users are who they say they are and controls what they can do in the cloud. Without Keystone, there would be no way to manage who can access which services or perform which actions. It
Keystone's Hierarchical Structure
Keystone organizes identity and access into a hierarchical model with three levels of abstraction:
1. Domains
Domains are the top-level containers in Keystone. They usually represent a large organizational boundary – think of different business units, customers, or institutions. Each domain can have its own set of:
- Users
- Groups
- Projects
- Roles
This makes domains ideal for multi-tenant or service-provider environments. Public clouds based on OpenStack often create a Keystone domain per customer. And one Keystone Domain can hold tens and hundreds of projects.
2. Projects
Projects (previously called “Tenants”) are logical containers for other cloud resources — such as virtual machines, volumes, networks, routers and more. Most day-to-day OpenStack usage happens at the project level. Users are assigned roles within specific projects, controlling what they can do in each one.
3. Sub-Projects (Nested Projects)
OpenStack supports nested projects, a way to create hierarchies within a domain. For example:
Domain: Cloudification
└── Project: Internal IT
├── Sub-project: Dev Team
└── Sub-project: Ops Team
Domain: Project X
└── Project: Application A
└── Project: Application B
└── Sub-project: Testing B
└── Project: Application C
Nested projects allow for granular control and delegated management, especially when paired with OpenStack RBAC.
Nested projects are helpful when:
- Different teams manage different parts of a shared workload
- You want to apply quotas or policies at a higher level but delegate control downward the project structure
- Cost tracking and reporting need to be done hierarchically
Understanding Quotas in OpenStack
Speaking about quotas – these are the soft limits that define how many resources (like VMs, Volumes, or Networks) can be provisioned within a Domain, Project, or a Sub-Project.
Projects consume their quotas from the parent Domain, and the total quotas of all Projects within a Domain must not exceed the Domain’s overall allocation. This hierarchical enforcement ensures fair and predictable resource distribution.
Similarly, Sub-Projects draw from the quota of their parent Project. The combined quota limits of all Sub-Projects must remain within the boundaries of the Project’s quota. This allows organizations to delegate responsibility and control at different levels while maintaining centralized oversight.
In practice, quotas are an essential tool for avoiding resource exhaustion, ensuring multi-tenancy isolation, and enabling capacity planning across teams, departments, or tenants.
TL/DR:
Keystone Domains: Top-level containers representing organizational boundaries. Each domain can contain multiple projects, users, groups and roles.
Keystone Projects: Containers for resources like instances, volumes, and networks. They provide isolation between different user groups.
Keystone Sub-Projects: Similar to regular projects, but their parent container is a project, not a domain.
Users and Groups: Entities that interact with OpenStack services. Users can be organized into groups for easier management.
Quotas: Soft limits on the number of resources that can be provisioned inside of a Project or Sub-Project. The quotas limit the number of users, groups, volumes, VMs, networks, and so on.
This structure facilitates organized and secure management of resources across diverse organizational needs.
Key Terminology: Speak Fluent Keystone
To navigate OpenStack’s Keystone and RBAC model effectively, it’s essential to understand the core terms. Here’s a quick glossary to help you speak the language of identity and access in OpenStack:
🔑 Authentication: The first line of defense – authentication is the process of verifying that a user is who they claim to be. Think of it like showing your ID badge at the entrance.
🛂 Authorization: Once a user is authenticated, authorization checks what they’re actually allowed to do. Just because you’re in the building doesn’t mean you have access to every room.
🏢 Domain: A domain acts as a top-level container for users, groups, and projects. It helps structure your cloud by segmenting resources and access. Users in one domain can potentially be authorized to access resources in another – depending on role assignments.
🧱 Project: A project is where the real action happens – it’s a namespace or container for OpenStack resources (like VMs, Volumes, or Networks). Projects are isolated from each other, providing tenants with secure boundaries. To interact with a project’s resources, a user (or group) must have the appropriate role assigned.
🧑💼 Role: A role represents a set of permissions. For example, the admin role typically allows full control over resources, while the reader might only allow viewing them. Creation of additional roles and segregating permissions further is also possible in OpenStack.
🎭 Role Assignment: A role assignment links an actor (a user or group) with a target (a project, domain, or even the entire system). This association defines what the actor can do within the context of that target.
🪪 Token: Once authenticated, users receive a token – essentially a temporary pass that allows them to interact with OpenStack services. This token can also carry their role-based permissions.
👤 User: A user is a digital representation of an individual end user who interacts with OpenStack.
👥 Group: A group is a collection of users. Instead of assigning roles individually, you can assign them to a group – making access control scalable and easier to manage.
📍Scope: The scope of a token defines the context in which the token is valid—typically a specific project or domain. For example, if a user has access to only one project, their token is “scoped to that project.”
🧩 Service: An OpenStack service is any component within the cloud – such as Nova (compute), Neutron (networking), Cinder (block storage), Designate (DNSaaS) or other. Tokens authorize access to these services based on roles and scope.
Understanding RBAC: Role-Based Access Control in OpenStack
What is RBAC?
Role-Based Access Control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In OpenStack, RBAC is implemented to ensure that users have appropriate permissions corresponding to their roles.
In OpenStack, this looks like:
Roles are defined globally (e.g., reader, member, admin), but assignments are scoped to a particular project or domain meaning that user gets permissions according to the defined boundary, e.g. Project on the image above.
Why is RBAC important?
RBAC is critical for the security and manageability of any OpenStack cloud:
- Principle of the least privilege: Users only get access to the resources and actions they need.
- Auditing and compliance: Access decisions can be traced and justified.
- Delegated administration: Admins can assign roles without exposing the full system.
- Scalability: It’s easier to manage role assignments than to manage individual permissions.
Common OpenStack Roles
While roles are customizable, these are commonly used:
OpenStack’s RBAC is backed by policy.yaml files in each service. These define what each role can actually do (e.g., who can create a server or list volumes). If you create new roles in OpenStack you have to add those to the respective service policy.yaml file and restart the service.
RBAC Use Cases
Let’s look at a few practical examples of how RBAC and Keystone structures are used:
1. Multi-Tenant IaaS Infrastructure
Imagine you’re hosting multiple customers in a private cloud. Each gets its own, dedicated Keystone Domain:
- Customer A → Domain A → Project X, Y
- Customer B → Domain B → Project Z
Only Customer A users can see and interact with resources in Domain A. RBAC ensures proper isolation.
2. Internal Company Teams
You may have a shared Engineering Keystone Domain with multiple nested projects. For example:
- Project: Dev
- Project: QA
- Project: Security
Each team gets member access to their own project, while platform engineers might hold admin roles for the full domain access.
3. Auditing and Read-Only Access
Your compliance team gets reader roles scoped to relevant projects. They can audit logs, see VM specs and network rules – without being able to modify anything.
OpenStack Neutron RBAC: Sharing Networks with Control
The Neutron service (OpenStack’s networking component) supports network-specific RBAC policies – a feature that allows granular sharing of resources like Networks, Routers, or Security groups across Projects and even Domains.
This is useful for:
- Shared infrastructure networks (e.g., for DNS, logging, monitoring or backup)
- Complex applications deployed across multiple projects
Efficient use of floating IP pools or external networks (allowing to share IP pools between multiple projects)
Example: Sharing a Network Across Projects
You can share a private network from one project to another like this:
openstack network rbac create \
--target-project <target_project_id> \
--action access_as_shared \
<network_id>Now, both projects can attach ports to this network – without making the network globally accessible.
Use Case: Shared External Network
At Cloudification, we sometimes set up a central external network that multiple OpenStack projects need access to. With Neutron RBAC, we can:
- Create an External Network in a “platform” project
- Share it with selected tenant projects using access_as_shared
- Keep access under tight control – no other projects can see or use that External Network
OpenStack RBAC Tips and Best Practices
- Use groups for role assignments: Managing user groups is easier and more scalable than assigning roles to individual users.
- Avoid global admin roles unless necessary: Limit the admin role to a few trusted users; prefer project-scoped roles for daily operations.
- Audit your RBAC policy files: Over time, policies can drift. Use version control and documentation for service policy.yaml files.
- Document your hierarchy: Maintain a clear map of your domains, projects, and nested relationships – especially in large scale cloud deployments.
- Monitor RBAC changes: Use Keystone logs and audit trails to track role assignments and access modifications. Each API call in OpenStack has a unique UUID identifier allowing to trace who made that call.
- Use Application Credentials for Automation: When integrating external systems or scripts, use Application Credentials instead of storing user passwords or long-lived tokens. They offer a secure and manageable way to authenticate non-interactive clients.
More on Application Credentials and how to secure Automation in OpenStack
Application Credentials are Keystone-issued authentication artifacts that allow a script or an external application to act on behalf of a user – without needing to store or expose that user’s password or re-use an expiring token.
They consist of:
- A credential ID (similar to a username)
- A secret (similar to a password)
These credentials can be scoped to specific roles and projects, providing tight control over what the application can do.
Why Use Application Credentials?
Application Credentials are important when it comes to automation because while automation is key to scaling and efficiency, it doesn’t come without challenges. One of those is the challenge of securely authenticating non-human users (like scripts, CI/CD systems, and monitoring tools).
Here are some of the advantages of using application credentials:
Security: You avoid storing user passwords in automation scripts or exposing them in CI pipelines.
Scoped Access: You can restrict the credentials to specific roles and projects, minimizing risk if compromised.
Auditing: Actions taken with application credentials are still tied to the owning user, allowing for traceability in logs.
Convenience: Tokens generated from application credentials can be used like any other Keystone token, making integration straightforward.
Use Case Example
Say you’re building a CI/CD pipeline that deploys resources to OpenStack. Instead of embedding your cloud admin’s password in a GitHub Actions workflow file, you can create an application credential scoped to a specific project with the member role. That credential can then be stored as a secret and used for authentication in automation scripts.
openstack application credential create \
--description "CI/CD deployment" \
--role member \
my-cicd-credYou’ll receive a credential ID and a secret, which you can use like this:
export OS_AUTH_TYPE=v3applicationcredential
export OS_APPLICATION_CREDENTIAL_ID=<ID>
export OS_APPLICATION_CREDENTIAL_SECRET=<SECRET>From there, your script can perform OpenStack operations as defined by the scope and role.
Best Practices
- Create credentials with the minimum required permissions.
- Regularly rotate application credentials.
- Revoke unused or compromised credentials immediately.
- Use them in place of passwords for all service integrations.
Wrapping Up
Keystone and RBAC together form the core of identity and access control in OpenStack. Understanding how to structure domains, projects, and roles allows you to secure your cloud, empower your teams, and enable collaboration without compromising isolation.
When paired with features like Neutron RBAC, OpenStack offers a powerful toolkit for multi-tenant networking and secure resource sharing – without vendor lock-in.
At Cloudification, we help enterprises and service providers design secure, scalable and reliable OpenStack environments. Whether you’re building your own private cloud with our c12n solution or migrating from VMware, we’ll help you get the RBAC and identity model right from day one.
Want help designing your Keystone architecture or auditing your RBAC policies?
