More configuration doc edits
* Keystone -> keystone * Remove mention of non-existant keystone.common.cache.backends.mongo * Correct that global caching is enabled by default, not disabled. * Remove LDAP schema examples for Project and Roles * Mark several tls config options as keywords using `` * Update the example LDAP pooling config options to match keystone.conf Change-Id: I1e3e896d447c1cbd187d21719f42dad6bf00b28b
This commit is contained in:
Eric Brown
parent
3c41421596
commit
e3962e5f1b
|
|
@ -23,12 +23,12 @@ Configuring Keystone
|
|||
|
||||
man/keystone-manage
|
||||
|
||||
Once Keystone is installed, it is configured via a primary configuration file
|
||||
Once keystone is installed, it is configured via a primary configuration file
|
||||
(``etc/keystone.conf``), a PasteDeploy configuration file
|
||||
(``etc/keystone-paste.ini``), possibly a separate logging configuration file,
|
||||
and initializing data into Keystone using the command line client.
|
||||
and initializing data into keystone using the command line client.
|
||||
|
||||
By default, Keystone starts a service on `IANA-assigned port 35357
|
||||
By default, keystone starts a service on `IANA-assigned port 35357
|
||||
<http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt>`_.
|
||||
This may overlap with your system's ephemeral port range, so another process
|
||||
may already be using this port without being explicitly configured to do so. To
|
||||
|
|
@ -47,7 +47,7 @@ To make the above change persistent,
|
|||
Configuration Files
|
||||
===================
|
||||
|
||||
The Keystone configuration files are an ``ini`` file format based on Paste_, a
|
||||
The keystone configuration files are an ``ini`` file format based on Paste_, a
|
||||
common system used to configure Python WSGI based applications. The PasteDeploy
|
||||
configuration entries (WSGI pipeline definitions) can be provided in a separate
|
||||
``keystone-paste.ini`` file, while general and driver-specific configuration
|
||||
|
|
@ -95,10 +95,10 @@ The primary configuration file is organized into the following sections:
|
|||
* ``[tokenless_auth]`` - Tokenless authentication configuration
|
||||
* ``[trust]`` - Trust configuration
|
||||
|
||||
The Keystone primary configuration file is expected to be named
|
||||
``keystone.conf``. When starting Keystone, you can specify a different
|
||||
The keystone primary configuration file is expected to be named
|
||||
``keystone.conf``. When starting keystone, you can specify a different
|
||||
configuration file to use with ``--config-file``. If you do **not** specify a
|
||||
configuration file, Keystone will look in the following directories for a
|
||||
configuration file, keystone will look in the following directories for a
|
||||
configuration file, in order:
|
||||
|
||||
* ``~/.keystone/``
|
||||
|
|
@ -108,7 +108,7 @@ configuration file, in order:
|
|||
|
||||
PasteDeploy configuration file is specified by the ``config_file`` parameter in
|
||||
``[paste_deploy]`` section of the primary configuration file. If the parameter
|
||||
is not an absolute path, then Keystone looks for it in the same directories as
|
||||
is not an absolute path, then keystone looks for it in the same directories as
|
||||
above. If not specified, WSGI pipeline definitions are loaded from the primary
|
||||
configuration file.
|
||||
|
||||
|
|
@ -144,7 +144,7 @@ following options:
|
|||
domain_config_dir = /etc/keystone/domains
|
||||
|
||||
Setting ``domain_specific_drivers_enabled`` to ``True`` will enable this
|
||||
feature, causing Keystone to look in the ``domain_config_dir`` for config files
|
||||
feature, causing keystone to look in the ``domain_config_dir`` for config files
|
||||
of the form::
|
||||
|
||||
keystone.<domain_name>.conf
|
||||
|
|
@ -241,7 +241,7 @@ specifying the domain name:
|
|||
|
||||
.. NOTE::
|
||||
|
||||
Although Keystone supports multiple LDAP backends via the above
|
||||
Although keystone supports multiple LDAP backends via the above
|
||||
domain-specific configuration methods, it currently only supports one SQL
|
||||
backend. This could be either the default driver or a single
|
||||
domain-specific backend, perhaps for storing service users in a
|
||||
|
|
@ -254,24 +254,24 @@ specifying the domain name:
|
|||
API instead.
|
||||
|
||||
Due to the need for user and group IDs to be unique across an OpenStack
|
||||
installation and for Keystone to be able to deduce which domain and backend to
|
||||
installation and for keystone to be able to deduce which domain and backend to
|
||||
use from just a user or group ID, it dynamically builds a persistent identity
|
||||
mapping table from a public ID to the actual domain, local ID (within that
|
||||
backend) and entity type. The public ID is automatically generated by Keystone
|
||||
backend) and entity type. The public ID is automatically generated by keystone
|
||||
when it first encounters the entity. If the local ID of the entity is from a
|
||||
backend that does not guarantee to generate UUIDs, a hash algorithm will
|
||||
generate a public ID for that entity, which is what will be exposed by
|
||||
Keystone.
|
||||
keystone.
|
||||
|
||||
The use of a hash will ensure that if the public ID needs to be regenerated
|
||||
then the same public ID will be created. This is useful if you are running
|
||||
multiple keystones and want to ensure the same ID would be generated whichever
|
||||
server you hit.
|
||||
|
||||
While Keystone will dynamically maintain the identity mapping, including
|
||||
removing entries when entities are deleted via the Keystone, for those entities
|
||||
in backends that are managed outside of Keystone (e.g. a Read Only LDAP),
|
||||
Keystone will not know if entities have been deleted and hence will continue to
|
||||
While keystone will dynamically maintain the identity mapping, including
|
||||
removing entries when entities are deleted via the keystone, for those entities
|
||||
in backends that are managed outside of keystone (e.g. a read-only LDAP),
|
||||
keystone will not know if entities have been deleted and hence will continue to
|
||||
carry stale identity mappings in its table. While benign, keystone provides an
|
||||
ability for operators to purge the mapping table of such stale entries using
|
||||
the keystone-manage command, for example:
|
||||
|
|
@ -281,7 +281,7 @@ the keystone-manage command, for example:
|
|||
$ keystone-manage mapping_purge --domain-name DOMAINA --local-id abc@de.com
|
||||
|
||||
A typical usage would be for an operator to obtain a list of those entries in
|
||||
an external backend that had been deleted out-of-band to Keystone, and then
|
||||
an external backend that had been deleted out-of-band to keystone, and then
|
||||
call keystone-manage to purge those entries by specifying the domain and
|
||||
local-id. The type of the entity (i.e. user or group) may also be specified if
|
||||
this is needed to uniquely identify the mapping.
|
||||
|
|
@ -320,9 +320,9 @@ sha256 generator as default, which produces regeneratable public IDs. The
|
|||
generator algorithm for public IDs is a balance between key size (i.e. the
|
||||
length of the public ID), the probability of collision and, in some
|
||||
circumstances, the security of the public ID. The maximum length of public ID
|
||||
supported by Keystone is 64 characters, and the default generator (sha256) uses
|
||||
supported by keystone is 64 characters, and the default generator (sha256) uses
|
||||
this full capability. Since the public ID is what is exposed externally by
|
||||
Keystone and potentially stored in external systems, some installations may
|
||||
keystone and potentially stored in external systems, some installations may
|
||||
wish to make use of other generator algorithms that have a different trade-off
|
||||
of attributes. A different generator can be installed by configuring the
|
||||
following property:
|
||||
|
|
@ -341,7 +341,7 @@ Authentication Plugins
|
|||
|
||||
.. NOTE::
|
||||
|
||||
This feature is only supported by Keystone for the Identity API v3 clients.
|
||||
This feature is only supported by keystone for the Identity API v3 clients.
|
||||
|
||||
Keystone supports authentication plugins and they are specified in the
|
||||
``[auth]`` section of the configuration file. However, an authentication plugin
|
||||
|
|
@ -366,7 +366,7 @@ All authentication plugins must extend the
|
|||
``authenticate()`` method. The ``authenticate()`` method expects the following
|
||||
parameters.
|
||||
|
||||
* ``context`` - Keystone's request context
|
||||
* ``context`` - keystone's request context
|
||||
* ``auth_payload`` - the content of the authentication for a given method
|
||||
* ``auth_context`` - user authentication context, a dictionary shared by all
|
||||
plugins. It contains ``method_names`` and ``extras`` by default.
|
||||
|
|
@ -416,7 +416,7 @@ specified in the ``[token]`` section of the configuration file. Keystone
|
|||
provides three non-test persistence backends. These can be set with the
|
||||
``[token] driver`` configuration option.
|
||||
|
||||
The drivers Keystone provides are:
|
||||
The drivers keystone provides are:
|
||||
|
||||
* ``memcache_pool`` - The pooled memcached token persistence engine. This
|
||||
backend supports the concept of pooled memcache client object (allowing for
|
||||
|
|
@ -430,7 +430,7 @@ The drivers Keystone provides are:
|
|||
* ``memcache`` - The memcached based token persistence backend. This backend
|
||||
relies on ``dogpile.cache`` and stores the token data in a set of memcached
|
||||
servers. The servers URLs are specified in the ``[memcache] servers``
|
||||
configuration option in the Keystone config. Implemented by
|
||||
configuration option in the keystone config. Implemented by
|
||||
:class:`keystone.token.persistence.backends.memcache.Token`
|
||||
|
||||
|
||||
|
|
@ -505,8 +505,7 @@ which allows for flexible cache backends. The majority of the caching
|
|||
configuration options are set in the ``[cache]`` section. However, each section
|
||||
that has the capability to be cached usually has a ``caching`` boolean value
|
||||
that will toggle caching for that specific section. The current default
|
||||
behavior is that subsystem caching is enabled, but the global toggle is set to
|
||||
disabled.
|
||||
behavior is that global and subsystem caching is enabled.
|
||||
|
||||
``[cache]`` configuration section:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
@ -519,7 +518,7 @@ disabled.
|
|||
|
||||
.. NOTE::
|
||||
A given ``backend`` must be registered with ``dogpile.cache`` before it
|
||||
can be used. The default backend is the ``Keystone`` no-op backend
|
||||
can be used. The default backend is the keystone no-op backend
|
||||
(``keystone.common.cache.noop``). If caching is desired a different
|
||||
backend will need to be specified. Current functional backends are:
|
||||
|
||||
|
|
@ -544,7 +543,7 @@ disabled.
|
|||
in the store can be inadvertently changed without extra layers of
|
||||
data protection added), and does not share cache between processes.
|
||||
This means that caching and cache invalidation will not be
|
||||
consistent or reliable when using ``Keystone`` and the
|
||||
consistent or reliable when using ``keystone`` and the
|
||||
``dogpile.cache.memory`` backend under any real workload.
|
||||
|
||||
* ``expiration_time`` - int, the default length of time to cache a specific
|
||||
|
|
@ -558,12 +557,12 @@ disabled.
|
|||
* ``proxies`` - comma delimited list of `ProxyBackends`_ e.g.
|
||||
``my.example.Proxy, my.example.Proxy2``
|
||||
|
||||
Current Keystone systems that have caching capabilities:
|
||||
Current keystone systems that have caching capabilities:
|
||||
* ``token``
|
||||
The token system has a separate ``cache_time`` configuration option,
|
||||
that can be set to a value above or below the global
|
||||
``expiration_time`` default, allowing for different caching behavior
|
||||
from the other systems in ``Keystone``. This option is set in the
|
||||
from the other systems in keystone. This option is set in the
|
||||
``[token]`` section of the configuration file.
|
||||
|
||||
The Token Revocation List cache time is handled by the configuration
|
||||
|
|
@ -575,7 +574,7 @@ Current Keystone systems that have caching capabilities:
|
|||
The resource system has a separate ``cache_time`` configuration option,
|
||||
that can be set to a value above or below the global
|
||||
``expiration_time`` default, allowing for different caching behavior
|
||||
from the other systems in ``Keystone``. This option is set in the
|
||||
from the other systems in keystone. This option is set in the
|
||||
``[resource]`` section of the configuration file.
|
||||
|
||||
Currently ``resource`` has caching for ``project`` and ``domain``
|
||||
|
|
@ -599,7 +598,7 @@ Current Keystone systems that have caching capabilities:
|
|||
The role system has a separate ``cache_time`` configuration option,
|
||||
that can be set to a value above or below the global ``expiration_time``
|
||||
default, allowing for different caching behavior from the other systems in
|
||||
``Keystone``. This option is set in the ``[role]`` section of the
|
||||
keystone. This option is set in the ``[role]`` section of the
|
||||
configuration file.
|
||||
|
||||
.. WARNING::
|
||||
|
|
@ -618,7 +617,6 @@ For more information about the different backends (and configuration options):
|
|||
* `dogpile.cache.backends.memcached`_
|
||||
* `dogpile.cache.backends.redis`_
|
||||
* `dogpile.cache.backends.file`_
|
||||
* :py:mod:`keystone.common.cache.backends.mongo`
|
||||
|
||||
.. _`dogpile.cache`: http://dogpilecache.readthedocs.org/en/latest/
|
||||
.. _`python-memcached`: http://www.tummy.com/software/python-memcached/
|
||||
|
|
@ -642,9 +640,9 @@ signed in an X509 certificate, and the certificate used to sign it must be
|
|||
available as Certificate Authority (CA) certificate. These files can be either
|
||||
externally generated or generated using the ``keystone-manage`` utility.
|
||||
|
||||
The files used for signing and verifying certificates are set in the Keystone
|
||||
The files used for signing and verifying certificates are set in the keystone
|
||||
configuration file. The private key should only be readable by the system user
|
||||
that will run Keystone. The values that specify the certificates are under the
|
||||
that will run keystone. The values that specify 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
|
||||
|
|
@ -750,8 +748,8 @@ not use ``keystone-manage pki_setup`` in a production environment. In
|
|||
production, an external CA should be used instead. This is because the CA
|
||||
secret key should generally be kept apart from the token signing secret keys so
|
||||
that a compromise of a node does not lead to an attacker being able to generate
|
||||
valid signed Keystone tokens. This is a low probability attack vector, as
|
||||
compromise of a Keystone service machine's filesystem security almost certainly
|
||||
valid signed keystone tokens. This is a low probability attack vector, as
|
||||
compromise of a keystone service machine's filesystem security almost certainly
|
||||
means the attacker will be able to gain direct access to the token backend.
|
||||
|
||||
When using the ``keystone-manage pki_setup`` to generate the certificates, the
|
||||
|
|
@ -784,11 +782,11 @@ following states:
|
|||
time. This key will become the *primary* during the *next* key rotation. This
|
||||
key is only used to validate tokens and serves to avoid race conditions in
|
||||
multi-node deployments (all nodes should recognize all *primary* keys in the
|
||||
deployment at all times). In a multi-node Keystone deployment this would
|
||||
allow for the *staged* key to be replicated to all Keystone nodes before
|
||||
deployment at all times). In a multi-node keystone deployment this would
|
||||
allow for the *staged* key to be replicated to all keystone nodes before
|
||||
being promoted to *primary* on a single node. This prevents the case where a
|
||||
*primary* key is created on one Keystone node and tokens encrypted/signed with
|
||||
that new *primary* are rejected on another Keystone node because the new
|
||||
*primary* key is created on one keystone node and tokens encrypted/signed with
|
||||
that new *primary* are rejected on another keystone node because the new
|
||||
*primary* doesn't exist there yet.
|
||||
|
||||
* **Primary key**: In a key rotation, the old *staged* key is promoted to be
|
||||
|
|
@ -842,7 +840,7 @@ To build your service catalog using this driver, see the built-in help:
|
|||
$ openstack help service create
|
||||
$ openstack help endpoint create
|
||||
|
||||
You can also refer to `an example in Keystone (tools/sample_data.sh)
|
||||
You can also refer to `an example in keystone (tools/sample_data.sh)
|
||||
<https://git.openstack.org/cgit/openstack/keystone/tree/tools/sample_data.sh>`_.
|
||||
|
||||
File-based Service Catalog (``templated.Catalog``)
|
||||
|
|
@ -869,7 +867,7 @@ catalog will not change very much over time.
|
|||
|
||||
The value of ``template_file`` is expected to be an absolute path to your
|
||||
service catalog configuration. An example ``template_file`` is included in
|
||||
Keystone, however you should create your own to reflect your deployment.
|
||||
keystone, however you should create your own to reflect your deployment.
|
||||
|
||||
Another such example is `available in devstack
|
||||
(files/default_catalog.templates)
|
||||
|
|
@ -906,13 +904,13 @@ api-ref/identity/v3-ext/#os-ep-filter-api>`_ for the details of API definition.
|
|||
Logging
|
||||
-------
|
||||
|
||||
Logging is configured externally to the rest of Keystone. Configure the path to
|
||||
Logging is configured externally to the rest of keystone. Configure the path to
|
||||
your logging configuration file using the ``[DEFAULT] log_config_append``
|
||||
option of ``keystone.conf``. If you wish to route all your logging through
|
||||
syslog, set the ``[DEFAULT] use_syslog`` option.
|
||||
|
||||
A sample ``log_config_append`` file is included with the project at
|
||||
``etc/logging.conf.sample``. Like other OpenStack projects, Keystone uses the
|
||||
``etc/logging.conf.sample``. Like other OpenStack projects, keystone uses the
|
||||
`Python logging module`_, which includes extensive configuration options for
|
||||
choosing the output levels and formats.
|
||||
|
||||
|
|
@ -922,13 +920,13 @@ choosing the output levels and formats.
|
|||
SSL
|
||||
---
|
||||
|
||||
A secure deployment should have Keystone running in a web server (such as
|
||||
A secure deployment should have keystone running in a web server (such as
|
||||
Apache httpd), or behind an SSL terminator.
|
||||
|
||||
User CRUD additions for the V2.0 API
|
||||
------------------------------------
|
||||
|
||||
For the V2.0 API, Keystone provides an additional capability that allows users
|
||||
For the V2.0 API, keystone provides an additional capability that allows users
|
||||
to use a HTTP PATCH to change their own password.
|
||||
|
||||
Each user can then change their own password with a HTTP PATCH :
|
||||
|
|
@ -1146,7 +1144,7 @@ can run with both options set to ``strict`` as soon as is practical.
|
|||
Sample Configuration Files
|
||||
--------------------------
|
||||
|
||||
The ``etc/`` folder distributed with Keystone contains example configuration
|
||||
The ``etc/`` folder distributed with keystone contains example configuration
|
||||
files for each Server application.
|
||||
|
||||
* ``etc/keystone.conf.sample``
|
||||
|
|
@ -1160,12 +1158,12 @@ files for each Server application.
|
|||
Keystone API protection with Role Based Access Control (RBAC)
|
||||
=============================================================
|
||||
|
||||
Like most OpenStack projects, Keystone supports the protection of its APIs by
|
||||
Like most OpenStack projects, keystone supports the protection of its APIs by
|
||||
defining policy rules based on an RBAC approach. These are stored in a JSON
|
||||
policy file, the name and location of which is set in the main Keystone
|
||||
policy file, the name and location of which is set in the main keystone
|
||||
configuration file.
|
||||
|
||||
Each Keystone v3 API has a line in the policy file which dictates what level of
|
||||
Each keystone v3 API has a line in the policy file which dictates what level of
|
||||
protection is applied to it, where each line is of the form::
|
||||
|
||||
<api name>: <rule statement> or <match statement>
|
||||
|
|
@ -1326,8 +1324,8 @@ return an empty list from your new database):
|
|||
.. NOTE::
|
||||
|
||||
We're providing the default OS_TOKEN and OS_URL values from
|
||||
``keystone.conf`` to connect to the Keystone service. If you changed those
|
||||
values, or deployed Keystone to a different endpoint, you will need to
|
||||
``keystone.conf`` to connect to the keystone service. If you changed those
|
||||
values, or deployed keystone to a different endpoint, you will need to
|
||||
change the provided command accordingly.
|
||||
|
||||
Initializing Keystone
|
||||
|
|
@ -1359,7 +1357,7 @@ information.
|
|||
The private key used for token signing can only be read by its owner. This
|
||||
prevents unauthorized users from spuriously signing tokens.
|
||||
``keystone-manage pki_setup`` Should be run as the same system user that will
|
||||
be running the Keystone service to ensure proper ownership for the private key
|
||||
be running the keystone service to ensure proper ownership for the private key
|
||||
file and the associated certificates.
|
||||
|
||||
Adding Users, Projects, and Roles via Command Line Interfaces
|
||||
|
|
@ -1371,7 +1369,7 @@ rules require admin credentials to administer ``users``, ``projects``, and
|
|||
`Keystone API protection with Role Based Access Control (RBAC)`_ for more
|
||||
details on policy files.
|
||||
|
||||
The Keystone command line interface packaged in `python-keystoneclient`_ only
|
||||
The keystone command line interface packaged in `python-keystoneclient`_ only
|
||||
supports the Identity v2.0 API. The OpenStack common command line interface
|
||||
packaged in `python-openstackclient`_ supports both v2.0 and v3 APIs.
|
||||
|
||||
|
|
@ -1393,16 +1391,16 @@ Authenticating with a Token
|
|||
|
||||
.. NOTE::
|
||||
|
||||
If your Keystone deployment is brand new, you will need to use this
|
||||
If your keystone deployment is brand new, you will need to use this
|
||||
authentication method, along with your ``[DEFAULT] admin_token``.
|
||||
|
||||
To authenticate with Keystone using a token and ``python-openstackclient``, set
|
||||
To authenticate with keystone using a token and ``python-openstackclient``, set
|
||||
the following flags.
|
||||
|
||||
* ``--os-url OS_URL``: Keystone endpoint the user communicates with
|
||||
* ``--os-token OS_TOKEN``: User's service token
|
||||
|
||||
To administer a Keystone endpoint, your token should be either belong to a user
|
||||
To administer a keystone endpoint, your token should be either belong to a user
|
||||
with the ``admin`` role, or, if you haven't created one yet, should be equal to
|
||||
the value defined by ``[DEFAULT] admin_token`` in your ``keystone.conf``.
|
||||
|
||||
|
|
@ -1425,14 +1423,14 @@ the following:
|
|||
Authenticating with a Password
|
||||
------------------------------
|
||||
|
||||
To authenticate with Keystone using a password and ``python-openstackclient``,
|
||||
To authenticate with keystone using a password and ``python-openstackclient``,
|
||||
set the following flags, note that the following user referenced below should
|
||||
be granted the ``admin`` role.
|
||||
|
||||
* ``--os-username OS_USERNAME``: Name of your user
|
||||
* ``--os-password OS_PASSWORD``: Password for your user
|
||||
* ``--os-project-name OS_PROJECT_NAME``: Name of your project
|
||||
* ``--os-auth-url OS_AUTH_URL``: URL of the Keystone authentication server
|
||||
* ``--os-auth-url OS_AUTH_URL``: URL of the keystone authentication server
|
||||
|
||||
You can also set these variables in your environment so that they do not need
|
||||
to be passed as arguments each time:
|
||||
|
|
@ -1503,8 +1501,8 @@ unnecessary and if attempted will fail with a NotImplemented error.
|
|||
Configuring the LDAP Identity Provider
|
||||
======================================
|
||||
|
||||
As an alternative to the SQL Database backing store, Keystone can use a
|
||||
directory server to provide the Identity service. An example Schema for
|
||||
As an alternative to the SQL Database backing store, keystone can use a
|
||||
directory server to provide the Identity service. An example schema for
|
||||
OpenStack would look like this::
|
||||
|
||||
dn: dc=openstack,dc=org
|
||||
|
|
@ -1513,7 +1511,7 @@ OpenStack would look like this::
|
|||
objectClass: organizationalUnit
|
||||
ou: openstack
|
||||
|
||||
dn: ou=Projects,dc=openstack,dc=org
|
||||
dn: ou=Groups,dc=openstack,dc=org
|
||||
objectClass: top
|
||||
objectClass: organizationalUnit
|
||||
ou: groups
|
||||
|
|
@ -1523,12 +1521,7 @@ OpenStack would look like this::
|
|||
objectClass: organizationalUnit
|
||||
ou: users
|
||||
|
||||
dn: ou=Roles,dc=openstack,dc=org
|
||||
objectClass: top
|
||||
objectClass: organizationalUnit
|
||||
ou: roles
|
||||
|
||||
The corresponding entries in the Keystone configuration file are:
|
||||
The corresponding entries in the keystone configuration file are:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
|
@ -1550,7 +1543,7 @@ preexisting, more complex schema. For example, in the user object, the
|
|||
objectClass posixAccount from RFC2307 is very common. If this is the underlying
|
||||
objectclass, then the *uid* field should probably be *uidNumber* and *username*
|
||||
field either *uid* or *cn*. To change these two fields, the corresponding
|
||||
entries in the Keystone configuration file are:
|
||||
entries in the keystone configuration file are:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
|
@ -1669,11 +1662,11 @@ Secure Connection
|
|||
-----------------
|
||||
|
||||
If you are using a directory server to provide the Identity service, it is
|
||||
strongly recommended that you utilize a secure connection from Keystone to the
|
||||
directory server. In addition to supporting LDAP, Keystone also provides
|
||||
strongly recommended that you utilize a secure connection from keystone to the
|
||||
directory server. In addition to supporting LDAP, keystone also provides
|
||||
Transport Layer Security (TLS) support. There are some basic configuration
|
||||
options for enabling TLS, identifying a single file or directory that contains
|
||||
certificates for all the Certificate Authorities that the Keystone LDAP client
|
||||
certificates for all the Certificate Authorities that the keystone LDAP client
|
||||
will recognize, and declaring what checks the client should perform on server
|
||||
certificates. This functionality can easily be configured as follows:
|
||||
|
||||
|
|
@ -1686,10 +1679,10 @@ certificates. This functionality can easily be configured as follows:
|
|||
tls_req_cert = demand
|
||||
|
||||
A few points worth mentioning regarding the above options. If both
|
||||
tls_cacertfile and tls_cacertdir are set then tls_cacertfile will be used and
|
||||
tls_cacertdir is ignored. Furthermore, valid options for tls_req_cert are
|
||||
demand, never, and allow. These correspond to the standard options permitted by
|
||||
the TLS_REQCERT TLS option.
|
||||
``tls_cacertfile`` and ``tls_cacertdir`` are set then tls_cacertfile will be
|
||||
used and ``tls_cacertdir`` is ignored. Furthermore, valid options for
|
||||
``tls_req_cert`` are ``demand``, ``never``, and ``allow``. These correspond to
|
||||
the standard options permitted by the ``TLS_REQCERT`` TLS option.
|
||||
|
||||
.. NOTE::
|
||||
|
||||
|
|
@ -1703,8 +1696,8 @@ Read Only LDAP
|
|||
|
||||
Many environments typically have user and group information in directories that
|
||||
are accessible by LDAP. This information is for read-only use in a wide array
|
||||
of applications. Prior to the Havana release, we could not deploy Keystone with
|
||||
read-only directories as backends because Keystone also needed to store
|
||||
of applications. Prior to the Havana release, we could not deploy keystone with
|
||||
read-only directories as backends because keystone also needed to store
|
||||
information such as projects, roles, domains and role assignments into the
|
||||
directories in conjunction with reading user and group information.
|
||||
|
||||
|
|
@ -1712,7 +1705,7 @@ Keystone now provides an option whereby these read-only directories can be
|
|||
easily integrated as it now enables its identity entities (which comprises
|
||||
users, groups, and group memberships) to be served out of directories while
|
||||
resource (which comprises projects and domains), assignment and role
|
||||
entities are to be served from different Keystone backends (i.e. SQL). To
|
||||
entities are to be served from different keystone backends (i.e. SQL). To
|
||||
enable this option, you must have the following ``keystone.conf`` options set:
|
||||
|
||||
.. code-block:: ini
|
||||
|
|
@ -1729,7 +1722,7 @@ enable this option, you must have the following ``keystone.conf`` options set:
|
|||
[role]
|
||||
driver = sql
|
||||
|
||||
With the above configuration, Keystone will only lookup identity related
|
||||
With the above configuration, keystone will only lookup identity related
|
||||
information such users, groups, and group membership from the directory, while
|
||||
resources, roles and assignment related information will be provided by the SQL
|
||||
backend. Also note that if there is an LDAP Identity, and no resource,
|
||||
|
|
@ -1759,7 +1752,7 @@ section:
|
|||
Connection Pooling
|
||||
------------------
|
||||
|
||||
Various LDAP backends in Keystone use a common LDAP module to interact with
|
||||
Various LDAP backends in keystone use a common LDAP module to interact with
|
||||
LDAP data. By default, a new connection is established for each LDAP operation.
|
||||
This can become highly expensive when TLS support is enabled, which is a likely
|
||||
configuration in an enterprise setup. Reuse of connectors from a connection
|
||||
|
|
@ -1770,7 +1763,7 @@ Keystone provides connection pool support via configuration. This will keep
|
|||
LDAP connectors alive and reused for subsequent LDAP operations. The connection
|
||||
lifespan is configurable as other pooling specific attributes.
|
||||
|
||||
In the LDAP identity driver, Keystone authenticates end users via an LDAP bind
|
||||
In the LDAP identity driver, keystone authenticates end users via an LDAP bind
|
||||
with the user's DN and provided password. This kind of authentication bind
|
||||
can fill up the pool pretty quickly, so a separate pool is provided for end
|
||||
user authentication bind calls. If a deployment does not want to use a pool for
|
||||
|
|
@ -1789,36 +1782,55 @@ Connection pool configuration is part of the ``[ldap]`` configuration section:
|
|||
.. code-block:: ini
|
||||
|
||||
[ldap]
|
||||
# Enable LDAP connection pooling. (boolean value)
|
||||
use_pool=false
|
||||
# Enable LDAP connection pooling for queries to the LDAP server. There is
|
||||
# typically no reason to disable this. (boolean value)
|
||||
use_pool = true
|
||||
|
||||
# Connection pool size. (integer value)
|
||||
pool_size=10
|
||||
# The size of the LDAP connection pool. This option has no effect unless
|
||||
# `[ldap] use_pool` is also enabled. (integer value)
|
||||
# Minimum value: 1
|
||||
pool_size = 10
|
||||
|
||||
# Maximum count of reconnect trials. (integer value)
|
||||
pool_retry_max=3
|
||||
# The maximum number of times to attempt reconnecting to the LDAP server before
|
||||
# aborting. A value of zero prevents retries. This option has no effect unless
|
||||
# `[ldap] use_pool` is also enabled. (integer value)
|
||||
# Minimum value: 0
|
||||
pool_retry_max = 3
|
||||
|
||||
# Time span in seconds to wait between two reconnect trials.
|
||||
# The number of seconds to wait before attempting to reconnect to the LDAP
|
||||
# server. This option has no effect unless `[ldap] use_pool` is also enabled.
|
||||
# (floating point value)
|
||||
pool_retry_delay=0.1
|
||||
pool_retry_delay = 0.1
|
||||
|
||||
# Connector timeout in seconds. Value -1 indicates indefinite wait for
|
||||
# response. (integer value)
|
||||
pool_connection_timeout=-1
|
||||
# The connection timeout to use with the LDAP server. A value of `-1` means
|
||||
# that connections will never timeout. This option has no effect unless `[ldap]
|
||||
# use_pool` is also enabled. (integer value)
|
||||
# Minimum value: -1
|
||||
pool_connection_timeout = -1
|
||||
|
||||
# Connection lifetime in seconds. (integer value)
|
||||
pool_connection_lifetime=600
|
||||
# The maximum connection lifetime to the LDAP server in seconds. When this
|
||||
# lifetime is exceeded, the connection will be unbound and removed from the
|
||||
# connection pool. This option has no effect unless `[ldap] use_pool` is also
|
||||
# enabled. (integer value)
|
||||
# Minimum value: 1
|
||||
pool_connection_lifetime = 600
|
||||
|
||||
# Enable LDAP connection pooling for end user authentication. If use_pool
|
||||
# is disabled, then this setting is meaningless and is not used at all.
|
||||
# (boolean value)
|
||||
use_auth_pool=false
|
||||
# Enable LDAP connection pooling for end user authentication. There is
|
||||
# typically no reason to disable this. (boolean value)
|
||||
use_auth_pool = true
|
||||
|
||||
# End user auth connection pool size. (integer value)
|
||||
auth_pool_size=100
|
||||
# The size of the connection pool to use for end user authentication. This
|
||||
# option has no effect unless `[ldap] use_auth_pool` is also enabled. (integer
|
||||
# value)
|
||||
# Minimum value: 1
|
||||
auth_pool_size = 100
|
||||
|
||||
# End user auth connection lifetime in seconds. (integer value)
|
||||
auth_pool_connection_lifetime=60
|
||||
# The maximum end user authentication connection lifetime to the LDAP server in
|
||||
# seconds. When this lifetime is exceeded, the connection will be unbound and
|
||||
# removed from the connection pool. This option has no effect unless `[ldap]
|
||||
# use_auth_pool` is also enabled. (integer value)
|
||||
# Minimum value: 1
|
||||
auth_pool_connection_lifetime = 60
|
||||
|
||||
Specifying Multiple LDAP servers
|
||||
--------------------------------
|
||||
|
|
|
|||
Loading…
Reference in New Issue