Learn OpenStack - Keystone (Identity Service): Authentication, Projects & RBAC

#Introduction

Of the six core services we met in episode 2, Keystone deserves an episode of its own. Why? Because without Keystone, none of the other services can be accessed. Every request — from the CLI, the dashboard, and even between components — must first be authenticated by Keystone. It isn't just a "login"; it's the security foundation of the entire cluster.

Episode 3 dissects Keystone from the top concept to the bottom: its role as the main gateway, the domain-project-user-group-role model, Fernet tokens, RBAC policies, and federation with LDAP/AD/SAML/OIDC.

#Keystone as the Main Gateway

#One Door for All Services

When you run openstack server create, the CLI first requests a token from Keystone. That token is then sent with every subsequent request. The target service verifies the token with Keystone before processing the request.

CLI/Dashboard → Keystone (request token) → token issued
              → Nova API + token → Keystone (verify) → process

This flow guarantees two things: authentication (who is asking) and authorization (whether the action is allowed). Both are governed by the Keystone identity structure we discuss next.

#Identity in One Sentence

From the largest scope down to the smallest: a domain hosts several projects; inside a project there are users and groups; and each user is given a role that determines access rights. This combination is the basis of RBAC.

#Keystone Fundamental Concepts

#Domains: The Highest Organizational Boundary

A domain is the highest isolation boundary, suitable for separating large organizational entities — for example, the mitra-a and mitra-b domains on a single cloud. Every user, project, and group lives inside a domain. The default installation uses the Default domain; many production deployments add a domain per organization for top-level multi-tenancy.

openstack domain list

#Projects (Tenants): Resource Isolation

A project — formerly called a tenant — is the resource isolation unit. The VMs, networks, volumes, and images you create live inside one project and are invisible to other projects. This is how OpenStack implements multi-tenancy: team A and team B can share a single cloud without interfering with each other.

openstack project create --domain default proyek-riset

openstack project create --domain default proyek-riset creates a project inside the default domain. Each project has its own quota, limited by the admin.

#Users & Groups

A user is the identity of a person or service (service account) that can log into the cloud. A group collects many users to simplify granting roles at once. Instead of assigning a role to 20 users one by one, you can simply assign the role to a single group.

openstack user create --project proyek-riset --password rahasia1 budi
openstack group create tim-riset
openstack group add user tim-riset budi

#Roles: Role-Based Access Rights

A role determines what a user may do within a project. The three most commonly used built-in roles:

openstack role add --project proyek-riset --user budi member

After openstack role add --project proyek-riset --user budi member, the user budi can manage resources in the proyek-riset project but can't delete the project itself. Tighter rights are configured through the policy.yaml file — details in episode 17.

#Token-Based Authentication

#Fernet Tokens: Stateless and Lightweight

Keystone issues a token for every authentication session. Since the Kilo release, the default format is the Fernet token: an encrypted, stateless token. This means Keystone doesn't need to store tokens in the database to validate them — all the information is in the token itself.

openstack token issue

The output of openstack token issue shows the token, the project scope, and the expiry time. Because Fernet is stateless, tokens are very cheap to validate — even at large scale it stays fast. Tokens last a few hours by default, then the user must re-authenticate.

#Fernet Keys and Rotation

Fernet tokens are encrypted with keys stored in fernet_keys. For production multi-node setups, these keys must be synchronized across nodes and rotated periodically. If the keys are lost, all outstanding tokens become invalid.

#Federation & SSO

#LDAP and Active Directory Integration

Large enterprises don't want to create cloud users one by one. Keystone can read identities from LDAP or Active Directory as the identity backend. Users who already exist in AD can log into OpenStack directly without being re-created — group membership and attributes sync along with them.

#SAML and OIDC for Single Sign-On

For single sign-on (SSO), Keystone supports SAML and OpenID Connect (OIDC). With SAML, login happens at an external IdP (for example Okta or ADFS) and is then mapped to OpenStack projects and roles. This federation turns OpenStack into a part of the corporate identity ecosystem.

#Summary

Episode 3 helps you understand Keystone as the main gateway: the domain-project-user-group-role structure for RBAC, stateless and lightweight Fernet tokens, and LDAP/AD/SAML/OIDC federation for SSO. Keystone isn't just a login — it's the identity architecture that secures multi-tenancy.

Key takeaways:

• Every request to an OpenStack service is authenticated through Keystone.
• A domain hosts projects; projects isolate resources between teams.
• The admin, member, and reader roles are the built-in basis of RBAC.
• Fernet tokens are stateless and lightweight, with no database storage.
• LDAP/AD/SAML/OIDC federation moves identity to external systems.
• Don't over-grant roles — authorization is governed by policies and mapping.

In episode 4, we'll cover Glance (Image Service) and Nova (Compute Service) — managing cloud images in QCOW2 format, creating your first instance with the CLI, understanding flavors, and running lifecycle operations such as start, stop, reboot, resize, and snapshot. This is the moment where you create your first VM from the cloud.