In an OpenStack cloud, services like Nova (compute), Cinder (block storage), and Neutron (networking) are constantly talking to each other. A user's request to launch a virtual machine, for instance, triggers a cascade of internal API calls. Nova needs to ask Glance for an image, Neutron for a network port, and Cinder for a boot volume. But how do these services know who is making the request and if they're allowed to do what they're asking? That's Keystone's job.

When a user or a service wants to perform an action, it first authenticates with Keystone. Keystone validates its credentials and, if successful, issues a token. This token is not just a simple password; it’s a temporary, signed credential that contains the user’s identity, their roles, and the scope of their access. Every subsequent request to any other OpenStack service must include this token. The receiving service then turns back to Keystone and asks, "Is this token valid, and does it permit this action?" This process ensures that authentication is centralized and consistent across the cloud.

Modern OpenStack deployments use Fernet tokens for authentication. Unlike older token formats that required persistent storage in a database, Fernet tokens are lightweight and self-contained. They are encrypted and signed using symmetric keys that are shared among Keystone nodes. This design significantly reduces the load on Keystone, as token validation doesn't require a database lookup every single time.

But once a service has a valid token, how does it know where to find other services? It doesn't use hardcoded IP addresses. Instead, the token contains a Service Catalog specific to the user's project. This catalog is a list of all available services (Nova, Cinder, etc.) and their network endpoints—the URLs for their public APIs.

When Nova needs to talk to Cinder, it looks up 'cinder' in the Service Catalog from its token, finds the correct API endpoint, and makes its request. This makes the entire architecture modular. You can move services to different servers or update their endpoints, and as long as the Service Catalog in Keystone is updated, everything continues to work without reconfiguring every other service.

Keystone organizes the cloud using a hierarchy of domains and projects (historically called tenants). A domain is a high-level container for users, groups, and projects. It can represent a distinct customer or an entire department within a company. A project is where resources like virtual machines and volumes actually live. A user can be a member of multiple projects, potentially across different domains, with different roles in each.

This structure is the foundation for Role-Based Access Control (RBAC). When Keystone issues a token, it doesn't just say who the user is; it specifies their roles within a specific project or domain. A user might have an admin role in 'Project A' but only a member role in 'Project B'.

When this user tries to delete a server in Project B, Nova receives the request and its token. Nova checks the token and sees the user only has the member role for this project. It then consults its own policy file (policy.json), which defines what actions each role can perform. The policy might state that only the admin role can delete servers. The request is denied. This allows for granular, centrally managed permissions across the entire cloud.

This integration of identity, policy, and service discovery is what makes Keystone the indispensable core of any OpenStack deployment, enabling secure and scalable multi-tenant operations.

Ready to test your knowledge?

Keystone's role as a centralized identity and access manager is crucial for the security and interoperability of an OpenStack cloud. By handling authentication, managing the service catalog, and enforcing role-based policies, it provides the essential framework for all other services to communicate securely.