diff options
Diffstat (limited to 'doc/source/configuration/block-storage/service-token.rst')
| -rw-r--r-- | doc/source/configuration/block-storage/service-token.rst | 57 |
1 files changed, 21 insertions, 36 deletions
diff --git a/doc/source/configuration/block-storage/service-token.rst b/doc/source/configuration/block-storage/service-token.rst index 108f4b0db..1c48552f2 100644 --- a/doc/source/configuration/block-storage/service-token.rst +++ b/doc/source/configuration/block-storage/service-token.rst @@ -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: + + ``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``. - (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_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``). - - ``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: +2. 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) |