Train Series Release Notes

16.0.2-9

Security Issues

  • [bug 1992183] [CVE-2022-2447] Tokens issued with application credentials will now have their expiration validated against that of the application credential. If the application credential expires before the token the token’s expiration will be set to the same expiration as the application credential. Otherwise the token will use the configured value.

Bug Fixes

  • [bug 1848342] There was an inconsistency in the ephemeral user update flow. Every time a federated user logged in, keystone created an entry in the local_user table instead of just updating the entries in the user and federated_user tables, which caused duplicate entries when listing users. Now, the keystone will not create the entry in the local_user table while updating an ephemeral user.

    If you are affected by this bug, a fix in the keystone database will be needed so we recommend to dump the users’ tables before doing this process:

    mysql db example:

    • mysqldump -h <mysql host> -p -P <mysql port> -u keystone keystone federated_user local_user user > user_tables.sql

    • mysql -h <mysql host> -D keystone -p -P <mysql port> -u keystone -e ‘delete from local_user where user_id in (select user_id from federated_user);’

    SQL:

    • delete from local_user where user_id in (select user_id from federated_user);

16.0.2

Security Issues

  • [bug 1901207] Policy enforcement for application credentials has been updated to protect against invalid ownership checks resulting in unauthorized users being able to get and delete application credentials for other users.

Bug Fixes

  • [bug 1688137] Fixed the AccountLocked exception being shown to the end user since it provides some information that could be exploited by a malicious user. The end user will now see Unauthorized instead of AccountLocked, preventing user info oracle exploitation.

  • [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.

  • [bug 1896125] Introduced more robust connection handling for asynchronous LDAP requests to address memory leaks fetching data from LDAP backends with low page sizes.

  • [bug 1901654] Previously, generate_public_ID() in sha256.py assumed the passed arguments is str data type. However, python-ldap 3.0 or later returns bytes data type for attribute values except fields of distinguished names, relative distinguished names, attribute names, queries. If keystone running on Python3 is integrated with LDAP and the LDAP server has local_id variable in its attribute, user login operations will fail due to the assumption and modifiation of python-ldap. By this fix, generate_public_ID() properly handles bytes data type in the parameter.

16.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 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 1856962] Fixes an issue where federated users could not authenticate if their mapped group membership was empty.

  • [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.

16.0.0

Prelude

[blueprint whitelist-extension-for-app-creds] This release adds support for delegating fine-grained privileges to application credentials via access rules. Access rules act as a whitelist of APIs that an application credential is allowed to use. Regular RBAC is still enforced by oslo.policy. See the API reference for details.

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

  • The keystone-manage bootstrap command can now be used to update existing endpoints idempotently, which is useful in conjunction with configuration management tools that use this command for both initialization and lifecycle management of keystone.

  • [blueprint whitelist-extension-for-app-creds] This release adds support for delegating fine-grained privileges to application credentials via access rules. Access rules act as a whitelist of APIs that an application credential is allowed to use. Regular RBAC is still enforced by oslo.policy. See the API reference for details.

  • [bug 1724645] Adds a new attribute, remote_id_attribute, to the federation protocol object, which allows WebSSO authentication to forward authentication requests through the right implementation for a federated protocol based on the remote ID attribute in the authentication headers.

  • [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 1750678] The EC2 credentials API now supports the admin, member, and reader default roles.

  • Allow the creating of a domain with the additional, optional parameter of explicit_domain_id instead of auto-creating a domain_id from a UUID.

    When keeping two Keystone servers in sync, but avoiding Database replication, it was often necessary to hack the database to update the Domain ID so that entries match. Domain ID is then used for LDAP mapped IDs, and if they don’t match, the user IDs are different. It should be possible to add a domain with an explicit ID, so that the two servers can match User IDs. The reason that the variable name is not simple domain_id is twofold: First to keep people from thinking that this is a required, or at least suggested field. Second, to prevent copy errors when creating a new domain, where the domain_id would be copied in from the old one, and having spurious failures, or undesirecd domain_id matching.

    https://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/explicit-domains-ids.html

  • [bug 1805363] The oauth1 consumer API now supports the admin, member, and reader default roles.

  • [bug 1805366] The Domain Config API now supports the admin, member, and reader default roles.

  • [bug 1805368] [bug 1750669] The grant API now supports the admin, member, and reader default roles for domain users (e.g., domain-scoped tokens).

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

  • [bug 1805400] The domain roles API now supports system scope using the admin, member, and reader default roles.

  • [bug 1805409] The policy and policy associations API now supports the admin, member, and reader default roles.

  • [bug 1818725] [bug 1750615] The application credential API now supports the admin, member, and reader default roles.

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

  • [bug 1818736] The identity:get_limit, identity:list_limits and identity:get_limit_model policies now support domain scope, so domain users are now able to get limit information on their own domains as well as see the limit model in effect.

  • [bug 1818846] The trusts API now supports the admin, member, and reader default roles. System users can now audit and clean up trusts using the default policies.

  • [bug 1823258] Adds support for an “immutable” resource option for roles, which when enabled prevents accidental harmful modification or deletion of roles. Also adds a new flag --immutable-roles to the keystone-manage bootstrap command to make the default roles (admin, member, and reader) immutable by default, as well as a check in the keystone-status upgrade check command to check that these roles have been made immutable. In a future release, these three roles will be immutable by default.

  • [bug 1839577] TOTP now allows by default the code from the previous time window to be considered valid as part of auth. This can be disabled, or the extended up to ten previous windows.

  • [bug 1844461] Listing role assignments for a project subtree is now allowed by system readers and domain readers in addition to project admins.

  • [bug 1844664] The Project Endpoints API now supports the admin, member, and reader default roles.

  • [bug 1807751] Keystone now implements the scaffolding for resource options in projects and roles. Functionally new options (such as “immutable” flags) will appear in returned JSON under the options field (dict) returned in the project, domain, and role structures. The options field will be empty until resource options are implemented for project, domain, and role.

Upgrade Notes

  • The keystone-manage bootstrap command will now update existing endpoints rather than skipping them if they already exist but are different from the values provided to the command. This is useful in conjunction with configuration management tools that use this command for both initialization and lifecycle management of keystone.

  • [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 1750676] [bug 1818844] The token API uses new default policies that make it easier for system users to delegate functionality in a secure way. Please consider the new policies if your deployment overrides the token policies.

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

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

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

  • [bug 1805368] [bug 1750669] The grant APIs use new default policies that make it more accessible to domain users in a safe and secure way. Please consider these new defaults if your deployment overrides the grant APIs.

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

  • [bug 1805400] The domain 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 1805409] The policy and policy associations API uses new default policies to make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides policy and policy associations policies.

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

  • [bug 1806762] [bug 1630434] The entire policy.v3cloudsample.json file has been removed. If you were using this policy file to supply overrides in your deployment, you should consider using the defaults in code and setting keystone.conf [oslo_policy] enforce_scope=True. The new policy defaults are more flexible, they’re tested extensively, and they solve all the problems the policy.v3cloudsample.json file was trying to solve.

  • [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 1806762] The grant policies defined in policy.v3cloudsample.json have been removed. These policies are now obsolete after incorporating system-scope and domain-scope into the grant 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 1818725] [bug 1750615] The application credential API uses new default policies to make it more accessible to end users and administrators in a secure way. Please consider these new defaults if your deployment overrides application credential policies.

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

  • [bug 1818736] The identity:get_limit policy default check string has been changed to support domain scope. This policy are not being formally deprecated because the unified limits API is still considered experimental. These new default automatically account for domain scope in addition to system scope. Please consider these new defaults if your deployment overrides the limit policies.

  • [bug 1818846] [bug 1818850] The trusts 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 trust policies.

  • [bug 1844194] [bug 1844193] The project tags API now 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 the project tags policies.

  • [bug 1844461] The identity:list_role_assignments_for_subtree policy now allows system and domain readers to list role assignments for a project subtree and deprecates the old rule:admin_required policy check string. Please consider the new policies if your deployment overrides role assignment policies.

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

  • [bug 1829453] The os-simple-cert-api will return 410 due to the removal of config options signing [ca_certs] and signing [cert_file].

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 1750676] [bug 1818844] The identity:check_token policy now uses (role:reader and system_scope:all) or rule:token_subject instead of rule:admin_required or rule:token_subject. The identity:validate_token policy now uses (role:reader and system_scope:all) or rule:service_role or rule:token_subject instead or rule:service_or_admin or rule:token_subject. The identity:revoke_token policy now uses (role:admin and system_scope:all) or rule:token_subject instead of rule:admin_or_token_subject. These new defaults automatically account for a read-only role by default and allow more granular access to the API. Please consider these new defaults if your deployment overrides the token policies.

  • [bug 1750678] The EC2 credentials policies have been deprecated. The identity:ec2_get_credentials now use (role:reader and system_scope:all) or user_id:%(target.credential.user_id)s instead of rule:admin_required``and ``identity:ec2_list_credentials policies now use role:reader and system_scope:all or rule:owner instead of rule:admin_required. The identity:ec2_delete_credentials now use (role:admin and system_scope:all) or user_id:%(target.credential.user_id)s instead of rule:admin_required``and ``identity:ec2_create_credentials policies now use role:admin and system_scope:all or rule:owner 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 EC2 credentials policies.

  • [bug 1805363] The oauth1 consumer policies have been deprecated. The identity:get_consumer and identity:list_consumers policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_consumer, identity:update_consumer, and identity:delete_consumer 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 oauth1 consumer policies.

  • [bug 1805366] The Domain Config API policies have been deprecated. The identity:get_domain_config policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:get_domain_config_default policy now use role:reader and system_scope:all instead of rule:admin_required.The identity:create_domain_config policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:update_domain_config policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:delete_domain_config policy now uses 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 domain config policies.

  • [bug 1805368] [bug 1750669] The grant policies have been deprecated and replaced with new policies that expose grant APIs to domain users. This allows deployments to delegate more functionality to domain owners by default. The identity:check_grant and identity:list_grants policies now use (role:reader and system_scope:all) or (role:reader and domain_id:%(target.user.domain_id)s) or (role:reader and domain_id:%(target.group.domain_id)s) instead of role:reader and system_scope:all. The identity:create_grant and identity:revoke_grant policies now use (role:admin and system_scope:all) or (role:admin and domain_id:%(target.user.domain_id)s) or (role:admin and domain_id:%(target.group.domain_id)s) instead of role:admin and system_scope:all. These new defaults automatically include support for domain reader and domain administrator roles, making it easier for system administrator to delegate functionality down to domain users to manage grants within their domains. Please consider these new defaults if your deployment overrides the grant APIs.

  • [bug 1805371] The implied roles policies have been deprecated. The identity:get_implied_role, identity:list_implied_roles, identity:list_role_inference_rules, and identity:check_implied_role policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_implied_role and identity:delete_implied_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 implied roles policies.

  • [bug 1805400] The domain role policies have been deprecated. The identity:get_domain_role and identity:list_domain_roles policies now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_domain_role, identity:update_domain_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 domain role policies.

  • [bug 1805409] The policy and policy associations policies have been deprecated. The identity:get_policy policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:list_policies policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:update_policy policy now use role:admin and system_scope:all instead of rule:admin_required.The identity:create_policy policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:delete_policy policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:check_policy_association_for_endpoint policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:check_policy_association_for_service policy now uses role:reader and system_scope:all instead of role:reader and system_scope:all. The identity:check_policy_association_for_region_and_service policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:get_policy_for_endpoint policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:list_endpoints_for_policy policy now use role:reader and system_scope:all instead of rule:admin_required. The identity:create_policy_association_for_endpoint policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:delete_policy_association_for_endpoint policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:create_policy_association_for_service policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:delete_policy_association_for_service policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:create_policy_association_for_region_and_service policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:delete_policy_association_for_region_and_service policy 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 policy and policy associations policies.

  • [bug 1818725] [bug 1750615] The application credential policies have been deprecated. The identity:get_application_credential policy now uses (role:reader and system_scope:all) or user_id:%(user_id)s instead of rule:admin_required or user_id:%(user_id)s. The identity:list_application_credentials policy now uses (role:reader and system_scope:all) or user_id:%(user_id)s instead of rule:admin_required or user_id:%(user_id)s. The identity:delete_application_credential policy now use (role:admin and system_scope:all) or user_id:%(user_id)s instead of rule:admin_required or user_id:%(user_id)s. 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 application credential policies.

  • [bug 1818734] The endpoint groups policies have been deprecated. The identity:list_endpoint_groups policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:get_endpoint_group policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:update_endpoint_group policy now use role:admin and system_scope:all instead of rule:admin_required.The identity:create_endpoint_group policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:delete_endpoint_group policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:list_projects_associated_with_endpoint_group policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:get_endpoint_group_in_project policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:list_endpoints_associated_with_endpoint_group policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:list_endpoint_groups_for_project policy now uses role:reader and system_scope:all instead of rule:admin_required. The identity:add_endpoint_group_to_project policy now use role:admin and system_scope:all instead of rule:admin_required. The identity:remove_endpoint_group_from_project policy 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 group policies.

  • [bug 1818845] The identity:revocation_list policy has been deprecated for removal. This policy didn’t actually protect the revocation list API since that API is unenforced and unprotected. It only returns an HTTP 410 or HTTP 403 depending on how keystone is configured. This policy can be safely removed.

  • [bug 1818846] [bug 1818850] The trust policies have been deprecated. The identity:list_trusts policy now uses (role:reader and system_scope:all) instead of rule_admin_required. The identity:list_roles_for_trust, identity:get_role_for_trust, and identity:get_trust policies now use (role:reader and system_scope:all) or user_id:%(target.trust.trustor_user_id)s or user_id:%(target.trust.trustee_user_id)s instead of``user_id:%(target.trust.trustor_user_id)s or user_id:%(target.trust.trustee_user_id)s``. The identity:delete_trust policy now uses (role:admin and system_scope:all) or user_id:%(target.trust.trustor_user_id)s instead of user_id:%(target.trust.trustor_user_id)s. 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 trust policies.

  • [bug 1844194] [bug 1844193] The project tags API policies have been deprecated. The identity:get_project_tag and identity:list_project_tags policies now use (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:update_project_tags, identity:delete_project_tags, identity:delete_project_tag, and identity:create_project_tag policies now use (role:admin and system_scope:all) or (role:admin and domain_id:%(target.project.domain_id)s) or (role:admin and project_id:%(target.project.id)s) 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 with compromising security. Please consider these new defaults if your deployment overrides the project tag policies.

  • [bug 1844461] The role assignment identity:list_role_assignments_for_subtree policy now uses (role:reader and system_scope:all) or (role:reader and domain_id:%(target.project.domain_id)s) or (role:admin and project_id:%(target.project.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 1844664] The Project Endpoints policies have been deprecated. The identity:list_projects_for_endpoint now use (role:reader and system_scope:all) identity:check_endpoint_in_project policies now use role:reader and system_scope:all and identity:list_endpoints_for_project now use (role:reader and system_scope:all) instead of rule:admin_required. The identity:add_endpoint_to_project now use (role:admin and system_scope:all) instead of rule:admin_required``and ``identity:remove_endpoint_from_project 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 Project Endpoints policies.

  • [bug 1829454] The [federation] federated_domain_name option is deprecated. All users live in the identity provider’s domain now, and the option is no longer used.

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 1750676] [bug 1818844] The token API now uses system-scope and default roles properly to provide more granular access to the token API.

  • [bug 1750678] The EC2 credentials API now uses system-scope and default roles to provide better accessibility to users in a secure manner.

  • [bug 1805363] The oauth1 consumer API now uses system-scope and default roles to provide better accessibility to users in a secure manner.

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

  • [bug 1805368] [bug 1750669] The grant API now supports domain-scoped default roles to provide better accessbility grants for domain users.

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

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

  • [bug 1805409] The policy and policy associations API now uses system-scope and default roles to provide better accessibility to users in a secure manner.

  • [bug 1818725] [bug 1750615] The application credential API now uses system-scope and default roles to provide better accessibility to users in a secure manner.

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

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

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

  • [bug 1844461] Listing role assignments for a project subtree now uses system-scope, domain-scope, project-scope, and default roles to provide better accessbility to users in a secure way.

  • [bug 1844664] The Project Endpoints API now uses system-scope and default roles to provide better accessibility to users in a secure manner.

Bug Fixes

  • A Federated user gets an entry in the shadow-users table. This entry has a unique ID. It was generated using a UUID. This fix changes to reuse the mechanism for LDAP, where the ID is generated from the domain ID + the local id of the user (an attribute that uniquely ids the user from the IdP). This generator is specified by the configuration file. Now Both LDAP and Federated Ids are generated the same way. It also means that Federated IDs can be kept in sync between two independent Keystone servers.

  • [bug 1724645] Fixes an issue where multiple implementations of a federation protocol, such as Shibboleth and Mellon for the SAML2.0 protocol, could not be differentiated from one another because they had to share the same globally configured remote ID attribute. Now the remote ID attribute can be set on the protocol object itself.

  • [bug 1754048] The correct user domain is now reported when validating a federated token. Previously, the domain would always be validated as “Federated.”

  • [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 1779889] Adds documentation about service tokens and configuring services to use service tokens for long running operations.

  • [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 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 1805880] The 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 1806762] [bug 1630434] The entire policy.v3cloudsample.json file has been removed. If you were using this policy file to supply overrides in your deployment, you should consider using the defaults in code and setting keystone.conf [oslo_policy] enforce_scope=True. The new policy defaults are more flexible, they’re tested extensively, and they solve all the problems the policy.v3cloudsample.json file was trying to solve.

  • [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 1806762] The grant 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 1815771] Allows operators to cache credentials to avoid lookups on the database. This operation can be turned on/off through the configuration parameter of keystone.conf [credential] caching.

  • [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 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 1833739] Fix PostgreSQL specifc issue with storing encrypted credentials. In Python 3 the psycopg2 module treats bytes strings as binary data. This causes issues when storing encrypted credentials in the Database. To fix this isseu the credentials sql backend is updated to encode the credential into a text string before handing it over to the database.

  • [bug 1836568 Addresses a side effect of the large series of policy migrations in which the volume of deprecation warnings that were emitted had become too massive to be helpful. Instead of emitting warnings for individual policy rules, the keystone server now emits a single warning indicating problematic rules were found. Operators can use oslopolicy-policy-generator and oslopolicy-policy-upgrade to find and resolve deprecated policies.

  • [bug 1839133] Makes user_enabled_emulation_use_group_config honor group_members_are_ids.

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

  • [bug 1841486] The keystone-manage mapping_engine --engine-debug CLI tool now outputs useful information about the direct mappings from an assertion after processing mapping rules.

  • [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 1844157] When performing keystone-manage db_sync –check if the legacy repo started at the same version number as the expand/contract/migrate repos the check to see if the db was under version control failed indicating that the db was up-to-date. This was due to the function get_init_version never receiving the path for the repo queried for version information. The fix is to ensure the repo path is always passed to get_init_version from the keystone.common.sql.upgrade.get_db_version function.

  • [bug 1844207] Fixes an issue with WebSSO auth where a server error was raised if a remote ID can’t be found for the requested federation protocol, now correctly raises an Unauthorized client error.

  • [bug 1828565] Fixes endpoint group listing by name. This allows the openstackclient command to search endpoint groups by name.

Other Notes

  • [bug 1829453] The deprecated config option infer_roles is removed now.

  • [bug 1829453] The deprecated config option admin_endpoint is removed now.

  • [bug 1829453] The deprecated config options in signing are removed now.