"compute_extension:simple_tenant_usage:show": "rule:admin_or_owner", "compute_extension:simple_tenant_usage:list": "rule:admin_api", "compute_extension:users": "rule:admin_api", "compute_extension:virtual_interfaces": "role:compute-user", "compute_extension:virtual_storage_arrays": "role:compute-user", "compute_extension:volumes": "role:compute-user", "compute_extension:volume_attachments:index": "role:compute-user", "compute_extension:volume_attachments:show": "role:compute-user", "compute_extension:volume_attachments:create": "role:compute-user", "compute_extension:volume_attachments:delete": "role:compute-user", "compute_extension:volumetypes": "role:compute-user", "volume:create": "role:compute-user", "volume:get_all": "role:compute-user", "volume:get_volume_metadata": "role:compute-user", "volume:get_snapshot": "role:compute-user", "volume:get_all_snapshots": "role:compute-user", "network:get_all_networks": "role:compute-user", "network:get_network": "role:compute-user", "network:delete_network": "role:compute-user", "network:disassociate_network": "role:compute-user", "network:get_vifs_by_instance": "role:compute-user", "network:allocate_for_instance": "role:compute-user", "network:deallocate_for_instance": "role:compute-user", "network:validate_networks": "role:compute-user", "network:get_instance_uuids_by_ip_filter": "role:compute-user", "network:get_floating_ip": "role:compute-user", "network:get_floating_ip_pools": "role:compute-user", "network:get_floating_ip_by_address": "role:compute-user", "network:get_floating_ips_by_project": "role:compute-user", "network:get_floating_ips_by_fixed_address": "role:compute-user", "network:allocate_floating_ip": "role:compute-user", "network:deallocate_floating_ip": "role:compute-user", "network:associate_floating_ip": "role:compute-user", "network:disassociate_floating_ip": "role:compute-user", "network:get_fixed_ip": "role:compute-user", "network:add_fixed_ip_to_instance": "role:compute-user", "network:remove_fixed_ip_from_instance": "role:compute-user", "network:add_network_to_project": "role:compute-user", "network:get_instance_nw_info": "role:compute-user", "network:get_dns_domains": "role:compute-user", "network:add_dns_entry": "role:compute-user", "network:modify_dns_entry": "role:compute-user", "network:delete_dns_entry": "role:compute-user", "network:get_dns_entries_by_address": "role:compute-user", "network:get_dns_entries_by_name": "role:compute-user", "network:create_private_dns_domain": "role:compute-user", "network:create_public_dns_domain": "role:compute-user", "network:delete_dns_domain": "role:compute-user" }
Service management
The Identity Service provides identity, token, catalog, and policy services. It consists of: •keystone Web Server Gateway Interface (WSGI) service. Can be run in a
WSGI-capable web server such as Apache httpd to provide the Identity Service. The ser- vice and administrative APIs are run as separate instances of the WSGI service.
• Identity Service functions. Each has a pluggable back end that allows different ways to use the particular service. Most support standard back ends like LDAP or SQL.
•keystone-all. Starts both the service and administrative APIs in a single process. Using
federation with keystone-all is not supported. keystone-all is deprecated in favor of the WSGI service.
The Identity Service also maintains a user that corresponds to each service, such as, a user named nova for the Compute service, and a special service tenant called service.
For information about how to create services and endpoints, see the OpenStack Admin Us- er Guide.
Groups
A group is a collection of users. Administrators can create groups and add users to them. Then, rather than assign a role to each user individually, assign a role to the group. Every group is in a domain. 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
Note
The Identity service server might not allow all operations. For example, if using the Identity server with the LDAP Identity back end and group updates are dis- abled, then a request to create, delete, or update a group fails.
Here are a couple of examples:
• Group A is granted Role A on Tenant A. If User A is a member of Group A, when User A gets a token scoped to Tenant A, the token also includes Role A.
• Group B is granted Role B on Domain B. If User B is a member of Domain B, if User B gets a token scoped to Domain B, the token also includes Role B.
Certificates for PKI
PKI stands for Public Key Infrastructure. Tokens are documents, cryptographically signed us- ing the X509 standard. In order to work correctly token generation requires a public/pri- vate 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 the keystone-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 on-
ly be readable by the system user that will run the Identity Service.
Warning
The certificates can be world readable, but the private key cannot be. The pri- vate key should only be readable by the account that is going to sign tokens. When generating files with the keystone-manage pki_setup command, your best option is to run as the pki user. If you run keystone-manage as root, you can append --keystone-user and --keystone-group parameters to set the user name and group keystone is going to run under.
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/key- stone/ssl/certs/signing_cert.pem.
•keyfile - Location of private key used to sign tokens. Default is /etc/key- stone/ssl/private/signing_key.pem.
•ca_certs - Location of certificate for the authority that issued the above certificate. De-
fault 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. De-
fault is /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com.
When generating certificates with the keystone-manage pki_setup command, the
ca_key, key_size, and valid_days configuration options are used.
If the keystone-manage pki_setup command is not used to generate certificates, or you are providing your own certificates, these values do not need to be set.
If provider=keystone.token.providers.uuid.Provider
in the [token] section of the keystone configuration, a typi-
cal token looks like 53f7f6ef0cc344b5be706bcc8b1479e1. If
provider=keystone.token.providers.pki.Provider, a typical token is a much
MIIKtgYJKoZIhvcNAQcCoIIKpzCCCqMCAQExCTAHBgUrDgMCGjCCCY8GCSqGSIb3DQEHAaCCCYAEggl8eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNS0z MFQxNTo1MjowNi43MzMxOTgiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTMxVDE1OjUyOjA2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogbnVs bCwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYzJjNTliNGQzZDI4NGQ4ZmEwOWYxNjljYjE4MDBlMDYiLCAibmFtZSI6ICJkZW1vIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRw b2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTkyLjE2OC4yNy4xMDA6ODc3NC92Mi9jMmM1OWI0ZDNkMjg0ZDhmYTA5ZjE2OWNiMTgwMGUwNiIsICJyZWdpb24iOiAiUmVnaW9u T25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xOTIuMTY4LjI3LjEwMDo4Nzc0L3YyL2MyYzU5YjRkM2QyODRkOGZhMDlmMTY5Y2IxODAwZTA2IiwgImlkIjogIjFmYjMzYmM5M2Y5 ODRhNGNhZTk3MmViNzcwOTgzZTJlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTkyLjE2OC4yNy4xMDA6ODc3NC92Mi9jMmM1OWI0ZDNkMjg0ZDhmYTA5ZjE2OWNiMTgwMGUwNiJ9XSwg ImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xOTIuMTY4LjI3 LjEwMDozMzMzIiwgInJlZ2lvbiI6ICJSZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzE5Mi4xNjguMjcuMTAwOjMzMzMiLCAiaWQiOiAiN2JjMThjYzk1NWFiNDNkYjhm MGU2YWNlNDU4NjZmMzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjI3LjEwMDozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUi OiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTkyLjE2OC4yNy4xMDA6OTI5MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjog Imh0dHA6Ly8xOTIuMTY4LjI3LjEwMDo5MjkyIiwgImlkIjogIjczODQzNTJhNTQ0MjQ1NzVhM2NkOTVkN2E0YzNjZGY1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTkyLjE2OC4yNy4x MDA6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6 Ly8xOTIuMTY4LjI3LjEwMDo4Nzc2L3YxL2MyYzU5YjRkM2QyODRkOGZhMDlmMTY5Y2IxODAwZTA2IiwgInJlZ2lvbiI6ICJSZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDov LzE5Mi4xNjguMjcuMTAwOjg3NzYvdjEvYzJjNTliNGQzZDI4NGQ4ZmEwOWYxNjljYjE4MDBlMDYiLCAiaWQiOiAiMzQ3ZWQ2ZThjMjkxNGU1MGFlMmJiNjA2YWQxNDdjNTQiLCAicHVi bGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjI3LjEwMDo4Nzc2L3YxL2MyYzU5YjRkM2QyODRkOGZhMDlmMTY5Y2IxODAwZTA2In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBl IjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xOTIuMTY4LjI3LjEwMDo4NzczL3NlcnZpY2VzL0FkbWluIiwg InJlZ2lvbiI6ICJSZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzE5Mi4xNjguMjcuMTAwOjg3NzMvc2VydmljZXMvQ2xvdWQiLCAiaWQiOiAiMmIwZGMyYjNlY2U4NGJj YWE1NDAzMDMzNzI5YzY3MjIiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjI3LjEwMDo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0 eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xOTIuMTY4LjI3LjEwMDozNTM1Ny92Mi4wIiwgInJlZ2lvbiI6ICJS ZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzE5Mi4xNjguMjcuMTAwOjUwMDAvdjIuMCIsICJpZCI6ICJiNTY2Y2JlZjA2NjQ0ZmY2OWMyOTMxNzY2Yjc5MTIyOSIsICJw dWJsaWNVUkwiOiAiaHR0cDovLzE5Mi4xNjguMjcuMTAwOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0 b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZTVhMTM3NGE4YTRmNDI4NWIzYWQ3MzQ1MWU2MDY4YjEiLCAicm9sZXMi OiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsi YWRiODM3NDVkYzQzNGJhMzk5ODllNjBjOTIzYWZhMjgiLCAiMzM2ZTFiNjE1N2Y3NGFmZGJhNWUwYTYwMWUwNjM5MmYiXX19fTGB- zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYD VQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCAHLpsEs2R nouriuiCgFayIqCssK3SVdhOMINiuJtqv0sE-wBDFiEj-Prcudqlz-n+6q7VgV4mwMPszz39-rwp +P5l4AjrJasUm7FrO-4l02tPLaaZXU1gBQ1jUG5e5aL5jPDP08HbCWuX6wr-QQQB SrWY8lF3HrTcJT23sZIleg==
Sign certificate issued by external CA
You can use a signing certificate issued by an external CA instead of generated by key-
stone-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_password as 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
Request a signing certificate from an external CA
One way to request a signing certificate from an external CA is to first generate a PKCS #10 Certificate Request Syntax (CRS) using OpenSSL CLI.
Create a certificate request configuration file. For example, create the cert_req.conf
[ req ] default_bits = 1024 default_keyfile = keystonekey.pem default_md = sha1 prompt = no distinguished_name = distinguished_name [ distinguished_name ] countryName = US stateOrProvinceName = CA localityName = Sunnyvale organizationName = OpenStack organizationalUnitName = Keystone
commonName = Keystone Signing emailAddress = [email protected]
Then generate a CRS with OpenSSL CLI. Do not encrypt the generated private key. Must
use the -nodes option.
For example:
$ openssl req -newkey rsa:1024 -keyout signing_key.pem -keyform PEM \ -out signing_cert_req.pem -outform PEM -config cert_req.conf -nodes
If everything is successful, you should end up with signing_cert_req.pem and
signing_key.pem. Send signing_cert_req.pem to your CA to request a token sign-
ing certificate and make sure to ask the certificate to be in PEM format. Also, make sure your trusted CA certificate chain is also in PEM format.
Install an external signing certificate
Assuming you have the following already:•signing_cert.pem - (Keystone token) signing certificate in PEM format
•signing_key.pem - corresponding (non-encrypted) private key in PEM format
•cacert.pem - trust CA certificate chain in PEM format
Copy the above to your certificate directory. For example: # mkdir -p /etc/keystone/ssl/certs # cp signing_cert.pem /etc/keystone/ssl/certs/ # cp signing_key.pem /etc/keystone/ssl/certs/ # cp cacert.pem /etc/keystone/ssl/certs/ # chmod -R 700 /etc/keystone/ssl/certs
Note
Make sure the certificate directory is only accessible by root.
Note
The procedure of copying the key and cert files may be improved if done after first running keystone-manage pki_setup since this command also creates oth- er needed files, such as the index.txt and serial files.
Also, when copying the necessary files to a different server for replicating the functionality, the entire directory of files is needed, not just the key and cert files.
If your certificate directory path is different from the default /etc/keystone/ssl/ certs, make sure it is reflected in the [signing] section of the configuration file.
Configure the Identity Service with SSL
You can configure the Identity Service to support two-way SSL. You must obtain the x509 certificates externally and configure them.The Identity Service provides a set of sample certificates in the examples/pki/certs and examples/pki/private directories:
Certificate types
cacert.pem Certificate Authority chain to validate against.
ssl_cert.pem Public certificate for Identity Service server.
middleware.pem Public and private certificate for Identity Service middleware/client.
cakey.pem Private key for the CA.
ssl_key.pem Private key for the Identity Service server.
Note
You can choose names for these certificates. You can also combine the pub- lic/private keys in the same file, if you wish. These certificates are provided as an example.
Client authentication with keystone-all
When running keystone-all, the server can be configured to enable SSL with client authenti- cation using the following instructions. Modify the [eventlet_server_ssl] section in
the etc/keystone.conf file. The following SSL configuration example uses the included
sample certificates: [eventlet_server_ssl] enable = True
certfile = <path to keystone.pem> keyfile = <path to keystonekey.pem> ca_certs = <path to ca.pem>
cert_required = True
Options
•enable. True enables SSL. Default is False.
•keyfile. Path to the Identity Service private certificate file. If you include the private
key in the certfile, you can omit the keyfile. •ca_certs. Path to the CA trust chain.
•cert_required. Requires client certificate. Default is False.
When running the Identity Service as a WSGI service in a web server such as Apache httpd, this configuration is done in the web server instead. In this case the options in the
[eventlet_server_ssl] section are ignored.
External authentication with Identity
When Identity runs in apache-httpd, you can use external authentication methods that
differ from the authentication provided by the identity store back end. For example, you can use an SQL identity back end together with X.509 authentication and Kerberos, instead of using the user name and password combination.
Use HTTPD authentication
Web servers, like Apache HTTP, support many methods of authentication. Identity can al- low the web server to perform the authentication. The web server then passes the authen- ticated user to Identity by using the REMOTE_USER environment variable. This user must al-
ready exist in the Identity back end to get a token from the controller. To use this method, Identity should run on apache-httpd.
Use X.509
The following Apache configuration snippet authenticates the user based on a valid X.509 certificate from a known CA:
<VirtualHost _default_:5000> SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl.cert SSLCertificateKeyFile /etc/ssl/private/ssl.key SSLCACertificatePath /etc/ssl/allowed_cas SSLCARevocationPath /etc/ssl/allowed_cas SSLUserName SSL_CLIENT_S_DN_CN SSLVerifyClient require SSLVerifyDepth 10 (...) </VirtualHost>
Integrate Identity with LDAP
The Openstack Identity Service supports integration with existing LDAP directories for au- thentication and authorization services.
When the Openstack Identity service is configured to use LDAP back ends, you can split au- thentication (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 Assignments feature enables administrators to manage project role authorization using the Openstack Identity service SQL database, while providing user authentication through the LDAP directory.
Important
For OpenStack Identity service to access LDAP servers, you must enable the
authlogin_nsswitch_use_ldap boolean value for SELinux on the Open-
stack Identity server. To enable and make the option persistent across reboots: # setsebool -P authlogin_nsswitch_use_ldap
Identity configuration is split into two separate back ends: identity (back end for users and groups) and assignments (back end for domains, projects, roles, role assignments). To con- figure identity, set options in the /etc/keystone/keystone.conf file. See the section
called “Integrate identity back end with LDAP” [32] for identity back end configuration examples and the section called “Integrate assignment back end with LDAP” [35] for as- signment back end configuration examples. Modify these examples as needed.
Note
Multiple back ends are supported. You can integrate the Openstack Identity service with a single LDAP server (configure both identity and assignments to LDAP, or set identity and assignments back end with SQL or LDAP), or multiple back ends using domain-specific configuration files.
To define the destination LDAP server. Define the destination LDAP server in the
keystone.conf file: [ldap] url = ldap://localhost user = dc=Manager,dc=example,dc=org password = samplepassword suffix = dc=example,dc=org use_dumb_member = False allow_subtree_delete = False
Note
Configure dumb_member if you set use_dumb_member to true.
[ldap]
dumb_member = cn=dumb,dc=nonexistent
Additional LDAP integration settings. Set these options in the /etc/key- stone/keystone.conf file for a single LDAP server, or /etc/keystone/do- mains/keystone.DOMAIN_NAME.conf files for multiple back ends.
Query option Use query_scope to control the scope level of data
presented (search only the first level or search an entire sub-tree) through LDAP.
Use page_size to control the maximum results per
page. A value of zero disables paging.
Use alias_dereferencing to control the LDAP
dereferencing option for queries.
Use chase_referrals to override the system's de-
fault referral chasing behavior for queries. [ldap]
query_scope = sub page_size = 0
alias_dereferencing = default chase_referrals =
Debug Use debug_level to set the LDAP debugging level for
LDAP calls. A value of zero means that debugging is not enabled.
[ldap]
debug_level = 0
Warning
This value is a bitmask, consult your LDAP documentation for possible values.
Connection pooling Use use_pool to enable LDAP connection pooling.
Configure connection pool size, maximum retry, recon- nect trials, timeout (-1 indicates indefinite wait) and life- time in seconds. [ldap] use_pool = true pool_size = 10 pool_retry_max = 3 pool_retry_delay = 0.1 pool_connection_timeout = -1 pool_connection_lifetime = 600
Connection pooling for end us- er authentication
Use use_auth_pool to enable LDAP connection pool-
ing for end user authentication. Configure connection pool size and lifetime in seconds.
[ldap]
use_auth_pool = false auth_pool_size = 100
auth_pool_connection_lifetime = 60
When you have finished configuration, restart the Openstack Identity service: # service keystone restart
Warning
Integrate identity back end with LDAP
The identity back end contains information for users, groups, and group member lists. In- tegrating the identity back end with LDAP allows administrators to use users and groups in LDAP.
Important
For OpenStack Identity Service to access LDAP servers, you must define the des- tination LDAP server in the keystone.conf file. For more information, see