Keystone Tokenization in IBM Cloud Infrastructure Center: Securing Identity and Access
In any cloud platform, identity and access management (IAM) is the backbone of security. In IBM Cloud Infrastructure Center (ICIC), this responsibility falls on Keystone—the Identity service. Keystone not only handles authentication but also enforces authorization using tokens. Tokens acts as “hall passes” that let users and services interact with ICIC components in a secure, temporary, and scoped manner.
In this blog, we will dive into what Keystone tokens are, how they are created and revoked, the role of roles and permissions, the types of tokens available, and their pros and cons—with insights from both the official Keystone docs and Keystone’s source code.
What is a Token in Keystone?
A token in Keystone is a temporary credential that represents a user (or service) after they have successfully authenticated. Instead of passing raw passwords every time, a client authenticates once, gets a token, and then uses that token to interact with Nova, Neutron, Swift, and other ICIC services.
In Keystone’s codebase, the keystone/token module is where the logic lives. The Provider class manages issuance, validation, and revocation of tokens, abstracting the complexity of different token formats.
How to Generate a Token
To generate a token, a client makes a call to Keystone’s /v3/auth/tokens API. Let’s look at an example using curl:
curl -i \
-H "Content-Type: application/json" \
-d '{
"auth": {
"identity": {
"methods": ["password"],
"password": {
"user": {
"name": "demo",
"domain": { "name": "Default" },
"password": "secret"
}
}
},
"scope": {
"project": {
"name": "demo",
"domain": { "name": "Default" }
}
}
}
}' \
http://127.0.0.1:5000/v3/auth/tokens
The response includes:
- X-Subject-Token: the actual token to use in subsequent requests.
- JSON body: details about the user, roles, project/domain, and expiry.
If you inspect the Keystone code, the API route /v3/auth/tokens is wired to Auth.controllers which calls the token_provider_api.issue_token() method. This is where Keystone generates the token string (UUID or Fernet) and associates metadata like expires_at.
Token Expiry and Auto-Invalidation
Tokens are time-bound. In ICIC, the default expiration is set to 21600 seconds (6 hours), configured in the keystone.conf file located at: /etc/keystone/keystone.conf
When a token is created, Keystone embeds issued_at and expires_at timestamps in its payload. For Fernet tokens, this data is encrypted in the token itself, so no database lookup is required.
Example from Fernet payload (decoded):
{
"user_id": "123456",
"project_id": "demo",
"roles": ["admin"],
"issued_at": "2025-08-17T13:00:00Z",
"expires_at": "2025-08-17T14:00:00Z"
}
This means even if you don’t explicitly revoke a token, it will naturally expire.
How to Revoke a Token
Sometimes you need to revoke a token before it expires—say if a user is terminated or credentials are compromised. Keystone exposes the revocation API:
curl -i -X DELETE \
-H "X-Auth-Token: <admin-token>" \
http://127.0.0.1:5000/v3/auth/tokens \
-H "X-Auth-Token: <token-to-revoke>"
-H "X-Subject-Token: <token-to-revoke>"
-H "Content-Type: application/json"
Internally, this hits the DELETE /v3/auth/tokens controller, which calls revoke_api.revoke_by_token(). For UUID tokens, revocation is tracked in the database; for Fernet, revocation is enforced via key rotation.
Roles, Permissions, and RBAC in IBM Cloud Infrastructure Center
In the world of cloud infrastructure, security isn’t just about who can log in—it's about what actions a user can perform once authenticated. In IBM Cloud Infrastructure Center (ICIC), Role-Based Access Control (RBAC) ensures that users only have access to the resources and operations appropriate to their role.
- Roles are created in Keystone (e.g., admin, member, reader).
- Assignments are scoped to a project, domain, or system.
- Policies in each ICIC service (policy.json or policy.yaml) reference roles to enforce role-based access control (RBAC).
Example: A member role in a project may create instances in Nova, but only an admin can manage quotas.
When a token is issued, Keystone attaches role IDs from the assignment_api module. These roles are embedded in the token payload and later consumed by services like Nova.
What Are Roles in ICIC?
In ICIC, roles are defined and managed by the Keystone identity service. A role represents a set of permissions or capabilities within the system.
Common roles include:
- admin – Full control over resources, configuration, and quotas.
- member – Typical project user, can perform tasks like creating instances.
- reader – Read-only access, useful for audit or monitoring purposes.
These roles do not directly define permissions, but they are used by the policy engine to determine what actions are permitted.
Role Assignments and Scopes
Roles in ICIC are assigned in a scoped manner, allowing for fine-grained control. The scope defines where the role applies:
- Project Scope – Access is limited to a specific project. Ideal for multi-tenant environments.
- Domain Scope – Roles are applied across all projects in a domain.
- System Scope – Highest level of access, across the entire ICIC environment.
This scoping mechanism allows administrators to carefully delegate access without over-provisioning privileges.
How ICIC Uses Policy Files for RBAC?
Each service within IBM Cloud Infrastructure Center (ICIC)—such as Nova for compute or Cinder for block storage, etc—has its own policy file (typically named policy.yaml or policy.json). These files define the authorization rules, specifying which roles are allowed to perform which actions.
In ICIC, you can find the policy files for each service in the following directory:
“/opt/ibm/icic/policy”
This centralized location makes it easier for administrators to manage and customize role-based access control (RBAC) across different ICIC components.
Suppose your IBM Cloud Infrastructure Center (ICIC) environment has two users:
- test_user → assigned the member role
- root_user → assigned the admin role
Now, imagine the policy file for the compute service contains the following rules:
"compute:create": "role:member"
"compute:delete": "role:admin"
This means:
- compute:create: A user with the member role (like test_user) can create virtual machines (VMs) within a project.
- compute:delete: Only a user with the admin role (like root_user) can delete VMs. test_user cannot perform this action.
These policies are enforced at runtime, providing dynamic access control based on the role embedded in the user’s token.
Why RBAC Matters?
RBAC plays a critical role in managing security in IBM Cloud Infrastructure Center. It enables:
- Least privilege access – users get only the permissions they need.
- Multi-tenancy – secure separation between projects or teams.
- Auditability – actions are tied to roles, making it easier to track and audit.
ICIC administrators can customize role definitions and policies to align with organizational security models, making RBAC both flexible and robust.
Types of Tokens in Keystone
Keystone supports multiple token formats. The default today is Fernet.
- UUID Tokens
- Random UUID stored in DB.
- Easy to use, but the DB grows quickly (performance bottleneck).
- Fernet Tokens (default)
- Lightweight, non-persistent.
- Payload is signed and encrypted using Fernet keys.
- No DB bloat, faster validation.
- Requires key rotation (handled by keystone-manage fernet_rotate).
- PKI / PKIZ Tokens
- Cryptographically signed tokens.
- Secure but very large in size (hard to pass in headers).
- Deprecated in most modern deployments.
- System-Scoped Tokens
- Newer type for system-wide operations (introduced post-Stein release).
- Useful for operators/admins.
Pros and Cons of Keystone Tokens
|
Token Type
|
Pros
|
Cons
|
|
UUID
|
Simple, widely supported
|
Requires DB lookups, causes DB bloat
|
|
Fernet
|
Lightweight, stateless, fast, secure
|
Requires key management/rotation; if keys leak, all tokens are compromised
|
|
PKI/PKIZ
|
Cryptographically verifiable, offline validation
|
Large size, overhead, mostly deprecated
|
|
System Scoped
|
Fine-grained control for admins
|
Newer, not supported everywhere
|
Why Tokens Matter
Tokens are central to ICIC’s distributed architecture. Without them:
- Users would have to send raw passwords on every request (security risk).
- Services wouldn’t have a common way to validate user identity and roles.
- RBAC would be harder to enforce across services.
By relying on Keystone tokens, ICIC achieves a scalable, stateless, and secure authentication model.
Conclusion
Keystone tokens are more than just session IDs—they are the foundation of security in IBM Cloud Infrastructure Center - ICIC. They represent who a user is, what they can do, and where they can do it. Understanding how tokens are generated, validated, expired, and revoked is essential for operators, developers, and security teams working with ICIC.