Users, projects, roles and quotas in OpenStack

Keystone models identity well and quotas awkwardly. This is what the entities actually mean, how role scopes and policy decide who can do what, why quota management is spread across three services, and the point at which OpenStack's model stops matching how you sell or share a cloud. Where it stops, edgeContinuum takes over: organizations, roles and quotas that hold for every managed service, on the OpenStack you already run.

1. The Keystone entities and what each one is for

Keystone is OpenStack's identity service: it authenticates, issues tokens, holds the service catalog and answers authorization questions. Five entities carry the whole model.

• Domain: a namespace containing users, groups and projects. Two domains can each hold a user called admin without collision, which is what makes domains the natural boundary for separate organizations sharing one cloud.
• Project: the unit that owns resources and carries quotas. Instances, volumes, networks and images belong to a project, not to a person. Projects can be nested, which is used to model departmental hierarchies.
• User: an identity that authenticates. A user is not confined to one project: membership is expressed by role assignments.
• Group: a set of users, so a role can be granted once to a group instead of repeatedly to people. This is the difference between an access model you can audit and a pile of individual grants.
• Role: a named capability, granted as an assignment that binds a user or group to a scope. The role name alone means nothing; policy decides what it permits.

The single most useful habit here is to grant roles to groups on projects, never to users directly. It costs nothing at the start and is the difference between removing someone in one action and hunting through assignments a year later.

2. Scopes: project, domain and system

A token is scoped, and the scope decides which resources the request can touch.

• Project-scoped: the normal case for anyone consuming the cloud. Actions apply inside one project.
• Domain-scoped: for administering the identities and projects inside a domain, which is how you delegate user and project management to a business unit without handing over the cloud.
• System-scoped: for cloud-wide operations that belong to no project, such as managing hypervisors or service-level configuration.

3. Roles and policy: who can actually do what

Every service enforces its own policy, expressed in rules that map an API action to the roles and scopes allowed to perform it. Defaults ship in code and are overridden per service in a policy file. Two consequences follow.

First, "what can a member do" is not a Keystone question, it is the union of every service's policy. A role grants nothing by itself; a service decides. Second, custom roles are cheap to create and expensive to live with, because a role that no service's policy mentions does nothing at all, and one that several policies mention differently becomes untestable. Prefer the standard roles, override policy sparingly, and keep the overrides in version control with the rest of your configuration.

4. Where users come from: SQL, LDAP and federation

Keystone stores identities in its own database, or reads them from an external source, and the choice shapes daily operations more than any other identity decision.

• SQL backend: users live in Keystone. Simple, self-contained, and a second place where people are created and deactivated.
• LDAP or Active Directory: Keystone reads identities from the corporate directory, usually read-only, while role assignments stay in Keystone. Joiners and leavers are handled once, in the directory, which is normally what an enterprise wants.
• Federation: Keystone acts as a service provider trusting an external identity provider over OIDC or SAML, and mapping rules translate incoming assertions into groups and projects. This is how single sign-on and external organizations get access without accounts being duplicated.

Federation is the most capable and the least forgiving: the mapping rules are the authorization model, and a permissive mapping quietly grants more than intended. Review them like code, because that is what they are.

5. Credentials that are not people

Automation needs to authenticate, and giving a pipeline a human's password is how credentials outlive their owner. Keystone has purpose-built answers. Application credentials let a user mint a credential scoped to one project, optionally limited to a subset of their roles and given an expiry, which a pipeline can use and an operator can revoke without touching the person's account. Trusts allow a user to delegate a limited set of roles to another user for delegated operations, which is the mechanism services use to act on a user's behalf.

The practical rule is that no long-lived automation should hold a password. Application credentials with an expiry and the narrowest role set are the correct default, and rotating them is a scheduled job rather than an incident.

6. Quotas: three services, three answers

Quotas are where the identity model meets accounting, and where OpenStack asks the most patience. Historically each service owns its own limits, in its own database, behind its own API and CLI:

• Nova: instances, vCPUs, memory, server groups, key pairs.
• Cinder: volumes, snapshots, gigabytes, per volume type.
• Neutron: networks, subnets, ports, routers, security groups and rules.

So "what is this team allowed to consume" is three questions with three answers, and raising a limit for a project means touching each service that matters. There is no single place to see a tenant's envelope, and nothing enforces consistency between the three.

Two smaller traps are worth knowing. Quotas bound resources, not cost or shape, so a project inside every limit can still be running the wrong things. And nested projects make quota arithmetic subtle, since a parent's limit and its children's limits have to be reasoned about together.

7. Unified limits, the direction of travel

Unified limits moves the numbers into Keystone: registered limits hold the cloud-wide defaults per resource, project limits override them for a specific project, usage is counted through Placement, and services enforce locally with a shared library. It is the right architecture, and it is arriving unevenly.

Nova has recommended unified limits since its 2023.2 release. Cinder evaluated the model and chose to wait for it to mature. Neutron has an open request to adopt it. And every resource has to be registered in Keystone before enforcement works at all, so a migration is a deliberate project rather than a switch.

8. Where the model stops: organizations and managed services

Everything above is a competent identity system for an infrastructure API. It stops short in four specific places, and they are the same four whether you serve internal teams or paying clients.

• There is no organization. A customer or business unit is usually several projects that should share an envelope, a set of members and a single view. Domains and nested projects approximate it; neither gives aggregate limits over the group or a tenant-level view of what that group holds.
• Limits describe primitives, not products. A quota knows about instances, volumes and ports. What a team consumes is Kubernetes clusters, databases and virtual machines. Six instances and eight volumes inside quota can still be a topology nobody agreed, at a version nobody supports, and the quota cannot say so.
• Roles cover infrastructure actions. Policy answers "may this user boot a server". It has nothing to say about "may this user create a production cluster", because managed services live above the layer policy describes.
• Self-service stops at the operator. Adding a member, creating a project, setting its limits and reporting its consumption are administrative tasks through operator tooling, so team onboarding remains a ticket.

9. Skip the build: organizations, roles and quotas that hold

edgeContinuum keeps Keystone exactly where it is and adds its own identity and tenancy model above it. Each team or client is an organization with its own members, projects, roles and limits. Quotas are enforced where people actually work, on the managed resources they request, so a team cannot create clusters, databases or virtual machines beyond the envelope it was given, and usage is tracked per tenant per resource so consumption is attributable to the organization that caused it.

Users themselves can come from your directory: edgeContinuum imports users from LDAP, so people do not have to be created twice. What it imports is the user list. Permissions are not derived from the directory: there is no group or permission synchronisation and no SAML or OIDC federation, so roles and quotas are assigned in the platform, per organization. That keeps the authorization model in one place and readable, which is the opposite trade from Keystone federation, where permissive mapping rules are the usual way people grant more than they meant to.

Credentials for the services follow the same rule: a managed cluster's administrative kubeconfig is downloaded from the console or the API by whoever holds that permission in the owning organization, so access is administered in the platform rather than by handing out certificates. Because the guardrails hold at that layer, self-service becomes safe: a developer provisions a cluster or a database from the console, the API or Terraform without an operator in the loop, inside limits the platform enforces. Your operators keep Horizon and their existing tooling, nothing about the deployment becomes proprietary, and standard OpenStack APIs stay standard underneath.

Authorization inside an organization is not a fixed ladder either. The platform registers a permission per action it exposes, more than 200 of them across virtual machines, Kubernetes, PostgreSQL, networks, firewalls, routers, SSH keys, regions and the organization itself, and a role is a set of them that you compose and name. Roles are granted to a user or to a group, at organization scope or inside a single project, which is how an operations team can restart machines and scale node pools across a whole estate while delete, resize and credential permissions stay elsewhere. The identity and access page walks through the model with a worked role.

For the wider architecture around this, see the OpenStack self-service platform architecture guide, the OpenStack management platform page, or selling managed services on your own infrastructure if the tenants are clients rather than teams.

Where to start: request a free trial, connect a lab OpenStack and give a team its own organization with real limits in an afternoon. Bring your current domain and quota practice to the call below if you would rather map the model first.

Frequently asked questions