83dc547d67
Keystone removed support for writable LDAP backends in Ocata. Prior to that it was deprecated for several releases. This commit removes references to those configuration options since they are silently ignored. This cleans up the configuration files and doesn't give the impression that functionality is still supported. Relevant release notes that advertize the removal: https://docs.openstack.org/releasenotes/keystone/ocata.html#relnotes-11-0-0-origin-stable-ocata-other-notes Change-Id: Id05247d004ee7d189dff3ec867a6ec11dfc40e9b
111 lines
4.4 KiB
ReStructuredText
111 lines
4.4 KiB
ReStructuredText
======================================================
|
|
Configuring the Identity service (keystone) (optional)
|
|
======================================================
|
|
|
|
Customize your keystone deployment in
|
|
``/etc/openstack_deploy/user_variables.yml``.
|
|
|
|
|
|
Securing keystone communication with SSL certificates
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The OpenStack-Ansible project provides the ability to secure keystone
|
|
communications with self-signed or user-provided SSL certificates. By default,
|
|
self-signed certificates are in use. However, you can
|
|
provide your own certificates by using the following Ansible variables in
|
|
``/etc/openstack_deploy/user_variables.yml``:
|
|
|
|
.. code-block:: yaml
|
|
|
|
keystone_user_ssl_cert: # Path to certificate
|
|
keystone_user_ssl_key: # Path to private key
|
|
keystone_user_ssl_ca_cert: # Path to CA certificate
|
|
|
|
.. note::
|
|
|
|
If you are providing certificates, keys, and CA file for a
|
|
CA without chain of trust (or an invalid/self-generated ca), the variables
|
|
``keystone_service_internaluri_insecure`` and
|
|
``keystone_service_adminuri_insecure`` should be set to ``True``.
|
|
|
|
Refer to :deploy_guide:`Securing services with SSL certificates
|
|
<app-advanced-config-sslcertificates.html>`
|
|
for more information on these configuration options and how you can provide
|
|
your own certificates and keys to use with keystone.
|
|
|
|
Implementing LDAP (or Active Directory) backends
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
You can use the built-in keystone support for services if you already have
|
|
LDAP or Active Directory (AD) infrastructure on your deployment.
|
|
Keystone uses the existing users, groups, and user-group relationships to
|
|
handle authentication and access control in an OpenStack deployment.
|
|
|
|
.. note::
|
|
|
|
We do not recommend configuring the default domain in keystone to use
|
|
LDAP or AD identity backends. Create additional domains
|
|
in keystone and configure either LDAP or active directory backends for
|
|
that domain.
|
|
|
|
This is critical in situations where the identity backend cannot
|
|
be reached due to network issues or other problems. In those situations,
|
|
the administrative users in the default domain would still be able to
|
|
authenticate to keystone using the default domain which is not backed by
|
|
LDAP or AD.
|
|
|
|
You can add domains with LDAP backends by adding variables in
|
|
``/etc/openstack_deploy/user_variables.yml``. For example, this dictionary
|
|
adds a new keystone domain called ``Users`` that is backed by an LDAP server:
|
|
|
|
.. code-block:: yaml
|
|
|
|
keystone_ldap:
|
|
Users:
|
|
url: "ldap://10.10.10.10"
|
|
user: "root"
|
|
password: "secrete"
|
|
|
|
Adding the YAML block above causes the keystone playbook to create a
|
|
``/etc/keystone/domains/keystone.Users.conf`` file within each keystone service
|
|
container that configures the LDAP-backed domain called ``Users``.
|
|
|
|
You can create more complex configurations that use LDAP filtering and
|
|
consume LDAP as a read-only resource. The following example shows how to apply
|
|
these configurations:
|
|
|
|
.. code-block:: yaml
|
|
|
|
keystone_ldap:
|
|
MyCorporation:
|
|
url: "ldaps://ldap.example.com"
|
|
user_tree_dn: "ou=Users,o=MyCorporation"
|
|
group_tree_dn: "cn=openstack-users,ou=Users,o=MyCorporation"
|
|
user_objectclass: "inetOrgPerson"
|
|
user_id_attribute: "cn"
|
|
user_name_attribute: "uid"
|
|
user_filter: "(groupMembership=cn=openstack-users,ou=Users,o=MyCorporation)"
|
|
|
|
In the `MyCorporation` example above, keystone uses the LDAP server as a
|
|
read-only resource. The configuration also ensures that keystone filters the
|
|
list of possible users to the ones that exist in the
|
|
``cn=openstack-users,ou=Users,o=MyCorporation`` group.
|
|
|
|
Horizon offers multi-domain support that can be enabled with an Ansible
|
|
variable during deployment:
|
|
|
|
.. code-block:: yaml
|
|
|
|
horizon_keystone_multidomain_support: True
|
|
|
|
Enabling multi-domain support in horizon adds the ``Domain`` input field on
|
|
the horizon login page and it adds other domain-specific features in the
|
|
keystone section.
|
|
|
|
More details regarding valid configuration for the LDAP Identity backend can
|
|
be found in the `Keystone Developer Documentation`_ and the
|
|
`OpenStack Administrator Guide`_.
|
|
|
|
.. _Keystone Developer Documentation: https://docs.openstack.org/keystone/latest/configuration.html#configuring-the-ldap-identity-provider
|
|
.. _OpenStack Administrator Guide: https://docs.openstack.org/keystone/latest/admin/identity-integrate-with-ldap.html
|