[admin-guide] Fix the rst mark-ups for Identity service
Change-Id: If2f7664d994aee5d3a87275fd83722755c4dbcb1
This commit is contained in:
venkatamahesh
parent
84fce47ab4
commit
b65d8b9cfd
@ -2,73 +2,73 @@ Authentication middleware with user name and password
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can also configure Identity authentication middleware using the
|
||||
:code:`admin_user` and :code:`admin_password` options.
|
||||
``admin_user`` and ``admin_password`` options.
|
||||
|
||||
.. note::
|
||||
|
||||
The :code:`admin_token` option is deprecated and no longer used for
|
||||
configuring auth_token middleware.
|
||||
The ``admin_token`` option is deprecated and no longer used for
|
||||
configuring auth_token middleware.
|
||||
|
||||
For services that have a separate paste-deploy :file:`.ini` file, you can
|
||||
For services that have a separate paste-deploy ``.ini`` file, you can
|
||||
configure the authentication middleware in the ``[keystone_authtoken]``
|
||||
section of the main configuration file, such as :file:`nova.conf`. In
|
||||
section of the main configuration file, such as ``nova.conf``. In
|
||||
Compute, for example, you can remove the middleware parameters from
|
||||
:file:`api-paste.ini`, as follows:
|
||||
``api-paste.ini``, as follows:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[filter:authtoken]
|
||||
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
|
||||
[filter:authtoken]
|
||||
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
|
||||
|
||||
|
||||
And set the following values in :file:`nova.conf` as follows:
|
||||
And set the following values in ``nova.conf`` as follows:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy=keystone
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy=keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
auth_uri = http://controller:5000/v2.0
|
||||
identity_uri = http://controller:35357
|
||||
admin_user = admin
|
||||
admin_password = SuperSekretPassword
|
||||
admin_tenant_name = service
|
||||
[keystone_authtoken]
|
||||
auth_uri = http://controller:5000/v2.0
|
||||
identity_uri = http://controller:35357
|
||||
admin_user = admin
|
||||
admin_password = SuperSekretPassword
|
||||
admin_tenant_name = service
|
||||
|
||||
.. note::
|
||||
|
||||
The middleware parameters in the paste config take priority. You
|
||||
must remove them to use the values in the ``[keystone_authtoken]``
|
||||
section.
|
||||
The middleware parameters in the paste config take priority. You
|
||||
must remove them to use the values in the ``[keystone_authtoken]``
|
||||
section.
|
||||
|
||||
.. note::
|
||||
|
||||
Comment out any :code:`auth_host`, :code:`auth_port`, and
|
||||
:code:`auth_protocol` options because the :code:`identity_uri` option
|
||||
replaces them.
|
||||
Comment out any ``auth_host``, ``auth_port``, and
|
||||
``auth_protocol`` options because the ``identity_uri`` option
|
||||
replaces them.
|
||||
|
||||
This sample paste config filter makes use of the :code:`admin_user` and
|
||||
:code:`admin_password` options:
|
||||
This sample paste config filter makes use of the ``admin_user`` and
|
||||
``admin_password`` options:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[filter:authtoken]
|
||||
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
|
||||
auth_uri = http://controller:5000/v2.0
|
||||
identity_uri = http://controller:35357
|
||||
auth_token = 012345SECRET99TOKEN012345
|
||||
admin_user = admin
|
||||
admin_password = keystone123
|
||||
[filter:authtoken]
|
||||
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
|
||||
auth_uri = http://controller:5000/v2.0
|
||||
identity_uri = http://controller:35357
|
||||
auth_token = 012345SECRET99TOKEN012345
|
||||
admin_user = admin
|
||||
admin_password = keystone123
|
||||
|
||||
.. note::
|
||||
|
||||
Using this option requires an admin tenant/role relationship. The
|
||||
admin user is granted access to the admin role on the admin tenant.
|
||||
Using this option requires an admin tenant/role relationship. The
|
||||
admin user is granted access to the admin role on the admin tenant.
|
||||
|
||||
.. note::
|
||||
|
||||
Comment out any ``auth_host``, ``auth_port``, and
|
||||
``auth_protocol`` options because the ``identity_uri`` option
|
||||
replaces them.
|
||||
Comment out any ``auth_host``, ``auth_port``, and
|
||||
``auth_protocol`` options because the ``identity_uri`` option
|
||||
replaces them.
|
||||
|
||||
|
||||
@ -131,38 +131,38 @@ The Identity service assigns a tenant and a role to a user. You might
|
||||
assign the ``compute-user`` role to the ``alice`` user in the ``acme``
|
||||
tenant:
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role add --project acme --user alice compute-user
|
||||
$ openstack role add --project acme --user alice compute-user
|
||||
|
||||
A user can have different roles in different tenants. For example, Alice
|
||||
might also have the ``admin`` role in the ``Cyberdyne`` tenant. A user
|
||||
can also have multiple roles in the same tenant.
|
||||
|
||||
The :file:`/etc/[SERVICE_CODENAME]/policy.json` file controls the
|
||||
The ``/etc/[SERVICE_CODENAME]/policy.json`` file controls the
|
||||
tasks that users can perform for a given service. For example, the
|
||||
:file:`/etc/nova/policy.json` file specifies the access policy for the
|
||||
Compute service, the :file:`/etc/glance/policy.json` file specifies
|
||||
``/etc/nova/policy.json`` file specifies the access policy for the
|
||||
Compute service, the ``/etc/glance/policy.json`` file specifies
|
||||
the access policy for the Image service, and the
|
||||
:file:`/etc/keystone/policy.json` file specifies the access policy for
|
||||
``/etc/keystone/policy.json`` file specifies the access policy for
|
||||
the Identity service.
|
||||
|
||||
The default :file:`policy.json` files in the Compute, Identity, and
|
||||
The default ``policy.json`` files in the Compute, Identity, and
|
||||
Image services recognize only the ``admin`` role. Any user with
|
||||
any role in a tenant can access all operations that do not require the
|
||||
``admin`` role.
|
||||
|
||||
To restrict users from performing operations in, for example, the
|
||||
Compute service, you must create a role in the Identity service and
|
||||
then modify the :file:`/etc/nova/policy.json` file so that this role
|
||||
then modify the ``/etc/nova/policy.json`` file so that this role
|
||||
is required for Compute operations.
|
||||
|
||||
For example, the following line in the :file:`/etc/nova/policy.json`
|
||||
For example, the following line in the ``/etc/nova/policy.json``
|
||||
file does not restrict which users can create volumes:
|
||||
|
||||
.. code:: json
|
||||
.. code-block:: json
|
||||
|
||||
"volume:create": "",
|
||||
"volume:create": "",
|
||||
|
||||
If the user has any role in a tenant, he can create volumes in that
|
||||
tenant.
|
||||
@ -170,9 +170,9 @@ tenant.
|
||||
To restrict the creation of volumes to users who have the
|
||||
``compute-user`` role in a particular tenant, you add ``"role:compute-user"``:
|
||||
|
||||
.. code:: json
|
||||
.. code-block:: json
|
||||
|
||||
"volume:create": "role:compute-user",
|
||||
"volume:create": "role:compute-user",
|
||||
|
||||
To restrict all Compute service requests to require this role, the
|
||||
resulting file looks like:
|
||||
@ -337,10 +337,10 @@ Identity API V3 provides the following group-related operations:
|
||||
|
||||
.. note::
|
||||
|
||||
The Identity service server might not allow all operations. For
|
||||
example, if you use the Identity server with the LDAP Identity
|
||||
back end and group updates are disabled, a request to create,
|
||||
delete, or update a group fails.
|
||||
The Identity service server might not allow all operations. For
|
||||
example, if you use the Identity server with the LDAP Identity
|
||||
back end and group updates are disabled, a request to create,
|
||||
delete, or update a group fails.
|
||||
|
||||
Here are a couple of examples:
|
||||
|
||||
|
||||
@ -10,23 +10,23 @@ commands can be invoked as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Using token auth env variables
|
||||
export OS_SERVICE_ENDPOINT=http://127.0.0.1:5000/v2.0/
|
||||
export OS_SERVICE_TOKEN=secrete_token
|
||||
keystone user-list
|
||||
keystone tenant-create --name demo
|
||||
# Using token auth env variables
|
||||
export OS_SERVICE_ENDPOINT=http://127.0.0.1:5000/v2.0/
|
||||
export OS_SERVICE_TOKEN=secrete_token
|
||||
keystone user-list
|
||||
keystone tenant-create --name demo
|
||||
|
||||
# Using token auth flags
|
||||
keystone --os-token secrete --os-endpoint http://127.0.0.1:5000/v2.0/ user-list
|
||||
keystone --os-token secrete --os-endpoint http://127.0.0.1:5000/v2.0/ tenant-create --name=demo
|
||||
# Using token auth flags
|
||||
keystone --os-token secrete --os-endpoint http://127.0.0.1:5000/v2.0/ user-list
|
||||
keystone --os-token secrete --os-endpoint http://127.0.0.1:5000/v2.0/ tenant-create --name=demo
|
||||
|
||||
# Using user + password + project_name env variables
|
||||
export OS_USERNAME=admin
|
||||
export OS_PASSWORD=secrete
|
||||
export OS_PROJECT_NAME=admin
|
||||
openstack user list
|
||||
openstack project create demo
|
||||
# Using user + password + project_name env variables
|
||||
export OS_USERNAME=admin
|
||||
export OS_PASSWORD=secrete
|
||||
export OS_PROJECT_NAME=admin
|
||||
openstack user list
|
||||
openstack project create demo
|
||||
|
||||
# Using user + password + project-name flags
|
||||
openstack --os-username admin --os-password secrete --os-project-name admin user list
|
||||
openstack --os-username admin --os-password secrete --os-project-name admin project create demo
|
||||
# Using user + password + project-name flags
|
||||
openstack --os-username admin --os-password secrete --os-project-name admin user list
|
||||
openstack --os-username admin --os-password secrete --os-project-name admin project create demo
|
||||
|
||||
@ -5,10 +5,10 @@ Logging
|
||||
You configure logging externally to the rest of Identity. The name of
|
||||
the file specifying the logging configuration is set using the
|
||||
``log_config`` option in the ``[DEFAULT]`` section of the
|
||||
:file:`keystone.conf` file. To route logging through syslog, set
|
||||
``keystone.conf`` file. To route logging through syslog, set
|
||||
``use_syslog=true`` in the ``[DEFAULT]`` section.
|
||||
|
||||
A sample logging configuration file is available with the project in
|
||||
:file:`etc/logging.conf.sample`. Like other OpenStack projects, Identity
|
||||
``etc/logging.conf.sample``. Like other OpenStack projects, Identity
|
||||
uses the Python logging module, which provides extensive configuration
|
||||
options that let you define the output levels and formats.
|
||||
|
||||
@ -4,9 +4,9 @@
|
||||
Identity management
|
||||
===================
|
||||
|
||||
OpenStack Identity, code-named keystone, is the default identity
|
||||
OpenStack Identity, code-named keystone, is the default Identity
|
||||
management system for OpenStack. After you install Identity, you
|
||||
configure it through the :file:`/etc/keystone/keystone.conf`
|
||||
configure it through the ``/etc/keystone/keystone.conf``
|
||||
configuration file and, possibly, a separate logging configuration
|
||||
file. You initialize data into Identity by using the ``keystone``
|
||||
command-line client.
|
||||
|
||||
@ -5,16 +5,16 @@ Identity API protection with role-based access control (RBAC)
|
||||
Like most OpenStack projects, Identity supports the protection of its
|
||||
APIs by defining policy rules based on an RBAC approach. Identity stores
|
||||
a reference to a policy JSON file in the main Identity configuration
|
||||
file, :file:`keystone.conf`. Typically this file is named ``policy.json``,
|
||||
file, ``keystone.conf``. Typically this file is named ``policy.json``,
|
||||
and contains the rules for which roles have access to certain actions
|
||||
in defined services.
|
||||
|
||||
Each Identity API v3 call has a line in the policy file that dictates
|
||||
which level of governance of access applies.
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
API_NAME: RULE_STATEMENT or MATCH_STATEMENT
|
||||
API_NAME: RULE_STATEMENT or MATCH_STATEMENT
|
||||
|
||||
Where:
|
||||
|
||||
@ -25,13 +25,13 @@ Where:
|
||||
token provided by the caller of the API and the parameters or target
|
||||
entities of the API call in question. For example:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
"identity:create_user": "role:admin and domain_id:%(user.domain_id)s"
|
||||
"identity:create_user": "role:admin and domain_id:%(user.domain_id)s"
|
||||
|
||||
Indicates that to create a user, you must have the admin role in your
|
||||
token. The :code:`domain_id` in your token must match the
|
||||
:code:`domain_id` in the user object that you are trying
|
||||
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
|
||||
@ -39,9 +39,9 @@ must be scoped to that domain.
|
||||
|
||||
Each component of a match statement uses this format:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
ATTRIB_FROM_TOKEN:CONSTANT or ATTRIB_RELATED_TO_API_CALL
|
||||
ATTRIB_FROM_TOKEN:CONSTANT or ATTRIB_RELATED_TO_API_CALL
|
||||
|
||||
The Identity service expects these attributes:
|
||||
|
||||
@ -64,9 +64,9 @@ 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:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
"identity:delete_user": "role:admin and domain_id:%(target.user.domain_id)s"
|
||||
"identity:delete_user": "role:admin and domain_id:%(target.user.domain_id)s"
|
||||
|
||||
would ensure that Identity only deletes the user object in the same
|
||||
domain as the provided token.
|
||||
@ -81,48 +81,48 @@ List of object attributes:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
role:
|
||||
target.role.id
|
||||
target.role.name
|
||||
role:
|
||||
target.role.id
|
||||
target.role.name
|
||||
|
||||
user:
|
||||
target.user.default_project_id
|
||||
target.user.description
|
||||
target.user.domain_id
|
||||
target.user.enabled
|
||||
target.user.id
|
||||
target.user.name
|
||||
user:
|
||||
target.user.default_project_id
|
||||
target.user.description
|
||||
target.user.domain_id
|
||||
target.user.enabled
|
||||
target.user.id
|
||||
target.user.name
|
||||
|
||||
group:
|
||||
target.group.description
|
||||
target.group.domain_id
|
||||
target.group.id
|
||||
target.group.name
|
||||
group:
|
||||
target.group.description
|
||||
target.group.domain_id
|
||||
target.group.id
|
||||
target.group.name
|
||||
|
||||
domain:
|
||||
target.domain.enabled
|
||||
target.domain.id
|
||||
target.domain.name
|
||||
domain:
|
||||
target.domain.enabled
|
||||
target.domain.id
|
||||
target.domain.name
|
||||
|
||||
project:
|
||||
target.project.description
|
||||
target.project.domain_id
|
||||
target.project.enabled
|
||||
target.project.id
|
||||
target.project.name
|
||||
project:
|
||||
target.project.description
|
||||
target.project.domain_id
|
||||
target.project.enabled
|
||||
target.project.id
|
||||
target.project.name
|
||||
|
||||
The default :file:`policy.json` file supplied provides a somewhat
|
||||
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 :file:`policy.v3cloudsample.json` as an
|
||||
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 :code:`admin domain`. This example policy file also
|
||||
shows the use of an :code:`admin_domain` to allow a cloud provider to
|
||||
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 :code:`admin_domain` with the first users within
|
||||
it. You could then obtain the :code:`domain_id` of the admin domain,
|
||||
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 of
|
||||
:file:`policy.v3cloudsample.json`, and then enable it as the main
|
||||
policy file.
|
||||
``policy.v3cloudsample.json``, and then enable it as the main
|
||||
``policy file``.
|
||||
|
||||
@ -3,12 +3,12 @@ Start the Identity services
|
||||
|
||||
To start the services for Identity, run the following command:
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
$ keystone-all
|
||||
$ keystone-all
|
||||
|
||||
This command starts two wsgi.Server instances configured by the
|
||||
:file:`keystone.conf` file as described previously. One of these wsgi
|
||||
servers is :code:`admin` (the administration API) and the other is
|
||||
:code:`main` (the primary/public API interface). Both run in a single
|
||||
``keystone.conf`` file as described previously. One of these wsgi
|
||||
servers is ``admin`` (the administration API) and the other is
|
||||
``main`` (the primary/public API interface). Both run in a single
|
||||
process.
|
||||
|
||||
@ -5,10 +5,10 @@ Troubleshoot the Identity service
|
||||
To troubleshoot the Identity service, review the logs in the
|
||||
``/var/log/keystone/keystone.log`` file.
|
||||
|
||||
.. note
|
||||
.. note::
|
||||
|
||||
Use the :file:`/etc/keystone/logging.conf` file to configure the
|
||||
location of log files.
|
||||
Use the ``/etc/keystone/logging.conf`` file to configure the
|
||||
location of log files.
|
||||
|
||||
The logs show the components that have come in to the WSGI request, and
|
||||
ideally show an error that explains why an authorization request failed.
|
||||
@ -32,56 +32,54 @@ section like this:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[keystone_authtoken]
|
||||
signing_dir = /var/cache/glance/api
|
||||
auth_uri = http://controller:5000/v2.0
|
||||
identity_uri = http://controller:35357
|
||||
admin_tenant_name = service
|
||||
admin_user = glance
|
||||
[keystone_authtoken]
|
||||
signing_dir = /var/cache/glance/api
|
||||
auth_uri = http://controller:5000/v2.0
|
||||
identity_uri = http://controller:35357
|
||||
admin_tenant_name = service
|
||||
admin_user = glance
|
||||
|
||||
The first thing to check is that the ``signing_dir`` does, in fact,
|
||||
exist. If it does, check for certificate files:
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
$ ls -la /var/cache/glance/api/
|
||||
$ ls -la /var/cache/glance/api/
|
||||
|
||||
.. code::
|
||||
|
||||
total 24
|
||||
drwx------. 2 ayoung root 4096 Jul 22 10:58 .
|
||||
drwxr-xr-x. 4 root root 4096 Nov 7 2012 ..
|
||||
-rw-r-----. 1 ayoung ayoung 1424 Jul 22 10:58 cacert.pem
|
||||
-rw-r-----. 1 ayoung ayoung 15 Jul 22 10:58 revoked.pem
|
||||
-rw-r-----. 1 ayoung ayoung 4518 Jul 22 10:58 signing_cert.pem
|
||||
total 24
|
||||
drwx------. 2 ayoung root 4096 Jul 22 10:58 .
|
||||
drwxr-xr-x. 4 root root 4096 Nov 7 2012 ..
|
||||
-rw-r-----. 1 ayoung ayoung 1424 Jul 22 10:58 cacert.pem
|
||||
-rw-r-----. 1 ayoung ayoung 15 Jul 22 10:58 revoked.pem
|
||||
-rw-r-----. 1 ayoung ayoung 4518 Jul 22 10:58 signing_cert.pem
|
||||
|
||||
This directory contains two certificates and the token revocation list.
|
||||
If these files are not present, your service cannot fetch them from
|
||||
Identity. To troubleshoot, try to talk to Identity to make sure it
|
||||
correctly serves files, as follows:
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
$ curl http://localhost:35357/v2.0/certificates/signing
|
||||
$ curl http://localhost:35357/v2.0/certificates/signing
|
||||
|
||||
This command fetches the signing certificate:
|
||||
|
||||
.. code::
|
||||
.. code-block:: yaml
|
||||
|
||||
Certificate:
|
||||
Data:
|
||||
Version: 3 (0x2)
|
||||
Serial Number: 1 (0x1)
|
||||
Signature Algorithm: sha1WithRSAEncryption
|
||||
Issuer: C=US, ST=Unset, L=Unset, O=Unset, CN=www.example.com
|
||||
Validity
|
||||
Not Before: Jul 22 14:57:31 2013 GMT
|
||||
Not After : Jul 20 14:57:31 2023 GMT
|
||||
Subject: C=US, ST=Unset, O=Unset, CN=www.example.com
|
||||
Certificate:
|
||||
Data:
|
||||
Version: 3 (0x2)
|
||||
Serial Number: 1 (0x1)
|
||||
Signature Algorithm: sha1WithRSAEncryption
|
||||
Issuer: C=US, ST=Unset, L=Unset, O=Unset, CN=www.example.com
|
||||
Validity
|
||||
Not Before: Jul 22 14:57:31 2013 GMT
|
||||
Not After : Jul 20 14:57:31 2023 GMT
|
||||
Subject: C=US, ST=Unset, O=Unset, CN=www.example.com
|
||||
|
||||
Note the expiration dates of the certificate:
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
Not Before: Jul 22 14:57:31 2013 GMT
|
||||
Not After : Jul 20 14:57:31 2023 GMT
|
||||
@ -96,7 +94,7 @@ files. You might have to turn up your logging levels. Set
|
||||
``debug = True`` and ``verbose = True`` in your Identity configuration
|
||||
file and restart the Identity server.
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
(keystone.common.wsgi): 2013-07-24 12:18:11,461 DEBUG wsgi __call__
|
||||
arg_dict: {}
|
||||
@ -122,9 +120,9 @@ Run the ``setenforce permissive`` command. If that makes a difference,
|
||||
you should relabel the directory. If you are using a sub-directory of
|
||||
the ``/var/cache/`` directory, run the following command:
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
# restorecon /var/cache/
|
||||
# restorecon /var/cache/
|
||||
|
||||
If you are not using a ``/var/cache`` sub-directory, you should. Modify
|
||||
the ``signing_dir`` configuration option for your service and restart.
|
||||
@ -141,33 +139,34 @@ Debug signing key file errors
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If an error occurs when the signing key file opens, it is possible that
|
||||
the person who ran the ``keystone-manage pki_setup`` command to generate
|
||||
certificates and keys did not use the correct user. When you run the
|
||||
``keystone-manage pki_setup`` command, Identity generates a set of
|
||||
certificates and keys in ``/etc/keystone/ssl*``, which is owned by
|
||||
the person who ran the :command:`keystone-manage pki_setup` command to
|
||||
generate certificates and keys did not use the correct user. When you
|
||||
run the :command:`keystone-manage pki_setup` command, Identity generates
|
||||
a set of certificates and keys in ``/etc/keystone/ssl*``, which is owned by
|
||||
``root:root``.
|
||||
|
||||
This can present a problem when you run the Identity daemon under the
|
||||
keystone user account (nologin) when you try to run PKI. Unless you run
|
||||
the ``chown`` command against the files ``keystone:keystone``, or run the
|
||||
``keystone-manage pki_setup`` command with the :option:`--keystone-user` and
|
||||
:option:`--keystone-group` parameters, you will get an error. For example:
|
||||
the :command:`chown` command against the files ``keystone:keystone``, or run
|
||||
the :command:`keystone-manage pki_setup` command with the
|
||||
:option:`--keystone-user` and :option:`--keystone-group` parameters, you
|
||||
will get an error. For example:
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
2012-07-31 11:10:53 ERROR [keystone.common.cms] Error opening signing key file
|
||||
/etc/keystone/ssl/private/signing_key.pem
|
||||
140380567730016:error:0200100D:system library:fopen:Permission
|
||||
denied:bss_file.c:398:fopen('/etc/keystone/ssl/private/signing_key.pem','r')
|
||||
140380567730016:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
|
||||
unable to load signing key file
|
||||
2012-07-31 11:10:53 ERROR [keystone.common.cms] Error opening signing key file
|
||||
/etc/keystone/ssl/private/signing_key.pem
|
||||
140380567730016:error:0200100D:system library:fopen:Permission
|
||||
denied:bss_file.c:398:fopen('/etc/keystone/ssl/private/signing_key.pem','r')
|
||||
140380567730016:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
|
||||
unable to load signing key file
|
||||
|
||||
Flush expired tokens from the token database table
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As you generate tokens, the token database table on the Identity server
|
||||
grows. To clear the token table, an administrative user must run the
|
||||
``keystone-manage token_flush`` command to flush the tokens. When you
|
||||
:command:`keystone-manage token_flush` command to flush the tokens. When you
|
||||
flush tokens, expired tokens are deleted and traceability is eliminated.
|
||||
|
||||
Use ``cron`` to schedule this command to run frequently based on your
|
||||
|
||||
@ -5,23 +5,25 @@ User CRUD
|
||||
Identity 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 :code:`user_crud_extension`
|
||||
filter, insert it after the "option:`*_body` middleware and before the
|
||||
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 the ``public_api`` WSGI pipeline in
|
||||
:file:`keystone-paste.ini`. For example:
|
||||
``keystone-paste.ini``. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[filter:user_crud_extension]
|
||||
paste.filter_factory = keystone.contrib.user_crud:CrudExtension.factory
|
||||
[filter:user_crud_extension]
|
||||
paste.filter_factory = keystone.contrib.user_crud:CrudExtension.factory
|
||||
|
||||
[pipeline:public_api]
|
||||
pipeline = sizelimit url_normalize request_id build_auth_context token_auth admin_token_auth json_body ec2_extension user_crud_extension public_service
|
||||
[pipeline:public_api]
|
||||
pipeline = sizelimit url_normalize request_id build_auth_context token_auth admin_token_auth json_body ec2_extension user_crud_extension public_service
|
||||
|
||||
Each user can then change their own password with a HTTP PATCH::
|
||||
Each user can then change their own password with a HTTP PATCH.
|
||||
|
||||
$ curl -X PATCH http://localhost:5000/v2.0/OS-KSCRUD/users/USERID -H "Content-type: application/json" \
|
||||
-H "X_Auth_Token: AUTHTOKENID" -d '{"user": {"password": "ABCD", "original_password": "DCBA"}}'
|
||||
.. code-block:: console
|
||||
|
||||
$ curl -X PATCH http://localhost:5000/v2.0/OS-KSCRUD/users/USERID -H "Content-type: application/json" \
|
||||
-H "X_Auth_Token: AUTHTOKENID" -d '{"user": {"password": "ABCD", "original_password": "DCBA"}}'
|
||||
|
||||
In addition to changing their password, all current tokens for the user
|
||||
are invalidated.
|
||||
|
||||
@ -9,7 +9,7 @@ Identity uses the
|
||||
`dogpile.cache <http://dogpilecache.readthedocs.org/en/latest/>`__
|
||||
library which allows flexible cache back ends. The majority of the
|
||||
caching configuration options are set in the ``[cache]`` section of the
|
||||
:file:`keystone.conf` file. However, each section that has the capability to
|
||||
``keystone.conf`` file. However, each section that has the capability to
|
||||
be cached usually has a caching boolean value that toggles caching.
|
||||
|
||||
So to enable only the token back end caching, set the values as follows:
|
||||
|
||||
@ -6,11 +6,11 @@ PKI stands for Public Key Infrastructure. Tokens 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)
|
||||
used to sign it must be available as a :term:`Certificate Authority (CA)<CA>`
|
||||
certificate. These files can be generated either using the
|
||||
``keystone-manage`` utility, or externally generated. The files need to
|
||||
:command:`keystone-manage` utility, or externally generated. The files need to
|
||||
be in the locations specified by the top level Identity service
|
||||
configuration file :file:`keystone.conf` as specified in the above section.
|
||||
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.
|
||||
|
||||
@ -31,20 +31,20 @@ values are:
|
||||
|
||||
- ``certfile``
|
||||
Location of certificate used to verify tokens. Default is
|
||||
:file:`/etc/keystone/ssl/certs/signing_cert.pem`.
|
||||
``/etc/keystone/ssl/certs/signing_cert.pem``.
|
||||
|
||||
- ``keyfile``
|
||||
Location of private key used to sign tokens. Default is
|
||||
:file:`/etc/keystone/ssl/private/signing_key.pem`.
|
||||
``/etc/keystone/ssl/private/signing_key.pem``.
|
||||
|
||||
- ``ca_certs``
|
||||
Location of certificate for the authority that issued
|
||||
the above certificate. Default is
|
||||
:file:`/etc/keystone/ssl/certs/ca.pem`.
|
||||
``/etc/keystone/ssl/certs/ca.pem``.
|
||||
|
||||
- ``ca_key``
|
||||
Location of the private key used by the CA. Default is
|
||||
:file:`/etc/keystone/ssl/private/cakey.pem`.
|
||||
``/etc/keystone/ssl/private/cakey.pem``.
|
||||
|
||||
- ``key_size``
|
||||
Default is ``2048``.
|
||||
@ -102,7 +102,7 @@ Sign certificate issued by external CA
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can use a signing certificate issued by an external CA instead of
|
||||
generated by ``keystone-manage``. However, a certificate issued by an
|
||||
generated by :command:`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)
|
||||
@ -130,7 +130,7 @@ 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
|
||||
:file:`cert_req.conf` file, as follows:
|
||||
``cert_req.conf`` file, as follows:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -154,14 +154,16 @@ Create a certificate request configuration file. For example, create the
|
||||
Then generate a CRS with OpenSSL CLI. **Do not encrypt the generated
|
||||
private key. You must use the -nodes option.**
|
||||
|
||||
For example::
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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
|
||||
:file:`signing_cert_req.pem` and :file:`signing_key.pem`. Send
|
||||
:file:`signing_cert_req.pem` to your CA to request a token signing certificate
|
||||
``signing_cert_req.pem`` and ``signing_key.pem``. Send
|
||||
``signing_cert_req.pem`` to your CA to request a token signing 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.
|
||||
|
||||
@ -170,18 +172,18 @@ Install an external signing certificate
|
||||
|
||||
Assuming you have the following already:
|
||||
|
||||
- :file:`signing_cert.pem`
|
||||
- ``signing_cert.pem``
|
||||
(Keystone token) signing certificate in PEM format
|
||||
|
||||
- :file:`signing_key.pem`
|
||||
- ``signing_key.pem``
|
||||
Corresponding (non-encrypted) private key in PEM format
|
||||
|
||||
- :file:`cacert.pem`
|
||||
- ``cacert.pem``
|
||||
Trust CA certificate chain in PEM format
|
||||
|
||||
Copy the above to your certificate directory. For example:
|
||||
|
||||
.. code::
|
||||
.. code-block:: console
|
||||
|
||||
# mkdir -p /etc/keystone/ssl/certs
|
||||
# cp signing_cert.pem /etc/keystone/ssl/certs/
|
||||
@ -197,15 +199,15 @@ Copy the above to your certificate directory. For example:
|
||||
|
||||
The procedure of copying the key and cert files may be improved if
|
||||
done after first running :command:`keystone-manage pki_setup` since this
|
||||
command also creates other needed files, such as the :file:`index.txt`
|
||||
and :file:`serial` files.
|
||||
command also creates other 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
|
||||
:file:`/etc/keystone/ssl/certs`, make sure it is reflected in the
|
||||
``/etc/keystone/ssl/certs``, make sure it is reflected in the
|
||||
``[signing]`` section of the configuration file.
|
||||
|
||||
Switching out expired signing certificates
|
||||
|
||||
@ -7,7 +7,7 @@ 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
|
||||
:file:`examples/pki/certs` and :file:`examples/pki/private` directories:
|
||||
``examples/pki/certs`` and ``examples/pki/private`` directories:
|
||||
|
||||
cacert.pem
|
||||
Certificate Authority chain to validate against.
|
||||
@ -36,23 +36,23 @@ Client authentication with keystone-all
|
||||
|
||||
When running ``keystone-all``, the server can be configured to enable SSL
|
||||
with client authentication using the following instructions. Modify the
|
||||
``[eventlet_server_ssl]`` section in the :file:`/etc/keystone/keystone.conf`
|
||||
``[eventlet_server_ssl]`` section in the ``/etc/keystone/keystone.conf``
|
||||
file. The following SSL configuration example uses the included sample
|
||||
certificates:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[eventlet_server_ssl]
|
||||
enable = True
|
||||
certfile = <path to keystone.pem>
|
||||
keyfile = <path to keystonekey.pem>
|
||||
ca_certs = <path to ca.pem>
|
||||
cert_required = True
|
||||
[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.
|
||||
``True`` enables SSL. Default is ``False``.
|
||||
|
||||
- ``certfile``
|
||||
Path to the Identity service public certificate file.
|
||||
@ -66,7 +66,7 @@ certificates:
|
||||
Path to the CA trust chain.
|
||||
|
||||
- ``cert_required``
|
||||
Requires client certificate. Default is False.
|
||||
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.
|
||||
|
||||
@ -22,7 +22,9 @@ Use X.509
|
||||
~~~~~~~~~
|
||||
|
||||
The following Apache configuration snippet authenticates the user based
|
||||
on a valid X.509 certificate from a known CA::
|
||||
on a valid X.509 certificate from a known CA:
|
||||
|
||||
.. code-block:: apacheconf
|
||||
|
||||
<VirtualHost _default_:5000>
|
||||
SSLEngine on
|
||||
|
||||
@ -56,19 +56,20 @@ keystone configuration file. The keystone process should be able to read and
|
||||
write to this location but it should be kept secret otherwise. Currently,
|
||||
keystone only supports file-backed key repositories.
|
||||
|
||||
..code-block:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[fernet_tokens]
|
||||
key_repository = /etc/keystone/fernet-keys/
|
||||
[fernet_tokens]
|
||||
key_repository = /etc/keystone/fernet-keys/
|
||||
|
||||
What is the recommended way to rotate and distribute keys?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``keystone-manage`` command line utility includes a key rotation mechanism.
|
||||
This mechanism will initialize and rotate keys but does not make an effort to
|
||||
distribute keys across keystone nodes. The distribution of keys across a
|
||||
keystone deployment is best handled through configuration management tooling.
|
||||
Use ``keystone-manage fernet_rotate`` to rotate the key repository.
|
||||
The :command:`keystone-manage` command line utility includes a key rotation
|
||||
mechanism. This mechanism will initialize and rotate keys but does not make
|
||||
an effort to distribute keys across keystone nodes. The distribution of keys
|
||||
across a keystone deployment is best handled through configuration management
|
||||
tooling. Use :command:`keystone-manage fernet_rotate` to rotate the key
|
||||
repository.
|
||||
|
||||
Do fernet tokens still expires?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -245,79 +246,91 @@ and adding two. Better illustrated as::
|
||||
The reason for adding two additional keys to the count is to include the staged
|
||||
key and a buffer key. This can be shown based on the previous example. We
|
||||
initially setup the key repository at 6:00 AM on Monday, and the initial state
|
||||
looks like::
|
||||
looks like:
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (primary key)
|
||||
.. code-block:: console
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (primary key)
|
||||
|
||||
All tokens created after 6:00 AM are encrypted with key ``1``. At 12:00 PM we
|
||||
will rotate keys again, resulting in::
|
||||
will rotate keys again, resulting in,
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 2 (primary key)
|
||||
.. code-block:: console
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 2 (primary key)
|
||||
|
||||
We are still able to validate tokens created between 6:00 - 11:59 AM because
|
||||
the ``1`` key still exists as a secondary key. All tokens issued after 12:00 PM
|
||||
will be encrypted with key ``2``. At 6:00 PM we do our next rotation, resulting
|
||||
in::
|
||||
in:
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 2 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 3 (primary key)
|
||||
.. code-block:: console
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 2 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 3 (primary key)
|
||||
|
||||
It is still possible to validate tokens issued from 6:00 AM - 5:59 PM because
|
||||
keys ``1`` and ``2`` exist as secondary keys. Every token issued until 11:59 PM
|
||||
will be encrypted with key ``3``, and at 12:00 AM we do our next rotation::
|
||||
will be encrypted with key ``3``, and at 12:00 AM we do our next rotation:
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 2 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 3 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 4 (primary key)
|
||||
.. code-block:: console
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 2 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 3 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 4 (primary key)
|
||||
|
||||
Just like before, we can still validate tokens issued from 6:00 AM the previous
|
||||
day until 5:59 AM today because keys ``1`` - ``4`` are present. At 6:00 AM,
|
||||
tokens issued from the previous day will start to expire and we do our next
|
||||
scheduled rotation::
|
||||
scheduled rotation:
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 2 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 3 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 4 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 5 (primary key)
|
||||
.. code-block:: console
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 1 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 2 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 3 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 4 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 5 (primary key)
|
||||
|
||||
Tokens will naturally expire after 6:00 AM, but we will not be able to remove
|
||||
key ``1`` until the next rotation because it encrypted all tokens from 6:00 AM
|
||||
to 12:00 PM the day before. Once we do our next rotation, which is at 12:00 PM,
|
||||
the ``1`` key will be pruned from the repository::
|
||||
the ``1`` key will be pruned from the repository:
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 2 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 3 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 4 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 5 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 6 (primary key)
|
||||
.. code-block:: console
|
||||
|
||||
$ ls -la /etc/keystone/fernet-keys/
|
||||
drwx------ 2 keystone keystone 4096 .
|
||||
drwxr-xr-x 3 keystone keystone 4096 ..
|
||||
-rw------- 1 keystone keystone 44 0 (staged key)
|
||||
-rw------- 1 keystone keystone 44 2 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 3 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 4 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 5 (secondary key)
|
||||
-rw------- 1 keystone keystone 44 6 (primary key)
|
||||
|
||||
If keystone were to receive a token that was created between 6:00 AM and 12:00
|
||||
PM the day before, encrypted with the ``1`` key, it would not be valid because
|
||||
|
||||
@ -21,7 +21,7 @@ assignments in LDAP.
|
||||
.. important::
|
||||
|
||||
For OpenStack Identity assignments to access LDAP servers, you must
|
||||
define the destination LDAP server in the :file:`keystone.conf` file.
|
||||
define the destination LDAP server in the ``keystone.conf`` file.
|
||||
For more information, see :ref:`integrate-identity-with-ldap`.
|
||||
|
||||
**To integrate assignment back ends with LDAP**
|
||||
@ -54,7 +54,7 @@ assignments in LDAP.
|
||||
various schemas. For example, this entry maps to the groupOfNames
|
||||
attribute in Active Directory:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
project_objectclass = groupOfNames
|
||||
|
||||
@ -72,10 +72,11 @@ assignments in LDAP.
|
||||
project_allow_update = False
|
||||
project_allow_delete = False
|
||||
|
||||
#. Restart the OpenStack Identity service::
|
||||
#. Restart the OpenStack Identity service:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# service keystone restart
|
||||
# service keystone restart
|
||||
|
||||
.. warning::
|
||||
|
||||
@ -84,8 +85,8 @@ assignments in LDAP.
|
||||
|
||||
**Additional LDAP integration settings.**
|
||||
|
||||
Set these options in the :file:`/etc/keystone/keystone.conf` file for a
|
||||
single LDAP server, or :file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf`
|
||||
Set these options in the ``/etc/keystone/keystone.conf`` file for a
|
||||
single LDAP server, or ``/etc/keystone/domains/keystone.DOMAIN_NAME.conf``
|
||||
files for multiple back ends.
|
||||
|
||||
Filters
|
||||
|
||||
@ -26,7 +26,7 @@ administrators to use users and groups in LDAP.
|
||||
driver = keystone.identity.backends.ldap.Identity
|
||||
|
||||
#. Create the organizational units (OU) in the LDAP directory, and define
|
||||
the corresponding location in the :file:`keystone.conf` file:
|
||||
the corresponding location in the ``keystone.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -43,12 +43,12 @@ administrators to use users and groups in LDAP.
|
||||
various schemas. For example, this entry maps to the person
|
||||
attribute in Active Directory:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
user_objectclass = person
|
||||
|
||||
#. A read-only implementation is recommended for LDAP integration. These
|
||||
permissions are applied to object types in the :file:`keystone.conf`:
|
||||
permissions are applied to object types in the ``keystone.conf``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -61,22 +61,25 @@ administrators to use users and groups in LDAP.
|
||||
group_allow_update = False
|
||||
group_allow_delete = False
|
||||
|
||||
Restart the OpenStack Identity service::
|
||||
Restart the OpenStack Identity service:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# service keystone restart
|
||||
|
||||
.. warning::
|
||||
.. warning::
|
||||
|
||||
During service restart, authentication and authorization are
|
||||
unavailable.
|
||||
|
||||
**To integrate multiple Identity back ends with LDAP**
|
||||
|
||||
#. Set the following options in the :file:`/etc/keystone/keystone.conf` file:
|
||||
#. Set the following options in the ``/etc/keystone/keystone.conf``
|
||||
file:
|
||||
|
||||
#. Enable the LDAP driver:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[identity]
|
||||
#driver = keystone.identity.backends.sql.Identity
|
||||
@ -84,15 +87,17 @@ administrators to use users and groups in LDAP.
|
||||
|
||||
#. Enable domain-specific drivers:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[identity]
|
||||
domain_specific_drivers_enabled = True
|
||||
domain_config_dir = /etc/keystone/domains
|
||||
|
||||
#. Restart the service::
|
||||
#. Restart the service:
|
||||
|
||||
# service keystone restart
|
||||
.. code-block:: console
|
||||
|
||||
# service keystone restart
|
||||
|
||||
#. List the domains using the dashboard, or the OpenStackClient CLI. Refer
|
||||
to the `Command List
|
||||
@ -102,18 +107,18 @@ administrators to use users and groups in LDAP.
|
||||
#. Create domains using OpenStack dashboard, or the OpenStackClient CLI.
|
||||
|
||||
#. For each domain, create a domain-specific configuration file in the
|
||||
:file:`/etc/keystone/domains` directory. Use the file naming convention
|
||||
:file:`keystone.DOMAIN_NAME.conf`, where DOMAIN\_NAME is the domain name
|
||||
``/etc/keystone/domains`` directory. Use the file naming convention
|
||||
``keystone.DOMAIN_NAME.conf``, where DOMAIN\_NAME is the domain name
|
||||
assigned in the previous step.
|
||||
|
||||
.. note::
|
||||
|
||||
The options set in the
|
||||
:file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf` file will
|
||||
override options in the :file:`/etc/keystone/keystone.conf` file.
|
||||
``/etc/keystone/domains/keystone.DOMAIN_NAME.conf`` file will
|
||||
override options in the ``/etc/keystone/keystone.conf`` file.
|
||||
|
||||
#. Define the destination LDAP server in the
|
||||
:file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf` file. For example:
|
||||
``/etc/keystone/domains/keystone.DOMAIN_NAME.conf`` file. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -127,7 +132,7 @@ administrators to use users and groups in LDAP.
|
||||
|
||||
#. Create the organizational units (OU) in the LDAP directories, and define
|
||||
their corresponding locations in the
|
||||
:file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf` file. For example:
|
||||
``/etc/keystone/domains/keystone.DOMAIN_NAME.conf`` file. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -144,15 +149,15 @@ administrators to use users and groups in LDAP.
|
||||
various schemas. For example, this entry maps to the person
|
||||
attribute in Active Directory:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
user_objectclass = person
|
||||
|
||||
#. A read-only implementation is recommended for LDAP integration. These
|
||||
permissions are applied to object types in the
|
||||
:file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf` file:
|
||||
``/etc/keystone/domains/keystone.DOMAIN_NAME.conf`` file:
|
||||
|
||||
.. code:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[ldap]
|
||||
user_allow_create = False
|
||||
@ -163,9 +168,11 @@ administrators to use users and groups in LDAP.
|
||||
group_allow_update = False
|
||||
group_allow_delete = False
|
||||
|
||||
#. Restart the OpenStack Identity service::
|
||||
#. Restart the OpenStack Identity service:
|
||||
|
||||
# service keystone restart
|
||||
.. code-block:: console
|
||||
|
||||
# service keystone restart
|
||||
|
||||
.. warning::
|
||||
|
||||
@ -174,8 +181,8 @@ administrators to use users and groups in LDAP.
|
||||
|
||||
**Additional LDAP integration settings**
|
||||
|
||||
Set these options in the :file:`/etc/keystone/keystone.conf` file for a
|
||||
single LDAP server, or :file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf`
|
||||
Set these options in the ``/etc/keystone/keystone.conf`` file for a
|
||||
single LDAP server, or ``/etc/keystone/domains/keystone.DOMAIN_NAME.conf``
|
||||
files for multiple back ends. Example configurations appear below each
|
||||
setting summary:
|
||||
|
||||
@ -184,9 +191,9 @@ Filters
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[ldap]
|
||||
user_filter = (memberof=cn=openstack-users,ou=workgroups,dc=example,dc=org)
|
||||
group_filter =
|
||||
[ldap]
|
||||
user_filter = (memberof=cn=openstack-users,ou=workgroups,dc=example,dc=org)
|
||||
group_filter =
|
||||
|
||||
Identity attribute mapping
|
||||
Mask account status values (include any additional attribute
|
||||
@ -197,7 +204,7 @@ Identity attribute mapping
|
||||
update.
|
||||
|
||||
For example, you can mask Active Directory account status attributes
|
||||
in the :file:`keystone.conf` file:
|
||||
in the ``keystone.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -235,9 +242,11 @@ Enabled emulation
|
||||
user_enabled_emulation_dn = false
|
||||
|
||||
When you have finished configuration, restart the OpenStack Identity
|
||||
service::
|
||||
service:
|
||||
|
||||
# service keystone restart
|
||||
.. code-block:: console
|
||||
|
||||
# service keystone restart
|
||||
|
||||
.. warning::
|
||||
|
||||
|
||||
@ -40,7 +40,7 @@ providing user authentication through the LDAP directory.
|
||||
The 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 configure Identity, set options
|
||||
in the :file:`/etc/keystone/keystone.conf` file. See
|
||||
in the ``/etc/keystone/keystone.conf`` file. See
|
||||
:ref:`integrate-identity-backend-ldap` for Identity back end configuration
|
||||
examples and :ref:`integrate-assignment-backend-ldap` for assignment back
|
||||
end configuration examples. Modify these examples as needed.
|
||||
@ -56,7 +56,7 @@ end configuration examples. Modify these examples as needed.
|
||||
|
||||
**To define the destination LDAP server**
|
||||
|
||||
#. Define the destination LDAP server in the :file:`keystone.conf` file:
|
||||
#. Define the destination LDAP server in the ``keystone.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -78,8 +78,8 @@ end configuration examples. Modify these examples as needed.
|
||||
|
||||
**Additional LDAP integration settings**
|
||||
|
||||
Set these options in the :file:`/etc/keystone/keystone.conf` file for a
|
||||
single LDAP server, or :file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf`
|
||||
Set these options in the ``/etc/keystone/keystone.conf`` file for a
|
||||
single LDAP server, or ``/etc/keystone/domains/keystone.DOMAIN_NAME.conf``
|
||||
files for multiple back ends. Example configurations appear below each
|
||||
setting summary:
|
||||
|
||||
@ -129,13 +129,13 @@ indicates indefinite wait) and lifetime in seconds.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[ldap]
|
||||
use_pool = true
|
||||
pool_size = 10
|
||||
pool_retry_max = 3
|
||||
pool_retry_delay = 0.1
|
||||
pool_connection_timeout = -1
|
||||
pool_connection_lifetime = 600
|
||||
[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 user authentication**
|
||||
|
||||
@ -151,7 +151,9 @@ seconds.
|
||||
auth_pool_connection_lifetime = 60
|
||||
|
||||
When you have finished the configuration, restart the OpenStack Identity
|
||||
service::
|
||||
service.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# service keystone restart
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ Once you verify the location of your certificate authority file:
|
||||
|
||||
**To configure TLS encryption on LDAP traffic**
|
||||
|
||||
#. Open the :file:`/etc/keystone/keystone.conf` configuration file.
|
||||
#. Open the ``/etc/keystone/keystone.conf`` configuration file.
|
||||
|
||||
#. Find the ``[ldap]`` section.
|
||||
|
||||
@ -50,7 +50,9 @@ Once you verify the location of your certificate authority file:
|
||||
* ``never`` - A certificate will never be requested.
|
||||
|
||||
On distributions that include openstack-config, you can configure TLS
|
||||
encryption on LDAP traffic by running the following commands instead::
|
||||
encryption on LDAP traffic by running the following commands instead.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# openstack-config --set /etc/keystone/keystone.conf \
|
||||
ldap use_tls True
|
||||
|
||||
@ -10,7 +10,7 @@ additional security mechanism ensures that if a token is stolen, for
|
||||
example, it is not usable without external authentication.
|
||||
|
||||
You configure the authentication types for a token binding in the
|
||||
:file:`keystone.conf` file:
|
||||
``keystone.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
||||
@ -3,9 +3,9 @@ Keystone token providers
|
||||
========================
|
||||
|
||||
Tokens are used to interact with the various OpenStack APIs. The token type
|
||||
issued by keystone is configurable through the :file:`etc/keystone.conf` file.
|
||||
Currently, there are four supported token types and they include UUID, fernet,
|
||||
PKI, and PKIZ.
|
||||
issued by keystone is configurable through the ``etc/keystone.conf`` file.
|
||||
Currently, there are four supported token types and they include ``UUID``,
|
||||
``fernet``, ``PKI``, and ``PKIZ``.
|
||||
|
||||
UUID tokens
|
||||
~~~~~~~~~~~
|
||||
|
||||
Loading…
Reference in New Issue
Block a user