The Keystone identity service is the OpenStack service that provides the identity, authorization, and access management for all the OpenStack services. By default, it runs on controller nodes. You might need to perform additional configuration before you deploy this service.
Keystone provides a catalog service, which is a registry of the endpoint URLs that can be used to access the APIs for OpenStack services. When you deploy an OpenStack service, three API endpoint URLs are registered for the service in the Keystone catalog as follows:
Public URL: This URL is used by users and is typically available on a public network.
Admin URL: This URL is used by users that need administrator access to a service and is usually available on the internal management/API network. The administrator APIs for the OpenStack service are only available at this URL.
Internal URL: This URL is used for communication between OpenStack services and is usually available on the internal management/API network.
Before you deploy OpenStack services, you use the kollacli property set command to set the properties that configure the endpoint URLs. The following are the main properties to set.
-
network_interface The name of the network interface (for example,
em1) on all nodes which is connected to the internal management/API network.-
kolla_internal_vip_address An unused IP address on the internal management/API network.
In an OpenStack deployment, Keepalived manages this address as a virtual IP (VIP) address and assigns it to the
network_interfaceon one of the control nodes.-
kolla_external_vip_interface The name of the network interface (for example,
em3) on all control nodes which is connected to the public network.By default, this property is mapped to
network_interface.Caution: The interface must not be the same as the interface specified for the
neutron_external_interface.-
kolla_external_vip_address An unused IP address on a public network.
In an OpenStack deployment, Keepalived manages this address as a VIP address and assigns it to the
kolla_external_vip_interfaceon the control node that currently manages thekolla_internal_vip_address.By default, this property is mapped to
kolla_internal_vip_address.
The minimum properties you should set are
network_interface and
kolla_internal_vip address. With this
configuration, the same IP address on the internal
management/API network is used for all endpoint URLs.
To configure the public URL endpoint to be a different IP
address on a public network, set the
kolla_external_vip_interface and
kolla_external_vip_address properties.
If the nodes have differing network interface names, use group and host properties to set different interface names, see Section 4.5, “Setting Properties for Groups or Hosts”.
You can also use fully qualified DNS names for the endpoints
instead of IP addresses by setting the
kolla_internal_fqdn and
kolla_external_fqdn properties. By default,
these properties are mapped to the internal and external VIP
address. If you set these properties, you must configure your
DNS to ensure that the names resolve correctly to the internal
and external VIP address.
Another important component of an API endpoint URL is the
network port to use. The ports are fully configurable by setting
the appropriate
<service>_admin_port<service>_public_portkeystone_admin_port and 5000 for the
keystone_public_port. You only need to set
these properties if you want to change the default ports.
If you want to manually configure an endpoint for a service, you
can also do this by setting the
<service>_public_endpoint<service>_admin_endpoint<service>_internal_endpoint
Oracle OpenStack for Oracle Linux uses Keepalived and HAProxy to provide high availability and load balancing for the OpenStack service endpoints, see Section 4.15.1, “Service Endpoint High Availability With Keepalived and HAProxy”.
Many OpenStack services require a database to store information. Oracle OpenStack for Oracle Linux uses a MySQL database. Typically, when you deploy an OpenStack service, a database is created for the service and the credentials for the service admin user are registered with the Keystone service. You must set passwords for the database and the service admin user before you deploy OpenStack services otherwise the deployment fails.
You manage passwords with the kollacli password family of commands. You can set the passwords for individual services with the kollacli password set command:
$ kollacli password set password_nameThe following are the password names you might want to set individually:
database_password: The root password for the MySQL database.service_database_passwordservice_keystone_passwordkeystone_admin_password: The password for the Admin project user that performs administrative tasks in your OpenStack deployment.
For example, for the Nova service set the following passwords:
$ kollacli password set nova_database_password $ kollacli password set nova_keystone_password
The kollacli password set command prompts you for the password, and to confirm the password. The password value is not displayed on screen.
Alternatively, you can use the kollacli password init command to set all the passwords at once using random secure passwords.
If you set passwords individually using the kollacli password set command, it is best to run the kollacli password init command afterward as this command sets values for the password names that do not have a value.
The user name for the database and Keystone service users is the
name of the service by default, for example
nova for the Nova service. Normally you do
not need to change the user names, but you can configure them
with kollacli property set if you want. For example, the
nova_database_user and
nova_keystone_user properties contain the
user names for the Nova service.
If you want to clear a password, for example because you want generate a secure random password using kollacli password init, use the kollacli password set command to set an empty password. Do not use the kollacli password clear command as this removes both the password and the password name.
The passwords you set are stored in the
/etc/kolla/passwords.yml file on the
master node. The kollacli password command
is the only supported method for managing the passwords in
this file.
By default, the passwords.yml file is
read-writable only by the kolla user and
members of the kolla group. For security
reasons, you should restrict access to this user and group.
When setting passwords individually, it is best to use a random strong password generator to generate secure passwords. The kollacli password init generates strong random passwords for you.