ironic/releasenotes/notes/keystone-auth-3155762c524e44df.yaml

52 lines
2.4 KiB
YAML
Raw Normal View History

Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
---
upgrade:
- |
Changes the way to configure access credentials for OpenStack services
clients. For each service, both Keystone session options
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
(timeout, SSL-related ones) and Keystone auth_plugin options
(auth_url, auth_type and corresponding auth_plugin options)
should be specified in the configuration section for this service.
Configuration sections affected are:
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
* ``[neutron]`` for Neutron service user
* ``[glance]`` for Glance service user
* ``[swift]`` for Swift service user
* ``[inspector]`` for Ironic Inspector service user
* ``[service_catalog]`` *new section* for Ironic service user,
used to discover Ironic endpoint from Keystone Catalog
This enables fine tuning of authentication for each service.
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
Backward-compatible options handling is provided
using values from ``[keystone_authtoken]`` config section,
but operators are advised to switch to the new config options as the
old options are deprecated. The old options will be removed during the
Ocata cycle.
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
For more information on sessions, auth plugins and their settings,
please refer to http://docs.openstack.org/developer/keystoneauth/.
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
- |
Small change in semantics of default for ``[neutron]/url`` option
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
* default is changed to None.
* For the case when ``[neutron]/auth_strategy`` is ``noauth``,
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
default means use ``http://$my_ip:9696``.
* For the case when ``[neutron]/auth_strategy`` is ``keystone``,
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
default means to resolve the endpoint from Keystone Catalog.
- New config section ``[service_catalog]`` for access credentials used
to discover Ironic API URL from Keystone Catalog.
Previously credentials from ``[keystone_authtoken]`` section were used,
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
which is now deprecated for such purpose.
deprecations:
- The ``[keystone_authtoken]`` configuration section is deprecated for
configuring clients for other services (but is still used for configuring
API token authentication), in favor of the ``[service_catalog]`` section.
The ability to configure clients for other services via the
``[keystone_authtoken]`` section will be removed during the Ocata cycle.
Migrate to using keystoneauth Sessions We currently construct Keystone client objects directly, which is no longer the preferred way. Instead, we should be using Sessions which allows use of different auth plugins. This change attempts to migrate our Keystone usage to this model. Additionally, we currently rely on the imported keystonemiddleware auth_token's configuration for all of the Keystone credentials used by the Ironic service user. This is bad, as that config is internal to that library and may change at any time. Also, the service user may be using different credentials than the token validator. This refactors the keystone module to use Sessions. It attempts to provide some backward compat for users who have not yet updated their config, by falling back to the authtoken config section when required. Operators impact: - Authentification parameters for each service now should specified in the corresponding config section for this service ([glance], [neutron] [swift], [inspector]). This includes providing both Keystone session-related options (timeout, SSL-related ones) and authentification options (`auth_type`, `auth_url` and proper options for the auth plugin). - New config section `service_catalog` for Ironic service user credentials, used to resolve Ironic API URL from Keystone catalog. - If loading from the service config section fails, an attempt is made to use respective options from [keystone_authtoken] section as a fall-back for backward compatibility. Implementation details: - using keystoneauth1 library instead of keystoneclient - For each service the keystone session is created only once and is reused further. This lowers the number of authentification requests made to Keystone but implies that only auth plugins that can re-authentificate themselves can be used (so no *Token plugins). This patch does not update the DevStack plugin, in order to test backwards compatibility with old config options. DevStack plugin will be modified in a subsequent patch. Change-Id: I166eebefc1e1335a1a7b632149cf6441512e9d5e Closes-Bug: #1422632 Related-Bug: #1418341 Related-Bug: #1494776 Co-Authored-By: Adam Gandelman <adamg@ubuntu.com>
2016-03-23 17:54:59 +02:00
fixes:
- Do not rely on keystonemiddleware config options for instantiating
clients for other OpenStack services.
This allows changing keystonemiddleware options from legacy ones
and thus support Keystone V3 for token validation.