Embed Size (px)
Citation preview
OpenStack Identity Service - KeystoneDistributed Systems course at Engineering and Computer Science (ECS)
University of Messina
byLorenzo 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 Kilo Identity Service;
● Learning to use command-line interface (CLI);
● Advanced topic;
● Learning to use Identity API v3.
Slide and VMs will be provided at the end of the seminar.
Topics
Overview
❖ OpenStack Identity - Keystone
❖ Installation and first configuration of Keystone
❖ Workshop
❖ 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 User
OpenStack roadmap
April 2015
October 2015
“Kilo” Sèrves, France is home to the Kilogram
“Liberty” - a village in theCanadian province ofSaskatchewan.
April 2016
“Mitaka” - is acity located inTokyoMetropolis,Japan.
TBD
Austin Summit
TBDBarcelona Summit
Architettura concettuale
Topics
❖ Overview
OpenStack Identity - Keystone
❖ Installation and first configuration of Keystone
❖ Workshop
❖ Identity service configuration➢ Identity API protection with
RBAC➢ Use Trusts➢ Certificates for PKI
❖ Hierarchical Projects
❖ Identity API v3 client example
Architettura logica
memcache
WSGI
SQLLDAP
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.
SQLLDAP
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.
SQLLDAP
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.
SQLLDAP
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.]
SQLLDAP
OpenStack Identity conceptsAuthentication
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.
CredentialsData 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.
DomainAn 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.
EndpointA 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.
GroupAn 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.
OpenStackClientA 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.
ProjectA 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.
RegionAn 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.
RoleA 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
❖ OpenStack Identity - Keystone
Installation and first configuration of Keystone
❖ Workshop
❖ Identity service configuration➢ Identity API protection with
RBAC➢ Use Trusts➢ Certificates for PKI
❖ Hierarchical Projects
❖ Identity API v3 client 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 packagesTo enable the OpenStack repository
● Install the Ubuntu Cloud archive keyring and repository:# apt-get install ubuntu-cloud-keyring# echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu" \ "trusty-updates/kilo main" > /etc/apt/sources.list.d/cloudarchive-kilo.list
To finalize installation
● Upgrade the packages on your system:# apt-get update && apt-get dist-upgrade
MySQLTo configure prerequisites
Before you configure the OpenStack Identity service, you must create a database and an administration token.
● To install the database:# apt-get install mysql-server python-mysqldb
● 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.
d) Exit the database access client.
Install and configure KeystoneTo install and configure the Identity service components
In Kilo, 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 python-openstackclient apache2 libapache2-mod-wsgi memcached python-memcache
● Edit /etc/hosts and add this row: <ip_host_machine_controller> nameHost# nano /etc/hostslocalhost 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
● Replace ADMIN_TOKEN with the authenticaiton token generated with this command:$ openssl rand -hex 10
● In the [database] section, configure database access:[database]...connection = mysql://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 = keystone.token.providers.uuid.Providerdriver = keystone.token.persistence.backends.memcache.Token
● In the [revoke] section, configure the SQL revocation driver:[revoke]...driver = keystone.contrib.revoke.backends.sql.Revoke
● Populate the Identity service database:# su -s /bin/sh -c "keystone-manage db_sync" keystone
Apache HTTP serverTo configure 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 5000Listen 35357<VirtualHost *:5000>
WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone display-name=%{GROUP} WSGIProcessGroup keystone-public WSGIScriptAlias / /var/www/cgi-bin/keystone/main WSGIApplicationGroup %{GLOBAL} WSGIPassAuthorization On <IfVersion >= 2.4>
ErrorLogFormat "%{cu}t %M"</IfVersion>LogLevel infoErrorLog /var/log/apache2/keystone-error.logCustomLog /var/log/apache2/keystone-access.log combined
</VirtualHost>
<VirtualHost *:35357>WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone display-name=%{GROUP}WSGIProcessGroup keystone-adminWSGIScriptAlias / /var/www/cgi-bin/keystone/adminWSGIApplicationGroup %{GLOBAL}WSGIPassAuthorization On<IfVersion >= 2.4>
ErrorLogFormat "%{cu}t %M"</IfVersion>LogLevel infoErrorLog /var/log/apache2/keystone-error.logCustomLog /var/log/apache2/keystone-access.log combined
</VirtualHost>
● Enable the Identity service virtual hosts# ln -s /etc/apache2/sites-available/wsgi-keystone.conf /etc/apache2/sites-enabled
● Create the directory structure for the WSGI components# mkdir -p /var/www/cgi-bin/keystone
● Copy the WSGI components from the upstream repository into this directory# curl http://git.openstack.org/cgit/openstack/keystone/plain/httpd/keystone.py?h=stable/kilo \| tee /var/www/cgi-bin/keystone/main /var/www/cgi-bin/keystone/admin
● Adjust ownership and permissions on this directory and the files in it# chown -R keystone:keystone /var/www/cgi-bin/keystone# chmod 755 /var/www/cgi-bin/keystone/*
To finalize installation Apache
● Restart the Apache HTTP server# service apache2 restart
● By default, the Ubuntu packages create a SQLite database; because this, you can remove the SQLite database file# rm -f /var/lib/keystone/keystone.db
Create the service entity and API endpointThe 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_TOKENReplace ADMIN_TOKEN with the authenticaiton token generated previously$ export OS_TOKEN=294a4c8a8a475f9b9836
● Configure the endpoint URL:$ export OS_URL=http://controller-keystone:35357/v2.0
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 the Identity service API endpoint
$ openstack endpoint create --publicurl http://controller-keystone:5000/v2.0 \ --internalurl http://controller-keystone:5000/v2.0 \ --adminurl http://controller-keystone:35357/v2.0 \ --region RegionOne \ identity
+--------------+---------------------------------------+| Field | Value |+--------------+---------------------------------------+| adminurl | http://controller-keystone:35357/v2.0 || id | 4a9ffc04b8eb4848a49625a3df0170e5 || internalurl | http://controller-keystone:5000/v2.0 || publicurl | http://controller-keystone:5000/v2.0 || region | RegionOne || service_id | 4ddaae90388b4ebc9d252ec2252d8d10 || service_name | keystone || service_type | identity |+--------------+---------------------------------------+
Each service that you add to your OpenStack environment requires one or more service entities and one API endpoint in the Identity service
Create projects, users and rolesThe 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 --description "Admin Project" admin+-------------+----------------------------------+| Field | Value |+-------------+----------------------------------+| description | Admin Project || enabled | True || id | cf12a15c5ea84b019aec3dc45580896b || name | admin |+-------------+----------------------------------+
b. Create the admin user
$ openstack user create --password-prompt adminUser Password:Repeat User Password:+------------+----------------------------------+| Field | Value |+------------+----------------------------------+| email | None || enabled | True || id | 4d411f2291f34941b30eef9bd797505a || name | admin || username | admin |+------------+----------------------------------+
c. Create the admin role
$ openstack role create admin+-------+----------------------------------+| Field | Value |+-------+----------------------------------+| id | cd2cb9a39e874ea69e5d4b896eb16128 || name | admin |+-------+----------------------------------+
d. Add the admin role to the admin project and user
$ openstack role add --project admin --user admin admin+-------+----------------------------------+| Field | Value |+-------+----------------------------------+| id | cd2cb9a39e874ea69e5d4b896eb16128 || name | 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 --description "Service Project" service+-------------+----------------------------------+| Field | Value |+-------------+----------------------------------+| description | Service Project || enabled | True || id | 55cbd79c0c014c8a95534ebd16213ca1 || name | service |+-------------+----------------------------------+
3. Regular (non-admin) tasks should use an unprivileged project and user. As an example, this guide creates the demo project
and user
a. Create the demo project$ openstack project create --description "Demo Project" demo+-------------+----------------------------------+| Field | Value |+-------------+----------------------------------+| description | Demo Project || enabled | True || id | ab8ea576c0574b6092bb99150449b2d3 || name | demo |+-------------+----------------------------------+
b. Create the demo user$ openstack user create --password-prompt demoUser Password:Repeat User Password:+------------+----------------------------------+| Field | Value |+------------+----------------------------------+| email | None || enabled | True || id | 3a81e6c8103b46709ef8d141308d4c72 || name | demo || project_id | ab8ea576c0574b6092bb99150449b2d3 || username | demo |+------------+----------------------------------+
c. Create the user role
$ openstack role create user+-------+----------------------------------+| Field | Value |+-------+----------------------------------+| id | 9fe2ff9ee4384b1894a90878d3e92bab || name | user |+-------+----------------------------------+
d. Add the user role to the demo project and user
$ openstack role add --project demo --user demo user+-------+----------------------------------+| Field | Value |+-------+----------------------------------+| id | 9fe2ff9ee4384b1894a90878d3e92bab || name | user |+-------+----------------------------------+
You can repeat this procedure to create additional projects and users
Verify OperationVerify 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 \ --os-project-name admin --os-username admin --os-auth-type password \ token issuePassword:+------------+----------------------------------+| Field | Value |+------------+----------------------------------+| expires | 2015-03-24T18:55:01Z || id | ff5ed908984c4a4190f584d826d75fed || project_id | cf12a15c5ea84b019aec3dc45580896b || user_id | 4d411f2291f34941b30eef9bd797505a |+------------+----------------------------------+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:35357 \ --os-project-domain-id default --os-user-domain-id default \ --os-project-name admin --os-username admin --os-auth-type password \ token issuePassword:+------------+----------------------------------+| Field | Value |+------------+----------------------------------+| expires | 2015-03-24T18:55:01Z || id | ff5ed908984c4a4190f584d826d75fed || project_id | cf12a15c5ea84b019aec3dc45580896b || user_id | 4d411f2291f34941b30eef9bd797505a |+------------+----------------------------------+This command uses the password for the admin user
5. As the admin user, list projects to verify that the admin user can execute admin-only CLI commands and that the Identityservice contains the projects that you created
$ openstack --os-auth-url http://controller-keystone:35357 \ --os-project-name admin --os-username admin --os-auth-type password \ project listPassword:+----------------------------------+---------+| ID | Name |+----------------------------------+---------+| 55cbd79c0c014c8a95534ebd16213ca1 | service || ab8ea576c0574b6092bb99150449b2d3 | demo || cf12a15c5ea84b019aec3dc45580896b | admin |+----------------------------------+---------+This command uses the password for the admin user
6. As the admin user, list users to verify that the Identity service contains the users that you created
$ openstack --os-auth-url http://controller-keystone:35357 \ --os-project-name admin --os-username admin --os-auth-type password \ user listPassword:+----------------------------------+-------+| ID | Name |+----------------------------------+-------+| 4d411f2291f34941b30eef9bd797505a | admin || 3a81e6c8103b46709ef8d141308d4c72 | demo |+----------------------------------+-------+This command uses the password for the admin user
7. As the admin user, list roles to verify that the Identity service contains the role that you created
$ openstack --os-auth-url http://controller-keystone:35357 \ --os-project-name admin --os-username admin --os-auth-type password \ role listPassword:+----------------------------------+-------+ | ID | Name |+----------------------------------+-------+| 9fe2ff9ee4384b1894a90878d3e92bab | user || cd2cb9a39e874ea69e5d4b896eb16128 | admin |+----------------------------------+-------+This command uses the password for the admin user
8. As the demo user, request an authentication token from the Identity version 3 API
$ openstack --os-auth-url http://controller-keystone:5000 \ --os-project-domain-id default --os-user-domain-id default \ --os-project-name demo --os-username demo --os-auth-type password \ token issuePassword:+------------+----------------------------------+| Property | Value |+------------+----------------------------------+| expires | 2014-10-10T12:51:33Z | | id | 1b87ceae9e08411ba4a16e4dada04802 || project_id | 4aa51bb942be4dd0ac0555d7591f80a6 || user_id | 7004dfa0dda84d63aef81cf7f100af01 | +------------+----------------------------------+
This command uses the password for the demo user and API port 5000 which only allows regular (non-admin) access to the Identity service API.
9. As the demo user, attempt to list users to verify that it cannot execute admin-only CLI commands
$ openstack --os-auth-url http://controller-keystone:5000 \ --os-project-domain-id default --os-user-domain-id default \ --os-project-name demo --os-username demo --os-auth-type password \ user listERROR: openstack You are not authorized to perform the requested action, admin_required. (HTTP 403)
Create OpenStack client environment scriptsThe 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=defaultexport OS_USER_DOMAIN_ID=defaultexport OS_PROJECT_NAME=adminexport OS_TENANT_NAME=adminexport OS_USERNAME=adminexport OS_PASSWORD=ADMIN_PASSexport OS_AUTH_URL=http://controller-keystone:35357/v3
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=defaultexport OS_USER_DOMAIN_ID=defaultexport OS_PROJECT_NAME=demoexport OS_TENANT_NAME=demoexport OS_USERNAME=demoexport OS_PASSWORD=DEMO_PASSexport OS_AUTH_URL=http://controller-keystone: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 |+------------+----------------------------------+
Topics
❖ Overview
❖ OpenStack Identity - Keystone
❖ Installation and first configuration of Keystone
Workshop
❖ Identity service configuration➢ Identity API protection with
RBAC➢ Use Trusts➢ Certificates for PKI
❖ Hierarchical Projects
❖ Identity API v3 client example
Overview
memcache
WSGI
SQL
Glance
SQL
● Quick installation and configuration guide of Glance service;
● Users install openstackclient on own client;● Users export admin credentials;● Users can try admin Keystone’s commands;
● Users create own username;● Users unset admin credentials;● Users create and export own credentials file;● Users query Glance service with own credentials.
Install Glance in other virtual machine1. Enable the OpenStack repository
2. Install the database, where Glance stores image metada
○ To install the database:# apt-get install mysql-server python-mysqldb
○ To create the database, complete these steps:
■ Use the database access client to connect to the database server as the root user:$ mysql -u root -p
■ Create the keystone database:CREATE DATABASE glance;
■ Grant proper access to the keystone database:GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \
IDENTIFIED BY 'GLANCE_DBPASS';GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' \
IDENTIFIED BY 'GLANCE_DBPASS';
Replace GLANCE_DBPASS with a suitable password.
■ Exit the database access client.
3. Install the packages# apt-get install glance python-openstackclient
4. Edit /etc/hosts and add:<ip-hostKeystone> controller-keystone <ip-hostGlance> controller-glance
5. Edit both /etc/glance/glance-api.conf and /etc/glance/glance-registry.conf files and complete the following actions:
[database]…connection = mysql://glance:GLANCE_DBPASS@controller-glance/glance
Replace GLANCE_DBPASS with the password you chose for the Image service database
6. In the [keystone_authtoken] and [paste_deploy] sections, configure Identity service access
[keystone_authtoken]…auth_uri = http://controller-keystone:5000auth_url = http://controller-keystone:35357auth_plugin = passwordproject_domain_id = defaultuser_domain_id = defaultproject_name = serviceusername = glancepassword = GLANCE_PASS[paste_deploy]flavor = keystone
7. In the [DEFAULT] section, configure the noop notification driver to disable notifications because they only pertain tothe optional Telemetry service
[DEFAULT]…notification_driver = noop
8. Populate the Image service database# su -s /bin/sh -c "glance-manage db_sync" glance
By default, Glance stores the images uploaded in a directory: /var/lib/glance/images/
To finalize installation
Restart the Image service services:# service glance-registry restart# service glance-api restart
By default, the Ubuntu packages create an SQLite database. Because this configuration uses a SQL database server, you can remove the SQLite database file:# rm -f /var/lib/glance/glance.sqlite
● Source the admin credentials to gain access to admin-only CLI commands$ source admin-openrc.sh
● To create the service credentials, complete these steps:
a. Create the glance user
$ openstack user create --password-prompt glanceUser Password:Repeat User Password:+------------+----------------------------------+| Field | Value |+------------+----------------------------------+| email | None || enabled | True || id | 1dc206e084334db2bee88363745da014 || name | glance || username | glance |+------------+----------------------------------+
Create user, service entity and API enpoint
b. Add the admin role to the glance user and service project:$ openstack role add --project service --user glance admin+-------+----------------------------------+| Field | Value |+-------+----------------------------------+| id | cd2cb9a39e874ea69e5d4b896eb16128 || name | admin |+-------+----------------------------------+
c. Create the glance service entity:$ openstack service create --name glance \
--description "OpenStack Image service" image+-------------+----------------------------------+| Field | Value |+-------------+----------------------------------+| description | OpenStack Image service || enabled | True || id | 178124d6081c441b80d79972614149c6 || name | glance || type | image |+-------------+----------------------------------+
● Create the Image service API endpoint$ openstack endpoint create \ --publicurl http://controller-glance:9292 \ --internalurl http://controller-glance:9292 \ --adminurl http://controller-glance:9292 \ --region RegionOne \ image+--------------+----------------------------------+| Field | Value |+--------------+----------------------------------+| adminurl | http://controller-glance:9292 || id | 805b1dbc90ab47479111102bc6423313 || internalurl | http://controller-glance:9292 || publicurl | http://controller-glance:9292 || region | RegionOne || service_id | 178124d6081c441b80d79972614149c6 || service_name | glance || service_type | image |+--------------+----------------------------------+
Add an image to Glance
● Richiesta del token da parte dell’utente glance$ openstack --os-auth-url http://controller-keystone:35357 / --os-project-domain-id default --os-user-domain-id default / --os-project-name service --os-username glance / --os-auth-type password token issue
+------------+----------------------------------+| Field | Value |+------------+----------------------------------+| expires | 2015-10-21T13:17:59.633219Z || id | 3a084565e9d749949f896b8de644f196 || project_id | 2d5b4dcf69ca45dea244035f09c51dbc || user_id | 2609a9cbb01a43c5bea84b6a7f401efd |+------------+----------------------------------+
● Request of the endpoint list$ openstack --os-token 3a084565e9d749949f896b8de644f196 \ --os-url http://controller-keystone:35357/v2.0 \ endpoint list+----------------------------------+-----------+--------------+--------------+| ID | Region | Service Name | Service Type |+----------------------------------+-----------+--------------+--------------+| fb6be6bc56dc4d79bab04ffa47c2abb0 | RegionOne | keystone | identity || d7547d6ee44c4353bfa3ee96689a8500 | RegionOne | glance | image |+----------------------------------+-----------+--------------+--------------+
● Request of endpoint of service glance$ openstack --os-token 3a084565e9d749949f896b8de644f196 \ --os-url http://controller-keystone:35357/v2.0 \ endpoint show glance
+--------------+----------------------------------+| Field | Value |+--------------+----------------------------------+| adminurl | http://controller-glance:9292 || enabled | True || id | d7547d6ee44c4353bfa3ee96689a8500 || internalurl | http://controller-glance:9292 || publicurl | http://controller-glance:9292 || region | RegionOne || service_id | db55294a40fd44e5994e3c6fb585c523 || service_name | glance || service_type | image |+--------------+----------------------------------+
● Upload the image to the Image service using the QCOW2 disk format, bare container format and public visibility so all projects can access it$ openstack --os-token 3a084565e9d749949f896b8de644f196 --os-url http://controller-glance:9292 \
image create --file /tmp/images/cirros-0.3.4-x86_64-disk.img \--disk-format qcow2 --container-format bare --public cirros-0.3.4-x86_64
+------------------+--------------------------------------+| Field | Value |+------------------+--------------------------------------+| checksum | ee1eca47dc88f4879d8a229cc70a07c6 || container_format | bare || created_at | 2015-10-21T10:40:12.000000 || deleted | False || deleted_at | None || disk_format | qcow2 || id | 57e1b12c-38ae-4190-940e-a4c1589377fc || is_public | True || min_disk | 0 || min_ram | 0 || name | cirros-0.3.4-x86_64 || owner | None || properties | {} || protected | False || size | 13287936 || status | active || updated_at | 2015-10-21T10:40:12.000000 || virtual_size | None |+------------------+--------------------------------------+
● Request of image list$ openstack --os-token 3a084565e9d749949f896b8de644f196 --os-url http://controller-glance:9292 image list
+--------------------------------------+---------------------+| ID | Name |+--------------------------------------+---------------------+| 57e1b12c-38ae-4190-940e-a4c1589377fc | cirros-0.3.4-x86_64 |+--------------------------------------+---------------------+
● Upload other image to the Image service$ openstack --os-token 3a084565e9d749949f896b8de644f196 --os-url http://controller-glance:9292
image create --file /tmp/images/Fedora-Cloud-Base-22-20150521.x86_64.qcow2 --disk-format qcow2 --container-format bare --publicFedora-Cloud-Base-22-20150521.x86_64
+------------------+--------------------------------------+| Field | Value |+------------------+--------------------------------------+| checksum | 18abc933d17f69d55ecea0d19f8f5c71 || container_format | bare || created_at | 2015-10-21T10:50:16.000000 || deleted | False || deleted_at | None || disk_format | qcow2 || id | 7953a831-b1d0-4675-af2a-92c2402ba7bd || is_public | True || min_disk | 0 || min_ram | 0 || name | Fedora-Cloud-Base-22-20150521.x86_64 || owner | None || properties | {} || protected | False || size | 228599296 || status | active || updated_at | 2015-10-21T10:50:20.000000 || virtual_size | None |+------------------+--------------------------------------+
● Request of image list$ openstack --os-token 3a084565e9d749949f896b8de644f196 --os-url http://controller-glance:9292 image list
+--------------------------------------+--------------------------------------+| ID | Name |+--------------------------------------+--------------------------------------+| 7953a831-b1d0-4675-af2a-92c2402ba7bd | Fedora-Cloud-Base-22-20150521.x86_64 || 57e1b12c-38ae-4190-940e-a4c1589377fc | cirros-0.3.4-x86_64 |+--------------------------------------+--------------------------------------+
Now try youYou must remember to update the repository
● Install the Ubuntu Cloud archive keyring and repository:# apt-get install ubuntu-cloud-keyring# echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu" \ "trusty-updates/kilo main" > /etc/apt/sources.list.d/cloudarchive-kilo.list
● Upgrade the packages on your system:# apt-get update && apt-get dist-upgrade
Now install openstackclient
● # apt-get install python-openstackclient
Edit /etc/hosts and add this row:
● # nano /etc/hosts <ip_host_keystone_controller> controller-keystone<ip_host_glance_controller> controller-glance
Replace <ip_host_keystone_controller> with IP address of OpenStack Identity ServiceReplace <ip_host_glance_controller> with IP address of OpenStack Image Service
For example:
<ip_host_keystone_controller> is 172.17.119.105
<ip_host_glance_controller> is 172.17.125.25
Create client environment script for admin user
● $ nano admin-creds
export OS_PROJECT_DOMAIN_ID=defaultexport OS_USER_DOMAIN_ID=defaultexport OS_PROJECT_NAME=adminexport OS_TENANT_NAME=adminexport OS_USERNAME=adminexport OS_PASSWORD=ADMIN_PASSexport OS_AUTH_URL=http://controller-keystone:35357/v3
Replace ADMIN_PASS with the password you chose for the admin user in the Identity service
● $ source admin-creds
Play with Keystone. Enjoy!
Example of command-line interface:
● openstack -h
● openstack user list
● openstack user show <user-name>
● openstack role list
● openstack role list --project <project-name> --user <user-name>
● openstack project list
● openstack project show <project-name>
● openstack endpoint list
● openstack endpoint show <service-name>
You create a user with your name
● $ openstack user create --password-prompt pippo
Add the admin role to the USER user and service project
● $ openstack role add --project service --user pippo admin
You unset creds
● $ nano unset
unset OS_PROJECT_DOMAIN_IDunset OS_USER_DOMAIN_IDunset OS_PROJECT_NAMEunset OS_TENANT_NAMEunset OS_USERNAMEunset OS_PASSWORDunset OS_AUTH_URL
● $ source unset
You create a creds script
● $ nano pippo-creds
export OS_PROJECT_DOMAIN_ID=defaultexport OS_USER_DOMAIN_ID=defaultexport OS_PROJECT_NAME=serviceexport OS_TENANT_NAME=serviceexport OS_USERNAME=pippoexport OS_PASSWORD=PIPPO_PASSexport OS_AUTH_URL=http://controller-keystone:35357/v3
Replace PIPPO_PASS with the password you chose for the pippo user in the Identity service
Get your token
● $ source pippo-creds● $ openstack token issue● $ source unset
List all image of glance service
● $ openstack --os-token YOUR_TOKEN --os-url http://controller-glance:9292 image list
Replace YOUR_TOKEN with your token
Topics
❖ Overview
❖ OpenStack Identity - Keystone
❖ Installation and first configuration of Keystone
❖ Workshop
Identity service configuration➢ Identity API protection with
RBAC➢ Use Trusts➢ Certificates for PKI
❖ Hierarchical Projects
❖ Identity API v3 client 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 RBACEach 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.
policy.json
Use TrustsOpenStack 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 depthDefines 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.
EndpointsA 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.
Certificates for PKITokens 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 PKITokens 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 CA2. Convert certificate and private key to PEM if needed3. 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 LDAPThe 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 bindingToken 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 layerOpenStack 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 CRUDIdentity 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.
● LoggingYou 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
❖ OpenStack Identity - Keystone
❖ Installation and first configuration of Keystone
❖ Workshop
❖ Identity service configuration➢ Identity API protection with
RBAC➢ Use Trusts➢ Certificates for PKI
Hierarchical Projects
❖ Identity API v3 client example
Hierarchical Projects: problem descriptionOpenStack 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
GroupsA 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
❖ OpenStack Identity - Keystone
❖ Installation and first configuration of Keystone
❖ Workshop
❖ Identity service configuration➢ Identity API protection with
RBAC➢ Use Trusts➢ Certificates for PKI
❖ Hierarchical Projects
Identity API v3 client example
KeystoneClient with v3 API
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 usLorenzo Carnevale Silvio Tavilla
www.linkedin.com/in/lorenzocarnevale
www.slideshare.net/LorenzoCarnevale
lorenzocarnevale silvio.tavilla
www.linkedin.com/in/silvio-tavilla-1b2b21110
