OpenStack Identity Service
Red Hat Technical Support Team
Introduction Identity Concept in Openstack
- Actors (Groups and Users)
- Service Catalogs
- Identity Providers (Multi Backend)
- PKI (PKIz)
- Logs, Enabling Debug
- Most common Problems
- Keystone Basic Operations
- Keystone Integration with Active Directory Server for
So where does OpenStack begin and end?
cloud GUI or CLI
Many OpenStack Services, Many API Endpoints!
How to authenticate them? Who will manage the authorization?
How will I come to know what is the endpoint of the service that I
want to access? Example Nova?
Openstack Keystone Service.
"Keystone provides Identity, Token, Catalog and Policy services for use
specifically by projects in the OpenStack family.“
Getting Token : http://openstackcloud.com:5000/v2.0/tokens
Getting endpoint of nova : http://openstackcloud.com:35357/v2.0/endpoints
Call the Nova AP : http://10.65.200.220:8774/v2/302dd5c64a1a4094b17621d3c0ccde59/servers/detail
Actor (User and groups)
Identity Management : Actors
In the Keystone realm, Users and User Groups are the entities given access to resour‐
ces that are isolated in Domains and Projects. Groups are a collection of Users. Users
are individuals who will end up using your cloud. We refer to Users and Groups as
Actors since, when assigning a role, these are the entities to which the role is “assigned
Identity Management : Project
- In Keystone, a Project is an abstraction used by other OpenStack services to group
and isolate resources (e.g., servers, images, etc.).
- Earlier known as Tenant
- Projects themselves don’t own Users, but Users or User Groups are given access to a Project
using the concept of Role Assignments.
Identity Management : Domain
Keystone v3 feature that provide mechanism to limit
the visibility of Projects to different user
For example, a cloud could have two domains, IBM and Red Hat . IBM has their
own collection of groups, users, and projects and so does Red Hat.
Identity Management: Tokens :
An arbitrary bit of test taht is used to access resources. Each token has a scope
which described which resources are accessible with it.
There are four types of token that you can use with OpenStack.
Tokens : UUID
- Simplest and Most Light Weight
- The UUID token is simply a randomly generated
UUID 32-character string (Version 4 UUID ) getuuid
- The token is extremely small and easy to use when
accessing Keystone through a
-Server side validation (Disadvantage with this
token format is that Keystone can become a
bottleneck due to the tremendous amount of
communication that occurs when Keystone is
needed to validate the token.)
- Revoked tokens are not removed from the
database. Need to manually flush the
database. "keystone-manage token_flush"
Token : PKI/PKIz
These are Cryptographically Encrypted Signed Document using X509 Standards.
Heavy weight as the contain contains the entire validation response that would be received from
- Expiry Date
- user identification
- Role information
- service catalog
- other information like region
- Client side validation.
- Complex to setup (Need Cerificates issued from CA)
- Extremely Large (Size can break the web
- Persisted in database. (Need to manually flush the
Token : Fernet Token
Fernet Token :
The newest Keystone token format is the Fernet token format. The Fernet token
attempts to improve on previous token formats in a variety of ways.
- Small footprint, 255 characters. (larger than UUID
tokens, but significantly smaller than PKI)
- Not stored in persistant backend.
- Service side validation
- Fernet tokens use symmetric keys to sign the
token, nnd these keys need to be
distributed to the various OpenStack regions.
"adminURL": "http: //swift.admin-nets.local: 8080/",
"internalURL": "http: //127.0.0.1: 8080/v1/AUTH_1",
"publicURL": "http: //swift.publicinternets.com/v1/AUTH_1"
The adminurl is for the admin users, (can see the all tenants and images )
internalurl are what the other services use to talk to each other
And the publicurl is what everyone else accessing the service endpoint uses.
SSL can also be enabled for the endpoints, However, Currently this configuration
cannot be deployed by our installation and provisioning tool, RHELOSP-Director/Packstack.
This need to be done manually post deployment.
Access Management and Authorization:
Access Management and Authorization is achieved using " Roles + Policy"
/etc/keystone/policy.json : The Policy service provides a rule-based authorization engine and the
associated rule management interface.
The Keystone v3 API introduces two significant Keystone features/concepts:
Domains concept enables multi backed identity provider that simplfies
keystone integration with external user directory services.
Configuration file (keystone.conf)
[DEFAULT] - general configuration
[sql] - optional storage backend configuration
[ec2] - Amazon EC2 authentication driver configuration
[s3] - Amazon S3 authentication driver configuration.
[oauth1] - Oauth 1.0a system driver configuration
[identity] - identity system driver configuration
[catalog] - service catalog driver configuration
[token] - token driver & token provider configuration
[cache] - caching layer configuration
[policy] - policy system driver configuration for RBAC
[signing] - cryptographic signatures for PKI based tokens
[ssl] - SSL configuration
[auth] - Authentication plugin configuration
[os_inherit] - Inherited Role Assignment extension
[paste_deploy] - Pointer to the PasteDeploy configuration file
Running Keystone in HTTPD
# openstack-status service | grep -i keystone
== Keystone service ==
openstack-keystone: inactive (disabled
- Packstack Configuration:
# Name of service to use to run the Identity service (keystone,
- Running Keystone in HTTPD