Stein Series Release Notes

15.0.1-9

Bug Fixes

  • [bug 1839133] Makes user_enabled_emulation_use_group_config honor group_members_are_ids.

  • [bug 1878938] Previously when a user used to have system role assignment and tries to delete the same role, the system role assignments still existed in system_assignment table. This causes keystone to return HTTP 404 Not Found errors when listing role assignments with names (e.g., –names or ?include_names).

    If you are affected by this bug, you must remove stale role assignments manually. The following is an example SQL statement you can use to fix the issue, but you should verify it’s applicability to your deployment’s SQL implementation and version.

    SQL:

    • delete from system_assignment where role_id not in (select id from role);

  • [bug 1885753] Keystone’s SQL identity backend now retries update user requests to safely handle stale data when two clients update a user at the same time.

  • [bug 1889936] Properly decode octet strings, or byte arrays, returned from LDAP.

15.0.1

Upgrade Notes

  • [bug 1872737] Added a default TTL of 15 minutes for signed EC2 credential requests, where previously an EC2 signed token request was valid indefinitely. This change in behavior is needed to protect against replay attacks.

Critical Issues

  • [bug 1855080] An error in the policy target filtering inadvertently allowed any user to list any credential object with the /v3/credentials API when [oslo_policy]/enforce_scope was set to false, which is the default. This has been addressed: users with non-admin roles on a project may not list other users’ credentials. However, users with the admin role on a project may still list any users credentials when [oslo_policy]/enforce_scope is false due to bug 968696.

  • [bug 1872733] Fixed a critical security issue in which an authenticated user could escalate their privileges by altering a valid EC2 credential.

  • [bug 1872735] Fixed a security issue in which a trustee or an application credential user could create an EC2 credential or an application credential that would permit them to get a token that elevated their role assignments beyond the subset delegated to them in the trust or application credential. A new attribute app_cred_id is now automatically added to the access blob of an EC2 credential and the role list in the trust or application credential is respected.

Security Issues

  • [bug 1855080] An error in the policy target filtering inadvertently allowed any user to list any credential object with the /v3/credentials API when [oslo_policy]/enforce_scope was set to false, which is the default. This has been addressed: users with non-admin roles on a project may not list other users’ credentials. However, users with the admin role on a project may still list any users credentials when [oslo_policy]/enforce_scope is false due to bug 968696.

  • [bug 1872733] Fixed a critical security issue in which an authenticated user could escalate their privileges by altering a valid EC2 credential.

  • [bug 1872735] Fixed a security issue in which a trustee or an application credential user could create an EC2 credential or an application credential that would permit them to get a token that elevated their role assignments beyond the subset delegated to them in the trust or application credential. A new attribute app_cred_id is now automatically added to the access blob of an EC2 credential and the role list in the trust or application credential is respected.

  • [bug 1872737] Fixed an incorrect EC2 token validation implementation in which the timestamp of the signed request was ignored, which made EC2 and S3 token requests vulnerable to replay attacks. The default TTL is 15 minutes but is configurable.

  • [bug 1872755] Added validation to the EC2 credentials update API to ensure the metadata labels ‘trust_id’ and ‘app_cred_id’ are not altered by the user. These labels are used by keystone to determine the scope allowed by the credential, and altering these automatic labels could enable an EC2 credential holder to elevate their access beyond what is permitted by the application credential or trust that was used to create the EC2 credential.

  • [bug 1873290] [bug 1872735] Fixed the token model to respect the roles authorized OAuth1 access tokens. Previously, the list of roles authorized for an OAuth1 access token were ignored, so when an access token was used to request a keystone token, the keystone token would contain every role assignment the creator had for the project. This also fixed EC2 credentials to respect those roles as well.

Bug Fixes

  • [bug 1773967] Fixes an issue where users who had role assignments only via a group membership and not via direct assignment could create but not use application credentials. It is important to note that federated users who only have role assignments via a mapped group membership still cannot create application credentials.

  • [bug 1782922] Fixed the problem where Keystone indiscriminately return the first RDN as the user ID, regardless whether it matches the configured ‘user_id_attribute’ or not. This will break deployments where ‘group_members_are_ids’ are set to False and ‘user_id_attribute’ is not in the DN. This patch will perform a lookup by DN if the first RND does not match the configured ‘user_id_attribute’.

  • [bug 1831918] Credentials now logs cadf audit messages.

  • [bug 1832265] Binary msgpack payload types are now consistently and correctly decoded when running Keystone under Python 3, avoiding any TypeErrors when attempting to convert binary encoded strings into UUID’s.

  • [bug 1840291] Adds retries for delete_credential_for_user method to avoid DBDeadlocks when deleting large number of credentials concurrently.

  • [bug 1843609 <https://bugs.launchpad.net/keystone/+bug/1843609>] Fixed an issue where system-scoped tokens couldn’t be used to list users and groups (e.g., GET /v3/users or GET /v3/groups) if keystone.conf [identity] domain_specific_drivers_enabled=True and the API would return an HTTP 401 Unauthorized. These APIs now recognize system-scoped tokens when using domain-specific drivers.

  • [bug 1856881] keystone-manage bootstrap can be run in upgrade scenarios where pre-existing domain-specific roles exist named admin, member, and reader.

  • [Bug 1856904] The initiator object for CADF notifications now will always contain the username for the user who initated the action. Previously, the initator object only contained the user_id, which lead to issues mapping to users when using LDAP-backed identity providers. This also helps the initiator object better conform to the OpenStack standard for CADF.

  • [bug 1858012] Fixes a bug in the /v3/role_assignments filtering where the role.id query parameter didn’t properly filter role assignments by role in cases where there were multiple system role assignments.

  • [bug 1872733] Fixed a critical security issue in which an authenticated user could escalate their privileges by altering a valid EC2 credential.

  • [bug 1872735] Fixed a security issue in which a trustee or an application credential user could create an EC2 credential or an application credential that would permit them to get a token that elevated their role assignments beyond the subset delegated to them in the trust or application credential. A new attribute app_cred_id is now automatically added to the access blob of an EC2 credential and the role list in the trust or application credential is respected.

  • [bug 1872737] Fixed an incorrect EC2 token validation implementation in which the timestamp of the signed request was ignored, which made EC2 and S3 token requests vulnerable to replay attacks. The default TTL is 15 minutes but is configurable.

  • [bug 1872755] Added validation to the EC2 credentials update API to ensure the metadata labels ‘trust_id’ and ‘app_cred_id’ are not altered by the user. These labels are used by keystone to determine the scope allowed by the credential, and altering these automatic labels could enable an EC2 credential holder to elevate their access beyond what is permitted by the application credential or trust that was used to create the EC2 credential.

  • [bug 1873290] [bug 1872735] Fixed the token model to respect the roles authorized OAuth1 access tokens. Previously, the list of roles authorized for an OAuth1 access token were ignored, so when an access token was used to request a keystone token, the keystone token would contain every role assignment the creator had for the project. This also fixed EC2 credentials to respect those roles as well.

15.0.0

Prelude

This release leverages oslo.policy’s policy-in-code feature to modify the default check strings and scope types for nearly all of keystone’s API policies. These changes make the policies more precise than they were before, using the reader, member, and admin roles where previously only the admin role and a catch-all rule was available. The changes also take advantage of system, domain, and project scope, allowing you to create role assignments for your users that are appropriate to the actions they need to perform. Eventually this will allow you to set [oslo_policy]/enforce_scope=true in your keystone configuration, which simplifies access control management by ensuring that oslo.policy checks both the role and the scope on API requests. However, please be aware that not all policies have been converted in this release and some changes are still under development. During the transition phase, if you have not overridden a policy, the old default and the new default will be OR’d together. This means that, for example, where we have changed the policy rule from 'rule:admin_required' to 'role:reader and system_scope:all', both policy rules will be in effect. Please check your current policies and role assignments before upgrading to ensure the policies will not be too permissive for your deployment. To hide the deprecation warnings and opt into the less permissive rules, you can override the policy configuration to use the newer policy rule.

New Features

  • [bug 1669080] Added support for a description attribute for V3 Identity Roles, see API docs for details.

  • [blueprint json-web-tokens] Keystone now supports a JSON Web Signature (JWS) token provider in addition to fernet tokens. Fernet token remain the default token provider. Full details can be found in the specification.

  • [blueprint mfa-auth-receipt] Added support for auth receipts. Allows multi-step authentication for users with configured MFA Rules. Partial authentication with successful auth methods will return an auth receipt that can be consumed in subsequent auth attempts along with the missing auth methods to complete auth and be provided with a valid token.

  • [Community Goal] Support has been added for developers to write pre-upgrade checks. Operators can run these checks using keystone-status upgrade check. This allows operators to be more confident when upgrading their deployments by having a tool that automates programmable checks against the deployment configuration or dataset.

  • [bug 1748027] The user API now supports the admin, member, and reader default roles across system-scope, domain-scope, and project-scope.

  • [bug 1750660] The project API now supports the admin, member, and reader default roles across system-scope, domain-scope, and project-scope.

  • [bug 1805368] [bug 1750669] The system assignment API now supports the admin, member, and reader default roles across system-scope, domain-scope, and project-scope. The grant API now supports the admin, member, and reader default roles for system-scope.

  • [bug 1750673] The role assignment API now supports the admin, member, and reader default roles across system-scope, domain-scope, and project-scope.

  • [bug 1794376] The domain API now supports the admin, member, and reader default roles.

  • [bug 1801095] Request ID and global request ID have been added to both basic and CADF notifications.

  • [bug 1804446] The regions API now supports the admin, member, and reader default roles.

  • [bug 1804463] The services API now supports the admin, member, and reader default roles.

  • [bug 1804483] The endpoint API now supports the admin, member, and reader default roles.

  • [bug 1804516] The federated identity provider API now supports the admin, member, and reader default roles.

  • [bug 1804521] The federated mapping API now supports the admin, member, and reader default roles.

  • [bug 1804522] The federated service provider API now supports the admin, member, and reader default roles.

  • [bug 1804523] The federated protocol API now supports the admin, member, and reader default roles.

  • [bug 1805369] The group API now supports the admin, member, and reader default roles.

  • [bug 1808859] The group API now supports using the domain scope type for performing domain-specific actions on groups and group membership.

  • [bug 1805372] The registered limit and limit API now support the admin, member, and reader default roles.

  • [bug 1805402] The role API now supports the admin, member, and reader default roles.

  • [bug 1805403] The project API now supports the admin, member, and reader default roles.

  • [bug 1805406] The user API now supports the admin, member, and reader default roles.

  • [blueprint domain-level-limit] Keystone now supports domain level unified limit. When creating a limit, users can specify a domain_id instead of project_id. For flat model, the domain limit is still non-hierarchical. For strict-two-level model, the domain limit is now considered as the first level, so that the project limit is the second level and the project can’t contain any child.

Upgrade Notes

  • [blueprint mfa-auth-receipt] Auth receipts share the same fernet mechanism as tokens and by default will share keys with tokens and work out of the box. If your fernet key directory is not the default, you will need to also configure the receipt key directory, but they can both point to the same location allowing key rotations to affect both safely. It is possible to split receipt and token keys and run rotatations separately for both if needed.

  • [bug 1748027] The user API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides user policies.

  • [bug 1750660] The project API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides project policies.

  • [bug 1805368] [bug 1750669] The system assignment and grant APIs uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides system assignment policies.

  • [bug 1750673] The role assignment API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new policies if your deployment overrides role assignment policies.

  • [bug 1787874] Please note that the deployment which sets unique_last_password_count = 1 in the config file should update the value to 0 to keep the same behavior as before.

  • [bug 1788415] [bug 968696] Policies protecting the /v3/credentials API have changed defaults in order to make the credentials API more accessible for all users and not just operators or system administrator. Please consider these updates when using this version of keystone since it could affect API behavior in your deployment, especially if you’re using a customized policy file.

  • [bug 1794376] The domain API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides domain policies.

  • [bug 1794864] [bug 1794376] The default policies that protect the domains API have been deprecated in favor of ones that are more secure and self-serviceable. If you’re maintaining custom policies, please make sure you resolve your domain policies to work with the new default by adding the proper role assignments, or continue maintaining custom overrides. The new defaults allow for better protection of the domains API when giving the admin role to users on domains and projects.

  • [bug 1804292] The region policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the region API and implementing default roles.

  • [bug 1804446] The regions API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides region policies.

  • [bug 1804462] The service policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the service API and implementing default roles.

  • [bug 1804463] The services API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides service policies.

  • [bug 1804482] The endpoint policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the endpoint API and implementing default roles.

  • [bug 1804483] The endpoint API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides endpoint policies.

  • [bug 1804516] The federated identity provider API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides federated identity provider policies.

  • [bug 1804517] The federated identity provider policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the identity provider API and implementing default roles.

  • [bug 1804519] The federated mapping policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the mapping API and implementing default roles.

  • [bug 1804520] The federated service provider policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the service provider API and implementing default roles.

  • [bug 1804521] The federated mapping API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides federated mapping policies.

  • [bug 1804522] The federated service provider API uses new default policies that make it more accessible to end users and administrators. Please consider these new defaults if your deployment overrides federated service provider policies.

  • [bug 1804523] The federated protocol API uses new default policies that make it more accessible to end users and administrators. Please consider these new defaults if your deployment overrides federated protocol policies.

  • [bug 1805369] The group API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides group policies.

  • [bug 1805372] Several of the registered limit and limit policies have been deprecated. The following policies now use role:admin and system_scope:all instead of rule:admin_required:

    • identity:create_registered_limits

    • identity:update_registered_limit

    • identity:delete_registered_limit

    • identity:create_limits

    • identity:update_limit

    • identity:delete_limit

    These policies are not being formally deprecated because the unified limits API is still considered experimental. These new default automatically account for system-scope. Please consider these new defaults if your deployment overrides the registered limit or limit policies.

  • [bug 1805402] The role API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides role policies.

  • [bug 1805403] The project API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides project policies.

  • [bug 1805406] The GET /v3/users/{user_id API now properly returns an HTTP 403 Forbidden as opposed to HTTP 404 Not Found if the calling user doesn’t have authorization to call the API. This applies consistent authorititive policy checks to the API.

    The user API uses new default policies that make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides user policies.

  • [bug 1805880] The registered limit policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the registered limit API and implementing default roles.

  • [bug 1806713] The role policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the role API and implementing default roles.

  • [bug 1806762] The user policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope, domain-scope, and project-scope into the user API and implementing default roles.

  • [bug 1804462] The group policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope and domain-scope into the groups API and implementing default roles.

  • [bug 1806762] The domain policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope into the domain API and implementing default roles. Additionally, the identity:get_domain policy in policy.v3cloudsample.json has been relaxed slightly to allow all users with role assignments on a domain to retrieve that domain, as opposed to only allowing users with the admin role to access that policy.

    All policies in policy.v3cloudsample.json that are redundant with the defaults in code have been removed. This improves maintainability and leaves the policy.v3cloudsample.json policy file with only overrides. These overrides will eventually be moved into code or new defaults in keystone directly. If you’re using the policies removed from policy.v3cloudsample.json please check to see if you can migrate to the new defaults or continue maintaining the policy as an override.

  • [bug 1806762] [bug 1804518] The protocol policies defined in the policy.v3cloudsample.json policy file have been removed. These policies are now obsolete after incorporating system-scope into the federated protocol API and implementing default roles.

  • The assignment driver interface has changed to use the named parameter ‘project_id’ instead of ‘tenant_id’.

Deprecation Notes

  • [bug 1748027] The user policies have been deprecated. The identity:get_user policy now uses (role:reader and system_scope:all) or (role:reader and token.domain.id:%(target.user.domain_id)s) or user_id:%(target.user.id)s instead of rule:admin_or_owner. The identity:list_users policy now uses (role:reader and system_scope:all) or (role:reader and domain_id:%(target.domain_id)s) instead of rule:admin_required. The identity:create_user, identity:update_user, and identity:delete_user policies now use (role:admin and system_scope:all) or (role:admin and token.domain.id:%(target.user.domain_id)s) instead of rule:admin_required. These new defaults automatically include support for a read-only role and allow for more granular access to user APIs, making it easier for system and domain administrators to delegate authorization, safely. Please consider these new defaults if your deployment overrides user policies.

  • [bug 1750660] The project policies have been deprecated. The identity:get_project policy now uses (role:reader and system_scope:all) or (role:reader and domain_id:%(target.project.domain_id)s) or project_id:%(target.project.id)s instead of rule:admin_required or project_id:%(target.project.id)s. The identity:list_projects policy now uses (role:reader and system_scope:all) or (role:reader and domain_id:%(target.domain_id)s instead of rule:admin_required. The identity:list_user_projects policy now uses (role:reader and system_scope:all) or (role:reader and domain_id:%(target.user.domain_id)s) or user_id:%(target.user.id)s instead of rule:admin_or_owner. The identity:create_project now uses (role:admin and system_scope:all) or (role:admin and domain_id:%(target.project.domain_id)s) instead of rule:admin_required. These new defaults automatically include support for a read-only role and allow for more granular access to project APIs, making it easier for system and domain administrators to delegate authorization, safely. Please consider these new defaults if your deployment overrides the project policies.

  • [bug 1805368] [bug 1750669] The system assignment and grant policies have been deprecated. The identity:list_system_grants_for_user, identity:check_system_grant_for_user, identity:list_system_grants_for_group, and identity:check_system_grant_for_group policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_system_grant_for_user, identity:revoke_system_grant_for_user, identity:create_system_grant_for_group, and identity:revoke_system_grant_for_group policies now use role:admin and system_scope:all instead of rule:admin_required. The identity:check_grant and identity:list_grants policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_grant and identity:revoke_grant policies now use role:admin and system_scope:all instead of rule:admin_required. These new defaults automatically include support for a read-only role and allow for more granular access to the system assignment and grant APIs, making it easier for administrators to delegate authorization, safely. Please consider these new defaults if your deployment overrides the system assignment APIs.

  • [bug 1750673] The role assignment identity:list_role_assignments policy now uses (role:reader and system_scope:all) or (role:reader and domain_id:%(target.domain.id)s) instead of rule:admin_required. This new default automatically includes support for a read-only role and allows for more granular access to the role assignment API. Please consider this new default if your deployment overrides the role assignment policies.

  • [bug 1794376] The following domain policy check strings have been deprecated in favor of more clear and concise defaults:

    • identity:get_domain

    • identity:list_domains

    • identity:create_domain

    • identity:update_domain

    • identtity:delete_domain

    Please consider these new default if your deployment overrides domain policies.

  • [bug 1794864] [bug 1794376] The default policies that protect the domains API have been deprecated in favor of ones that are more secure and self-serviceable. If you’re maintaining custom policies, please make sure you resolve your domain policies to work with the new default by adding the proper role assignments, or continue maintaining custom overrides. The new defaults allow for better protection of the domains API when giving the admin role to users on domains and projects.

  • [bug 1804446] The identity:create_region, identity:update_region, and identity:delete_region policies now use role:admin and system_scope:all instead of rule:admin_required. These new defaults automatically account for system-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides the region policies.

  • [bug 1804463] The service policies have been deprecated. The identity:get_service and identity:list_services policies now use (role:reader and system_scope:all) instead of rule:admin_required. The identity:create_service, identity:update_service, and identity:delete_service policies now use (role:admin and system_scope:all) instead of rule:admin_required. These new defaults automatically account for system-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides service policies.

  • [bug 1804483] The endpoint policies have been deprecated. The identity:list_endpoints and identity:get_endpoint policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_endpoint, identity:update_endpoint, and identity:delete_endpoint policies now use role:admin and system_scope:all instead of rule:admin_required. These new defaults automatically account for system-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides the endpoint policies.

  • [bug 1804516] The federated identity provider policies have been deprecated. The identity:list_identity_providers and identity:get_identity_provider policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_identity_provider, identity:update_identity_provider, identity:delete_identity_provider policies now use role:admin and system_scope:all instead of rule:admin_required. These new defaults automatically account for system-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides the federated identity provider policies.

  • [bug 1804521] The federated mapping policies have been deprecated. The identity:list_mappings and identity:get_mapping policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_mapping, identity:update_mapping, and identity:delete_mapping policies now use role:admin and system_scope:all instead of rule:admin_required. These new defaults automatically account for system-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides the federated mapping policies.

  • [bug 1804522] The federated service provider policies have been deprecated. The identity:get_service_provider and identity:list_service_providers policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_service_provider, identity:update_service_provider, and identity:delete_service_provider policies now use role:admin and system_scope:all instead of rule:admin_required. These new defaults automatically include support for a read-only role and allow for more granular access to service provider APIs, making it easier for system administrators to delegate authorization. Please consider these new defaults if your deployment overrides the federated service provider policies.

  • [bug 1804523] The federated protocol policies have been deprecated. The identity:get_protocol and identity:list_protocols now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_protocol, identity:update_protocol, and identity:delete_protocol policies now use role:admin and system_scope:all instead of rule:admin_required. These new defaults automatically account for system-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides the federated protocol policies.

  • [bug 1805369] The group policies have been deprecated. The identity:get_group, identity:list_groups, identity:list_users_in_group, and identity:check_user_in_group policies now use role:reader and system_scope:all or (role:reader and domain_id:%(target.group.domain_id)s) instead of rule:admin_required. The identity:list_groups_for_user policy now uses (role:reader and system_scope:all) or (role:reader and domain_id:%(target.user.domain_id)s) or or user_id:%(user_id)s instead of rule:admin_or_owner. The identity:create_group, identity:update_group, identity:delete_group, identity:remove_user_from_group, and identity:add_user_to_group policies now use role:admin and system_scope:all or (role:admin and domain_id:%(target.group.domain_id)s) instead of rule:admin_required. These new defaults automatically account for system-scope and domain-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides group policies.

  • [bug 1805402] The role policies have been deprecated. The identity:get_role and identity:list_roles policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_role, identity:update_role, and identity:delete_role policies now use role:admin and system_scope:all instead of rule:admin_required. These new defaults automatically account for system-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides the role policies.

  • [bug 1805403] The project policies have been deprecated. The identity:get_project policy now uses (role:reader and system_scope:all) or project_id:%(target.project.id)s instead of rule:admin_required or project_id:%(target.project.id)s. The identity:list_projects policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:create_project, identity:update_project, and identity:delete_project policies now use role:admin and system_scope:all instead of rule:admin_required. The identity:list_user_projects policy now uses (role:admin and system_scope:all) or user_id:%(target.user.id)s instead of rule:admin_or_owner. These new defaults automatically account for system-scope and support a read-only role, making it easier for system administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides the project policies.

  • [bug 1805406] The user policies have been deprecated. The identity:get_user now uses (role:reader and system_scope:all) or (role:reader and token.domain.id:%(target.user.domain_id)s) or user_id:%(target.user.id)s instead of rule:admin_or_owner. The identity:list_users policy now uses (role:reader and system_scope:all) or (role:reader and domain_id:%(target.domain_id)s) instead of rule:admin_required. The identity:create_user, identity:update_user, and identity:delete_user policies now use (role:admin and system_scope:all) or (role:admin and token.domain.id:%(target.user.domain_id)s) instead of rule:admin_required. These new defaults automatically account for system-scope, domain-scope, and support a read-only role, making it easier for system and domain administrators to delegate subsets of responsibility without compromising security. Please consider these new defaults if your deployment overrides the user policies.

  • The commandline options standard-threads, `pydev-debug-host and pydev-debug-port are only used by Keystone eventlet model in Newton release before. They are deprecated now and will be removed in the next release.

Security Issues

  • [bug 1748027] The user API now uses system-scope, domain-scope, project-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1750660] The project API now uses system-scope, domain-scope, project-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1805368] [bug 1750669] The system assignment API now uses system-scope, domain-scope, project-scope, and default roles to provide better accessibility to users in a secure way. The grant API now uses system-scope and default to provide better accessbility to operators.

  • [bug 1750673] The role assignment API now uses system-scope, domain-scope, project-scope, and default roles to provide better accessbility to users in a secure way.

  • [bug 1788415] [bug 968696] More granular policy checks have been applied to the credential API in order to make it more self-service for users. By default, end users will now have the ability to manage their credentials.

  • [bug 1794376] The domain API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1794864] [bug 1794376] The default policies that protect the domains API have been deprecated in favor of ones that are more secure and self-serviceable.

  • [bug 1804446] The regions API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1804463] The services API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1804483] The endpoint API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1804516] The federated identity provider API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1804521] The federated mapping API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1804522] The federated service provider API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1804523] The federated protocol API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1805369] The group API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1808859] The group API now supports using the domain scope for the reader, member, and admin role to provide better accessibility to users in a secure way.

  • [bug 1805372] The registered limit and limit APIs now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1805402] The role API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1805403] The project API now uses system-scope and default roles to provide better accessibility to users in a secure way.

  • [bug 1805406] The user API now uses system-scope and default roles to provide better accessibility to users in a secure way.

Bug Fixes

  • [bug 1729933] The Region Update API now correctly updates extra values. Previously adding any extra values to a region via the update API would discard any added values besides the default ones. Any extra values are now correctly added and returned. This fix was for consistency with other APIs in keystone that use ‘extra’ and the use of ‘extra’ in keystone is highly discouraged.

  • [bug 1744195] The SQL Foreign Key is enabled for Keystone unit tests now. This is not an end user impact fixed. But for the downstream teams, please take care of it for your private test code changes.

  • [bug 1757151] More thorough documentation has been added for authorization and token scopes, which helps users and developers understand the purpose of scope and why it can be a useful tool for resource isolation and API protection.

  • [bug 1780503] The notification wrapper now sets the initiator’s id to the given user id. This fixes an issue where identity.authentication event would result in the initiator id being a random default UUID, rather than the user’s id when said user would authenticate against keystone.

  • [bug 1784536] Keystone now return 401 Unauthorized correctly when issuing a project-scoped token but the input project id is a domain id.

  • [bug 1787874] The default value of the config option unique_last_password_count is changed from 1 to 0. Now unique_last_password_count = 0 means password history check is disabled. unique_last_password_count = 1 means when changing password, the new one should be different than the current one.

  • [bug 1788415] [bug 968696] Improved self-service support has been implemented in the credential API. This means that end users have the ability to manage their own credentials as opposed to filing tickets to have deployment administrators manage credentials for users.

  • [bug 1788694] System-scoped tokens now support expanding role assignments to include implied roles in token creation and validation responses.

  • [bug 1789450] When a mapped group that does not exist in keystone is found, instead of throwing a 500 error, keystone will now log the instance and continue. This is expected behavior as an external IdP may specify a group that does not exist within keystone.

  • [bug 1792026] Formal documentation for user resource options has been added to the administrator guide and the API reference. This documentation helps describe how user options can improve user experience, namely for deployments looking to offer flexibility around PCI-DSS security requirements, among other things.

  • [bug 1794864] [bug 1794376] The default policies that protect the domains API have been deprecated in favor of ones that are more secure and self-serviceable. Users with roles on domains and projects are now able to call the GET /v3/domains/{domain_id} API if they use a token scoped to that domain or a token scoped to a project within that domain. System users are allowed to access the domain APIs in the same way legacy admin users were able to. This allows for better protection of the domain API when giving the admin role to users on domains and projects.

  • [bug 1796887] Add caching on trust role validation to improve performance. Services relying heavily on trusts are impacted as the trusts are validated against the database. This adds caching on those operations to improve performance

  • [bug 1801873] This fixes an issue where an LDAP-backed domain could not be deleted due to the existence of shadow users in the SQL database.

  • [bug 1804292] The region policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1804462] The service policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1804482] The endpoint policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1804517] The federated identity provider policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1804519] The federated mapping policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1804520] The federated service provider policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1805880] The registered limit policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1806713] The role policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1806762] The user policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1804462] The group policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1806762] The domain policies in policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1806762] [bug 1804518] The federated protocol policies in the policy.v3cloudsample.json policy file have been removed in favor of better defaults in code. These policies weren’t tested exhaustively and were misleading to users and operators.

  • [bug 1810393] Now when an identity provider protocol is deleted, the cache info for the related federated users will be invalidated as well.

  • [bug 1811605] Fixes X.509 tokenless auth by properly populating the request context with the necessary credential information. Since Stein release, RBAC has been using the credential information from the Keystone request context instead of the authentication context. Therefore, we’ll need to populate the request context with the necessary credential information from the X.509 tokenless authentication context.

  • [bug 1813085 <https://bugs.launchpad.net/keystone/+bug/1813085>] Validation of federated domain-scoped tokens scoped to the default domain no longer results in an HTTP 404 Domain Not Found due to byte string conversion issues with msgpack in python 3.

  • [bug 1814589] Fixes incorrect parameters passed into keystone.federation.utils.transform_to_group_ids() which resulted in HTTP 500 internal error.

  • [bug 1816927] It was discovered that the order in which fernet keys are distributed after fernet key rotation has impact on keystone service. All operators are advised to ensure that during fernet key distribution the new primary fernet key (with largest number) is distributed first.

  • [bug 1817313] Raise METHOD NOT ALLOWED for OS-Federation protocols creation if the protocol_id is not in the URL. The corrective action was to split the LIST from CRUD resources so that the routing regexes can work as expected.

  • [bug 1819036] Middleware that processes requests in front of keystone now caches tokens per request, eliminating unnecessary round trips to validate tokens on every request. This change doesn’t require the usage of any configuration options to take effect. The fix for this bug improved performance ~20% during testing and impacts most of keystone’s API.

  • [bug 1798184] [bug 1820333] In Python 3, python-ldap no longer allows bytes for some fields (DNs, RDNs, attribute names, queries). Instead, text values are represented as str, the Unicode text type. Compatibility support is provided for Python 2 by setting bytes_mode=False [1].

    The keystone LDAP backend is updated to adhere to this behavior by using bytes_mode=False for Python 2 and dropping UTF-8 encoding and decoding fields that are now represented as text in python-ldap.

    [1] More details about byte/str usage in python-ldap can be found at: http://www.python-ldap.org/en/latest/bytes_mode.html#bytes-mode

    Note that at a minimum python-ldappool 2.3.1 is required.

  • Some bugs for unified limit APIs have been fixed, it includes:

    • [bug 1798716] The region_id of registered limit now can be updated to None.

    • [bug 1798495] The length of unified limit’s resource_name now is limited from 1 to 255 (string).

    • [bug 1797876] The default_limit of registered limit and the resource_limit of limit now are limited from -1 to 2147483647 (integer). -1 means no limit. 2147483647 is the max value for integer by default in SQL (4 bytes).

Other Notes

  • [bug 1473292] If you’re relying on a custom implementation of the trust backend, please be sure to implement the new method prior to upgrading.

  • Keystone has been fully converted to run under flask. All of the APIs are now natively dispatched under flask.

    Included in this change is a removal of a legacy WSGI environment data holder calld openstack.params. The data holder was used exclusively for communicating data down the chain under paste-deploy. The data in openstack.params was generally “normalized” in an odd way and unreferenced in the rest of the OpenStack code-base.

    Some minor changes to the JSON Home document occured to make it consistent with the rest of our convensions (Technically an API contract break) but required for the more strict view the Keystone flask code takes on setting up the values for JSON Home. Notably “application_credentials” now has an appropriate entry for listing and creating new app creds.

    JSON Body and URL Normalising middleware were moved to a flask-native model.

    Any middleware defined in Keystone’s tree is no longer loaded via Stevedore, and likewise the entry points were removed.

    Original WSGI Framework (custom, home-rolled, based on WEBOB) has been removed from the codebase.

  • [blueprint removed-as-of-stein] The options member_role_id and member_role_name which were deprecated in Queens and only used for V2 are removed now.

  • [blueprint removed-as-of-stein] The deprecated option crypt_strength is removed now. It was only useful for sha512_crypt password hashes which has been superseded by more secure hashing implementations.

  • [blueprint removed-as-of-stein] The keystone.conf [DEFAULT] secure_proxy_ssl_header configuration option was slated for removal in Pike and has now officially been removed. Please use oslo.middleware.http_proxy_to_wsgi instead.

  • [blueprint removed-as-of-stein] The interface create_arguments_apply in token formatter payload has been removed. The token payload now doesn’t need to be force ordered any more.