OpenStack Identity - Keystone (liberty) by Lorenzo Carnevale and Silvio Tavilla

OpenStack Identity Service - Keystone
Distributed Systems course at Engineering and Computer Science (ECS)
University of Messina
by
Lorenzo Carnevale & Silvio Tavilla

Note
The content covered are part of the site openstack.org
We are going to install Keystone on Ubuntu 14

Goals
● Knowing OpenStack Identity Service;
● Installing and configuring OpenStack Liberty Identity Service;
● Learning to use command-line interface (CLI);
● Advanced topic;
● Learning to use Identity API v3

Topics
Overview
❖ OpenStack Identity -
Keystone
❖ Installation and first
configuration of Keystone
❖ Identity service
configuration
➢ Identity API protection with
RBAC
➢ Use Trusts
➢ Certificates for PKI
❖ Hierarchical Projects
❖ Identity API v3 client
example

OpenStack
● Open-source;
● Cloud IaaS;
● Private and Public Cloud;
● Support of: Xen , VMware, KVM, ecc;
● Modular architecture;
● The OpenStack users control processes, storage and networks with web-
based dashboard, command-line tool (CLI) or RESTful API;
● Apache License;

OpenStack roadmap
April
2015
October
2015
“Kilo”
Sèrves,
France is
home to the
Kilogram
“Liberty” - a village in the
Canadian province of
Saskatchewan.
April
2016
“Mitaka” - is a
city located in
Tokyo
Metropolis,
Japan.
TBD
Austin Summit
TBD
Barcelona Summit

Topics
❖ Overview
OpenStack Identity -
Keystone
configuration
RBAC
➢ Use Trusts
example

memcache
WSGI
Can be run in a WSGI-capable web
server such as Apache httpd to
provide the Identity service. The
service and administrative APIs are
run as separate instances of the
WSGI service.
The Web Server Gateway Interface
(WSGI) is a specification for simple
and universal interface between web
servers and web applications or
frameworks for the Python
programming language.
The protocol specifies how the server
capture requests from browser / client
and forwarding your information
requests, as well as how to use the
information and how to respond.
SQL
LDAP

memcache
WSGI
Memcached (Mem-Cache-D) is a
general-purpose distributed memory
caching system. It is often used to
speed up dynamic database-driven
websites by caching data and objects
in RAM to reduce the number of times
an external data source (such as a
database or API) must be read.
Memcached is used to store token in
secure way.
SQL
LDAP

memcache
WSGI
MySQL is an open-source relational
database management system
(RDBMS); in July 2013, it was the
world's most widely used RDBMS,
and the most widely used open-
source client–server model RDBMS.
The SQL acronym stands for
Structured Query Language.
SQL
LDAP

memcache
WSGI
The Lightweight Directory Access
Protocol is an open, vendor-neutral,
industry standard application protocol
for accessing and maintaining
distributed directory information
services over an Internet Protocol (IP)
network. Directory services play an
important role in developing intranet
and Internet applications by allowing
the sharing of information about users,
systems, networks, services, and
applications throughout the network.
A common usage of LDAP is to
provide a single sign on where one
password for a user is shared
between many services, such as
applying a company login code to web
pages (so that staff log in only once to
company computers, and then are
automatically logged into the company
intranet).
LDAP is based on a simpler subset of
the standards contained within the X.
500 standard. Because of this
relationship, LDAP is sometimes
called X.500-lite.]
SQL
LDAP

OpenStack Identity concepts
Authentication
The process of confirming the identity of a user. To confirm an incoming request, OpenStack Identity validates a set of credentials that the
user supplies. Initially, these credentials are a user name and password or a user name and API key. When OpenStack Identity validates
user credentials, it issues an authentication token that the user provides in subsequent requests.
Credentials
Data that confirms the identity of the user. For example, user name and password, user name and API key, or an authentication token that
the Identity service provides.
Domain
An Identity service API v3 entity. Represents a collection of projects and users that defines administrative boundaries for the management
of Identity entities. A domain, which can represent an individual, company, or operator-owned space, exposes administrative activities
directly to system users. Users can be granted the administrator role for a domain. A domain administrator can create projects, users, and
groups in a domain and assign roles to users and groups in a domain.
Endpoint
A network-accessible address, usually a URL, through which you can access a service. If you are using an extension for templates, you
can create an endpoint template that represents the templates of all consumable services that are available across the regions.

Group
An Identity service API v3 entity. Represents a collection of users that are owned by a domain. A group role granted to a domain or project
applies to all users in the group. Adding users to, or removing users from, a group respectively grants, or revokes, their role and
authentication to the associated domain or project.
OpenStackClient
A command-line interface for several OpenStack services including the Identity API. For example, a user can run the openstack service
create and openstack endpoint create commands to register services in her OpenStack installation.
Project
A container that groups or isolates resources or identity objects. Depending on the service operator, a project might map to a customer,
account, organization, or tenant.
Region
An Identity service API v3 entity. Represents a general division in an OpenStack deployment. You can associate zero or more sub-regions
with a region to make a tree-like structured hierarchy. Although a region does not have a geographical connotation, a deployment can use
a geographical name for a region, such as us-east.
Role
A personality with a defined set of user rights and privileges to perform a specific set of operations. The Identity service issues a token that
includes a list of roles to a user. When a user calls a service, that service interprets the set of user roles and determines to which
operations or resources each role grants access.

Service
An OpenStack service, such as Compute (nova), Object Storage (swift), or Image service (glance), that provides one or more endpoints
through which users can access resources and perform operations.
Token
An alpha-numeric text string that enables access to OpenStack APIs and resources. A token may be revoked at any time and is valid for a
finite duration. While OpenStack Identity supports token-based authentication in this release, it intends to support additional protocols in
the future. OpenStack Identity is an integration service that does not aspire to be a full-fledged identity store and management solution.
User
A digital representation of a person, system, or service that uses OpenStack cloud services. The Identity service validates that incoming
requests are made by the user who claims to be making the call. Users have a login and can access resources by using assigned tokens.
Users can be directly assigned to a particular project and behave as if they are contained in that project.

Topics
❖ Overview
Keystone
Installation and first
configuration
RBAC
➢ Use Trusts
example

Conventions
Command prompts
$ prompt
Any user, including the root user, can run commands that are prefixed with the $ prompt.
# prompt
The root user must run commands that are prefixed with the # prompt. You can also prefix these commands with the
sudo command, if available, to run them.

OpenStack packages
To enable the OpenStack repository
# apt-get install software-properties-common
# add-apt-repository cloud-archive:liberty
● Upgrade the packages on your system:
# apt-get update && apt-get dist-upgrade
# apt-get install python-openstackclient

MySQL
● To install the database:
# apt-get install mariadb-server python-pymysql
● To create the database, complete these steps:
a) Use the database access client to connect to the database server as the root user:
$ mysql -u root -p
b) Create the keystone database:
CREATE DATABASE keystone;
c) Grant proper access to the keystone database:
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'KEYSTONE_DBPASS';
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'KEYSTONE_DBPASS';
Replace KEYSTONE_DBPASS with a suitable password (we chose “keystone”).
d) Exit the database access client.

Install and configure Keystone
In Liberty, the keystone project deprecates Eventlet in favor of a WSGI server. This guide uses the Apache HTTP server with
mod_wsgi to serve keystone requests on ports 5000 and 35357. By default, the keystone service still listens on ports 5000 and
35357. Therefore, this guide disables the keystone service.
● Disable the keystone service from starting automatically after installation:
# echo "manual" > /etc/init/keystone.override
● Run the following command to install the packages:
# apt-get install keystone apache2 libapache2-mod-wsgi memcached python-memcache
● Edit /etc/hosts and add this row: <ip_host_machine_controller> nameHost
# nano /etc/hosts
<ip_host_machine_controller> controller-keystone
Edit the /etc/keystone/keystone.conf file and complete the following actions:
● In the [DEFAULT] section, define the value of the initial administration token:
[DEFAULT]
...
admin_token = ADMIN_TOKEN

● In the [database] section, configure database access:
[database]
...
connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@localhost/keystone
● In the [memcache] section, configure the Memcache service:
[memcache]
...
servers = localhost:11211
● In the [token] section, configure the UUID token provider and Memcached driver:
[token]
...
provider =uuid
driver = memcache
● In the [revoke] section, configure the SQL revocation driver:
[revoke]
...
driver = sql
● Populate the Identity service database:
# su -s /bin/sh -c "keystone-manage db_sync" keystone

Apache HTTP server
● Edit the /etc/apache2/apache2.conf file and configure the ServerName option to reference the controller node
# ServerName controller-keystone
● Create the /etc/apache2/sites-available/wsgi-keystone.conf file with the following content:
Listen 5000
Listen 35357
<VirtualHost *:5000>
WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone group=keystone display-name=%{GROUP}
WSGIProcessGroup keystone-public
WSGIScriptAlias / /usr/bin/keystone-wsgi-public
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
<IfVersion >= 2.4>
ErrorLogFormat "%{cu}t %M"
</IfVersion>
ErrorLog /var/log/apache2/keystone.log
CustomLog /var/log/apache2/keystone_access.log combined
<Directory /usr/bin>
<IfVersion >= 2.4>
Require all granted
</IfVersion>
<IfVersion < 2.4>
Order allow,deny
Allow from all
</IfVersion>
</Directory>
</VirtualHost>

<VirtualHost *:35357>
WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone group=keystone display-name=%{GROUP}
WSGIProcessGroup keystone-admin
WSGIScriptAlias / /usr/bin/keystone-wsgi-admin
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
<IfVersion >= 2.4>
ErrorLogFormat "%{cu}t %M"
</IfVersion>
ErrorLog /var/log/apache2/keystone.log
CustomLog /var/log/apache2/keystone_access.log combined
<Directory /usr/bin>
<IfVersion >= 2.4>
Require all granted
</IfVersion>
<IfVersion < 2.4>
Order allow,deny
Allow from all
</IfVersion>
</Directory>
</VirtualHost>
● Enable the Identity service virtual hosts
# ln -s /etc/apache2/sites-available/wsgi-keystone.conf /etc/apache2/sites-enabled
● Restart the Apache HTTP server
# service apache2 restart
● Because this configuration uses an SQL database server, you can remove the SQLite database file:
# rm -f /var/lib/keystone/keystone.db

Create the service entity and API endpoint
The identity service provides a catalog of services and their locations.
Each service that you add to Openstack, requires a service entity and several API endpoint in the catalog
To configure prerequisites
To initialize the service entity and API endpoint for the Identity service, you must use a temporary authentication token.
You must pass the value of the authenticaton token to the openstack command with the --os-token parameter or set the
OS_TOKEN environment variable. Similarly, you must do with Identity service URL: --os-url or set the OS_URL environment
variable.
For security reason, don’t use temporary authetication for longer than necessary to initialize the Identity service.
● Configure the authentication token
$ export OS_TOKEN=ADMIN_TOKEN
● Configure the endpoint URL:
$ export OS_URL=http://controller-keystone:35357/v3
● Configure the identity API version:
$ export OS_IDENTITY_API_VERSION=3

To create the service entity and API endpoint
The Identity service manages a catolog of services in you Openstack. Services use this catalog to determine the other services
available in your environment
● Create the service entity for the Identity service
$ openstack service create --name keystone --description “Openstack Identity” identity
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | OpenStack Identity |
| enabled | True |
| id | 4ddaae90388b4ebc9d252ec2252d8d10 |
| name | keystone |
| type | identity |
+-------------+----------------------------------+
OpenStack generates IDs dynamically, so you will see different values in our examples

The Identity service manages a catalog of API endpoints associated with the services in your OpenStack environment.
Services use this catalog to determine how to communicate with other services.
OpenStack uses three API endpoint variants for each service:
● admin
● internal
● public
The admin API endpoint allows modifying users and tenants by default, while the public and internal APIs do not.
In a production environment, the variants might reside on separate networks that service different types of users for security
reasons. For instance:
● the public API network might be reachable from outside the cloud for management tools
● the admin API network might be protected
● the internal API network is connected to each host
Also, OpenStack supports multiple regions for scalability. For simplicity, this guide uses the management network for all endpoint
variations and the default RegionOne region.

Create projects, users and roles
The Identity service provides authentication services for each OpenStack service.
The authentication service uses a combination of domains, projects (tenants), users and roles.
(For simplicity, this guide implicitly uses the default domain)
To create tenants, users, and roles
1. Create an administrative project, user and role for administrative operations in your environment
a. Create the admin project
$ openstack project create --domain default --description "Admin Project" admin
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Admin Project |
| domain_id | default |
| enabled | True |
| id | 343d245e850143a096806dfaefa9afdc |
| is_domain | False |
| name | admin |
| parent_id | None |
+-------------+----------------------------------+

d. Add the admin role to the admin project and user
$ openstack role add --project admin --user admin admin
Any roles that you create must map to roles specified in the policy.json file in the configuration file directory of
each OpenStack service.
The default policy for most services grants administrative access to the admin role
2. This guide uses a service project that contains a unique user for each service that you add to your environment
a. Create the service project
$ openstack project create --domain default --description "Service Project" service
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Service Project |
| enabled | True |
| id | 894cdfa366d34e9d835d3de01e752262 |
| name | service |
+-------------+----------------------------------+

c. Create the user role
$ openstack role create user
+-------+----------------------------------+
| Field | Value |
+-------+----------------------------------+
| id | 997ce8d05fc143ac97d83fdfb5998552 |
| name | user |
+-------+----------------------------------+
d. Add the user role to the demo project and user
$ openstack role add --project demo --user demo user
You can repeat this procedure to create additional projects and users

Verify Operation
Verify operation of the Identity service before installing other services
1. For security reasons, disable the temporary authentication token mechanism
Edit the /etc/keystone/keystone-paste.ini file and remove admin_token_auth from the [pipeline:public_api], [pipeline:
admin_api], and [pipeline:api_v3] sections
2. Unset the temporary OS_TOKEN and OS_URL environment variables
$ unset OS_TOKEN OS_URL
3. As the admin user, request an authentication token from the Identity version 2.0 API
$ openstack --os-auth-url http://controller-keystone:35357/v3 --os-project-domain-id default --os-user-domain-id default
--os-project-name admin --os-username admin --os-auth-type password token issue
Password:
+------------+----------------------------------+
| Field | Value |
+------------+----------------------------------+
| expires | 2015-03-24T18:55:01Z |
| id | ff5ed908984c4a4190f584d826d75fed |
| project_id | cf12a15c5ea84b019aec3dc45580896b |
| user_id | 4d411f2291f34941b30eef9bd797505a |
+------------+----------------------------------+
4. This command uses the password for the admin user

4. The Identity version 3 API adds support for domains that contain projects and users.
Projects and users can use the same names in different domains. Therefore, in order to use the version 3 API, requests
must also explicitly contain at least the default domain or use IDs.
For simplicity, this guide explicitly uses the default domain so examples can use names instead of IDs
$ openstack --os-auth-url http://controller-keystone:5000/v3 --os-project-domain-id default --os-user-domain-id default
--os-project-name demo --os-username demo --os-auth-type password token issue
Password:
+------------+----------------------------------+
| Field | Value |
+------------+----------------------------------+
| expires | 2014-10-10T12:51:33Z |
| id | 1b87ceae9e08411ba4a16e4dada04802 |
| project_id | 4aa51bb942be4dd0ac0555d7591f80a6 |
| user_id | 7004dfa0dda84d63aef81cf7f100af01 |
+------------+----------------------------------+
This command uses the password for the admin user

Create OpenStack client environment scripts
The previous section used a combination of environment variables and command options to interact with the Identity service via
the openstack client.
To increase efficiency of client operations, OpenStack supports simple client environment scripts also known as OpenRC
files. These scripts typically contain common options for all clients, but also support unique options
To create the scripts
Create client environment scripts for the admin and demo projects and users
1. Edit the admin-openrc.sh file and add the following content:
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=ADMIN_PASS
export OS_AUTH_URL=http://controller:35357/v3
export OS_IDENTITY_API_VERSION=3
Replace ADMIN_PASS with the password you chose for the admin user in the Identity service

2. Edit the demo-openrc.sh file and add the following content:
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=demo
export OS_TENANT_NAME=demo
export OS_USERNAME=demo
export OS_PASSWORD=DEMO_PASS
export OS_AUTH_URL=http://controller:5000/v3
Replace DEMO_PASS with the password you chose for the demo user in the Identity service
To load client environment scripts
To run clients as a specific project and user, you can simply load the associated client environment script prior to running them.
For example:
1. Load the admin-openrc.sh file to populate environment variables with the location of the Identity service and the admin
project and user credentials:
$ source admin-openrc.sh
+------------+----------------------------------+
2. Request an authentication token: | Field | Value |
$ openstack token issue +------------+----------------------------------+
| expires | 2015-03-25T01:45:49.950092Z |
| id | cd4110152ac24bdeaa82e1443c910c36 |
| project_id | cf12a15c5ea84b019aec3dc45580896b |
| user_id | 4d411f2291f34941b30eef9bd797505a |
+------------+----------------------------------+

UNSET environment scripts
unset OS_PROJECT_DOMAIN_ID
unset OS_USER_DOMAIN_ID
unset OS_PROJECT_NAME
unset OS_TENANT_NAME
unset OS_USERNAME
unset OS_PASSWORD
unset OS_AUTH_URL
unset OS_IDENTITY_API_VERSION
unset OS_TOKEN
unset OS_TRUST_ID

Topics
❖ Overview
Keystone
Identity service
configuration
RBAC
➢ Use Trusts
example

Identity Service configuration
● keystone.conf: file to configure most Identity service options;
http://docs.openstack.org/kilo/config-reference/content/section_keystone.conf.html
● keystone-paste.ini: file to configure the Web Service Gateway Interface (WSGI) middleware pipeline for the Identity
service.
http://docs.openstack.org/kilo/config-reference/content/section_keystone-paste.ini.html
● logging.conf
http://docs.openstack.org/kilo/config-reference/content/section_keystone-logging.conf.html
● policy.json: file to define additional access controls that apply to the Identity service.

Identity API protection with RBAC
Each Identity API v3 call has a line in the policy file that dictates which level of governance of access applies.
Where:
RULE_STATEMENT can contain RULE_STATEMENT or MATCH_STATEMENT.
MATCH_STATEMENT is a set of identifiers that must match between the token provided by the caller of the API and the parameters or target
entities of the API call in question. For example:
Indicates that to create a user, you must have the admin role in your token. The domain_id in your token must match the domain_id in the
user object that you are trying to create, which implies this must be a domain-scoped token. In other words, you must have the admin role on
the domain in which you are creating the user, and the token that you use must be scoped to that domain.

Each component of a match statement uses this format:
The Identity service expects these attributes:
Attributes from token:
● user_id
● domain_id
● project_id
The project_id attribute requirement depends on the scope, and the list of roles you have within that scope.
Attributes related to API call:
● user.domain_id
● Any parameters passed into the API call
● Any filters specified in the query string

You reference attributes of objects passed with an object.attribute syntax (such as, user.domain_id). The target objects of an API are also
available using a target.object.attribute syntax. For instance:
would ensure that Identity only deletes the user object in the same domain as the provided token.
Every target object has an id and a name available as target.OBJECT.id and target.OBJECT.name. Identity retrieves other attributes from the
database, and the attributes vary between object types. The Identity service filters out some database fields, such as user passwords.
List of object attributes:

The default policy.json file supplied provides a somewhat basic example of API protection, and does not assume any particular use of
domains. Refer to policy.v3cloudsample.json as an example of multi-domain configuration installations where a cloud provider wants to
delegate administration of the contents of a domain to a particular admin domain. This example policy file also shows the use of an
admin_domain to allow a cloud provider to enable cloud administrators to have wider access across the APIs.
A clean installation could start with the standard policy file, to allow creation of the admin_domain with the first users within it. You could then
obtain the domain_id of the admin domain, paste the ID into a modified version ofpolicy.v3cloudsample.json, and then enable it as the main
policy file.

Use Trusts
OpenStack Identity manages authentication and authorization. A trust is an OpenStack Identity extension that enables delegation and,
optionally, impersonation through keystone. A trust extension defines a relationship between:
Trustor: the user delegating a limited set of their own rights to another user;
Trustee: the user trust is being delegated to, for a limited time.
The trust can eventually allow the trustee to impersonate the trustor. For security reasons, some safeties are added. For example, if a
trustor loses a given role, any trusts the user issued with that role, and the related tokens, are automatically revoked.
The delegation parameters are:
User ID
The user IDs for the trustor and trustee.
Privileges
The delegated privileges are a combination of a tenant ID and a number of roles that must be a subset of the roles assigned to
the trustor.
If you omit all privileges, nothing is delegated. You cannot delegate everything.

Delegation depth
Defines whether or not the delegation is recursive. If it is recursive, defines the delegation chain length.
Specify one of the following values:
● 0. The delegate cannot delegate these permissions further.
● 1. The delegate can delegate the permissions to any set of delegates but the latter cannot delegate further.
● inf. The delegation is infinitely recursive.
Endpoints
A list of endpoints associated with the delegation.
This parameter further restricts the delegation to the specified endpoints only. If you omit the endpoints, the delegation is
useless. A special value of all_endpoints allows the trust to be used by all endpoints associated with the delegated tenant.
Duration
(Optional) Comprised of the start time and end time for the trust.

Use Trusts example
● Unset the demo creds and create a openrc file for the trustee demo user
export OS_TOKEN=<TOKEN>
export OS_AUTH_URL=http://controller-keystone:5000/v3
export OS_TRUST_ID=<TRUST-ID>
● Try to execute admin operations
$ source demo_trust-openrc.sh
$ openstack user list

Certificates for PKI
Tokens are documents, cryptographically signed using the X509 standard. In order to work correctly, token generation requires a
public/private key pair. The public key must be signed in an X509 certificate and the certificate used to sign it must be available as a
Certificate Authority (CA) certificate. These files can be generated either using thekeystone-manage utility, or externally generated. The
files need to be in the locations specified by the top level Identity service configuration file keystone.conf as specified in the above
section. Additionally, the private key should only be readable by the system user that will run the Identity service.
The values that specify where to read the certificates are under the [signing] section of the configuration file. The configuration values
are:
● certfile: location of certificate used to verify tokens. Default is /etc/keystone/ssl/certs/signing_cert.pem.
● keyfile: location of private key used to sign tokens. Default is /etc/keystone/ssl/private/signing_key.pem.
● ca_certs: location of certificate for the authority that issued the above certificate. Default is/etc/keystone/ssl/certs/ca.pem.
● ca_key: location of the private key used by the CA. Default is /etc/keystone/ssl/private/cakey.pem.
● key_size: default is 2048.
● valid_days: default is 3650.
● cert_subject: certificate subject (auto generated certificate) for token signing. Default
is/C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com.

Certificates for PKI
Tokens are documents, cryptographically signed using the X509 standard. In order to work correctly, token generation requires a
public/private key pair. The public key must be signed in an X509 certificate and the certificate used to sign it must be available as a
Certificate Authority (CA) certificate. These files can be generated either using thekeystone-manage utility, or externally generated. The
files need to be in the locations specified by the top level Identity service configuration file keystone.conf as specified in the above
section. Additionally, the private key should only be readable by the system user that will run the Identity service.
The values that specify where to read the certificates are under the [signing] section of the configuration file. The configuration values
are:
● certfile: location of certificate used to verify tokens. Default is /etc/keystone/ssl/certs/signing_cert.pem.
● keyfile: location of private key used to sign tokens. Default is /etc/keystone/ssl/private/signing_key.pem.
● ca_certs: location of certificate for the authority that issued the above certificate. Default is/etc/keystone/ssl/certs/ca.pem.
● ca_key: location of the private key used by the CA. Default is /etc/keystone/ssl/private/cakey.pem.
● key_size: default is 2048.
● valid_days: default is 3650.
● cert_subject: certificate subject (auto generated certificate) for token signing. Default
is/C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com.
In cryptography, an entity that issues digital
certificates. The digital certificate certifies the
ownership of a public key by the named subject of
the certificate. This enables others (relying parties)
to rely upon signatures or assertions made by the
private key that corresponds to the certified public
key. In this model of trust relationships, a CA is a
trusted third party for both the subject (owner) of
the certificate and the party relying upon the
certificate. CAs are characteristic of many public
key infrastructure (PKI) schemes.

It’s possible to use a signing certificate issued by an external CA instead of generated by keystone-manage. However, a certificate
issued by an external CA must satisfy the following conditions:
● All certificate and key files must be in Privacy Enhanced Mail (PEM) format
● Private key files must not be protected by a password
When using a signing certificate issued by an external CA, you do not need to specify key_size, valid_days, and ca_passwordas they
will be ignored.
The basic workflow for using a signing certificate issued by an external CA involves:
1. Request Signing Certificate from External CA
2. Convert certificate and private key to PEM if needed
3. Install External Signing Certificate

Other features
● Configure the Identity service with SSL
● External authentication with Identity
You can use an SQL identity back end together with X.509 authentication and Kerberos, instead of using the user name and
password combination.
● Integrate Identity with LDAP
The OpenStack Identity service supports integration with existing LDAP directories for authentication and authorization
services.
When the OpenStack Identity service is configured to use LDAP back ends, you can split authentication (using the identity
feature) and authorization (using the assignment feature).
The identity feature enables administrators to manage users and groups by each domain or the OpenStack Identity service
entirely.
The assignment feature enables administrators to manage project role authorization using the OpenStack Identity service SQL
database, while providing user authentication through the LDAP directory.
● Configure Identity service for token binding
Token binding embeds information from an external authentication mechanism, such as a Kerberos server or X.509 certificate,
inside a token. By using token binding, a client can enforce the use of a specified external authentication mechanism with the
token. This additional security mechanism ensures that if a token is stolen, for example, it is not usable without external
authentication.

● Caching layer
OpenStack Identity supports a caching layer that is above the configurable subsystems (for example, token, assignment).
OpenStack Identity uses the dogpile.cache library which allows flexible cache back ends. The majority of the caching
configuration options are set in the [cache] section of the keystone.conf file. However, each section that has the capability to be
cached usually has a caching boolean value that toggles caching.
● User CRUD
Identity provides a user CRUD (Create, Read, Update, and Delete) filter that can be added to the public_api pipeline. The user
CRUD filter enables users to use a HTTP PATCH to change their own password. To enable this extension you should define a
user_crud_extension filter, insert it after the “option:*_body middleware and before the public_service application in
thepublic_api WSGI pipeline in keystone-paste.ini.
● Logging
You configure logging externally to the rest of Identity. The name of the file specifying the logging configuration is set using
thelog_config option in the [DEFAULT] section of the keystone.conf file. To route logging through syslog, setuse_syslog=true in
the [DEFAULT] section.

Topics
❖ Overview
Keystone
configuration
RBAC
➢ Use Trusts
Hierarchical Projects
example

Hierarchical Projects: problem description
OpenStack will add support for hierarchical ownership of objects.
This enables the management of projects and quotas in a way that is more comfortable for private clouds, because in a private cloud,
you can organize better your departmental divisions they work as “subprojects”.
Use Case:
● A division of a large enterprise is represented by a domain in an OpenStack installation, and consists of Dev and Test teams.
● The division admin team wants to be able to assign quotas to each of the sub-teams for all their projects.
● The division admin team creates all the users for Dev and Test in the company LDAP, which the divisional domain references
for authentication.
● The domain admin team creates a top level project for each of the Dev and Test teams, and assign an admin from each team
the project_admin role on their respective top level project. The domain admin team create a quota for each team on their
respective top level project.
● Each team can then creates projects below their top level project, and the usage vs quotas can be compared at the top level
project level.

Proposed Change
● After that you must create domains and the projects hierarchies will be placed under
those domains. You can create as many domains as you want and as many hierarchies
as you want under each domain.
● Max Depth Tree:
○ As of the first release we should have a configuration option allowing to restrict
the depth of the tree with a reasonable default of 5.
● Update Projects:
○ In this first release, It will not be possible to update the hierarchy. So we can’t
change the parent project of any project.
● Delete Projects:
○ It is possible to delete leaf projects.
○ The first version will support a non-recursive delete function which will fail with
“in use” or similar if the project to be deleted has children.
● Get Projects:
○ Clear identifier to indicate we are looking for hierarchy details.

● Roles:
○ Inherited roles assignments: If a user has, say, a role assignment “project_member” that was marked as inherited in a project, then
this user will automatically have this role on any child projects. Currently, inherited roles assignments only work from domains to
projects, this proposal expands this inheritance to work down a hierarchy of projects.
○ This change will be implemented in the extension OS-INHERIT, like currently working for domains.
○ Example:
■ The domain_admin_team creates the Dev and Test projects and assigns the role project_admin to project_admin_user. As
their role is inheritable it will have access to their children.
■ As Joe has project_admin role assignment in Dev project, he can create instances in this project and can create subproject
and control quotas to his subprojects. The same thing will happen to Sam in Test.
■ The user_project_admin can grant/revoke roles to users in its project and in its subprojects. A user with a member role can’t
grant/revoke roles.
● Token:
○ Token must be scoped to the target project on which the action is performed.
○ If the role assignment of a project is inheritable, tokens granted to child projects will also contain this role assignment, otherwise it
will not have access.

● Users:
○ This proposal does not change user/group management - this is still handled at the domain level.
● Notes:
Not available in Keystone V2 API.

Hierarchical Projects: example

Groups
A group is a collection of users in a domain. Administrators can create groups and add users to them. A role can then be assigned to the
group, rather than individual users. Groups were introduced with the Identity API v3.
Identity API V3 provides the following group-related operations:
● Create a group
● Delete a group
● Update a group (change its name or description)
● Add a user to a group
● Remove a user from a group
● List group members
● List groups for a user
● Assign a role on a tenant to a group
● Assign a role on a domain to a group
● Query role assignments to groups

Topics
❖ Overview
Keystone
configuration
RBAC
➢ Use Trusts
Identity API v3 client
example

References
● http://docs.openstack.org/admin-guide-cloud/;
● http://docs.openstack.org/kilo/config-reference/content/config_overview.html;
● http://specs.openstack.org/openstack/keystone-
specs/specs/juno/hierarchical_multitenancy.html;
● http://raildo.me/hierarchical-multitenancy-in-openstack/;
● http://docs.openstack.org/developer/python-keystoneclient/api/keystoneclient.
v3.html#module-keystoneclient.v3.credentials;
● https://en.wikipedia.org/wiki/.

About us
Lorenzo Carnevale Silvio Tavilla
lorenzocarnevale@gmail.com
www.linkedin.com/in/lorenzocarnevale
www.slideshare.net/LorenzoCarnevale
silvio.tavilla@gmail.com
lorenzocarnevale silvio.tavilla
www.linkedin.com/in/silvio-tavilla-
1b2b21110

OpenStack Identity - Keystone (liberty) by Lorenzo Carnevale and Silvio Tavilla

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to OpenStack Identity - Keystone (liberty) by Lorenzo Carnevale and Silvio Tavilla

Similar to OpenStack Identity - Keystone (liberty) by Lorenzo Carnevale and Silvio Tavilla (20)

Recently uploaded

Recently uploaded (20)

OpenStack Identity - Keystone (liberty) by Lorenzo Carnevale and Silvio Tavilla