openstack/cinder
Code Issues Proposed changes

Merge "Fix service token documentation"

Browse Source
This commit is contained in:
Zuul 2023-02-17 20:29:08 +00:00 committed by Gerrit Code Review
commit bc8fcd7c3e
1 changed files with 21 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
doc/source/configuration/block-storage/service-token.rst
View File

@ -53,15 +53,20 @@ following:
3. Also in that section, fill in the appropriate configuration for
your service user (``username``, ``project_name``, etc.)
.. note::
There is no configuration required for a service to *receive*
service tokens. This is automatically handled by the keystone
middleware used by each service (beginning with the Pike release).
4. If Cinder is going to receive service tokens from other services
it needs to have two options configured in the
``[keystone_authtoken]`` section of the configuration file:
(The previous statement is true for the default configuration. It
is possible for someone to change some settings so that service
tokens will be ignored. See the :ref:`service-token-troubleshooting`
section below.)
``service_token_roles``
The value is a list of roles; the service user passing the service
token must have at least one of these roles or the token will be
rejected. The default value is ``service``.
``service_token_roles_required``
This is a boolean; the default value is ``False``. It governs whether
the keystone middleware used by the receiving service will pay any
attention to the ``service_token_roles`` setting. It should be set
to ``True``.
.. _service-token-troubleshooting:
@ -85,34 +90,14 @@ Identity Service (Keystone).
requires Keystone validation (for example, the Swift backend) and the
user token has expired.
2. Each receiving service, by default, is set up to accept service tokens.
There are two options to be aware of, however, that can affect whether or
not a receiving service (for example, Glance) will actually accept service
tokens. These appear in the ``[keystone_authtoken]`` section of the
**receiving service** configuration file (for example,
``/etc/glance/glance-api.conf``).
2. There are several things to pay attention to in Keystone:
``service_token_roles``
The value is a list of roles; the service user passing the service
token must have at least one of these roles or the token will be
rejected. (But see the next option.) The default value is
``service``.
``service_token_roles_required``
This is a boolean; the default value is ``false``. It governs whether
the keystone middleware used by the receiving service will pay any
attention to the ``service_token_roles`` setting. (Eventually the
default is supposed to become True, but it's still False as of Stein.)
3. There are several things to pay attention to in Keystone:
* If you've decided to turn on ``service_token_roles_required`` for any of
the receiving services, then you must make sure that any service user who
will be contacting that receiving service (and for whom you want to
enable "service token" usage) has one of the roles specified in the
receiving services's ``service_token_roles`` setting. (This is a matter
of creating and assigning roles using the Identity Service API, it's
not a configuration file issue.)
* When ``service_token_roles_required`` is enabled you must make sure that
any service user who will be contacting that receiving service (and for
whom you want to enable "service token" usage) has one of the roles
specified in the receiving services's ``service_token_roles`` setting.
(This is a matter of creating and assigning roles using the Identity
Service API, it's not a configuration file issue.)
* Even with a service token, an expired user token cannot be used
indefinitely. There's a Keystone configuration setting that controls
@ -136,4 +121,4 @@ To summarize, you need to be aware of:
* Each source service: must be configured to be able to create and send
service tokens (default is OFF)
* Each receiving service: has to be configured to accept service tokens
(default is ON)
(default is ON) and require role verification (default is OFF)