Ussuri Series Release Notes

17.0.1-11

Nouvelles fonctionnalités

  • A new option “randomize_urls” can be used to randomize the order in which keystone connects to the LDAP servers in [ldap] “url” list. It is false by default.

Notes de mises à jours

  • [bug 1929066] Increase the length of the local_id column in the id_mapping table to accommodate LDAP group names that result in names greater than 64 characters.

Problèmes de sécurités

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

17.0.1

Problèmes de sécurités

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

Corrections de bugs

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

17.0.0

Nouvelles fonctionnalités

  • [bug 1641625] The keystone configured as an identity provider now includes an additional attribute called openstack_groups in the assertion when generating SAML assertions.

  • [bug 1809116] It is now possible to have group memberships carried over through mapping persist for a limited time after a user authenticates using federation. The « time to live » of these memberships is specified via the configuration option [federation] default_authorization_ttl or for each identity provider by setting authorization_ttl on the identity provider. Every time a user authenticates carrying over that membership, it will be renewed.

  • GET /v3/users/{user_id} now returns a federated object associated with the user if any. POST /v3/users allows an operator to add a list of federated objects to associate with the user. PATCH /v3/users allows the operator to update a users associated federated objects.

  • Restores the configurability of the resource driver, so it is now possible to create a custom resource driver if the built-in sql driver does not meet business requirements.

Notes de mises à jours

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

  • If you have a custom implementation for the shadow users backend, you will need to implement the new methods: delete_federated_object, create_federated_object, get_federated_objects. These methods are needed to support federated attributes via the user API.

  • [bug 1823258] The keystone-manage bootstrap command now defaults to making the default roles (admin, member, and reader) immutable. This has the consequence that if the bootstrap command is re-run on an existing deployment, those roles will become immutable if they were not before. To opt out of this behavior, add the --no-immutable-roles flag to the bootstrap command.

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

  • The foreign key constraint between the user.domain_id column and the project.id column and between the identity_provider.domain_id column and the project.id column will be dropped upon running the keystone db_sync contraction step. These constraints are enforced in code and do not need to be enforced by the database. This should have no impact on users.

Erreurs critiques

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

Problèmes de sécurités

  • If expiring user group memberships are enabled via the [federation] default_authorization_ttl configuration option, or on an idp by idp basis by setting authorization_ttl, there will be a lag between when a user is removed from a group in an identity provider, and when that will be reflected in keystone. That amount of time will be equal to the last time the user logged in + idp ttl.

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

Corrections de bugs

  • [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 1848238] Allow deleting a domain when using the ldap driver for a domain. There was an attempt to delete the group on the ldap whereas this one is read-only.

  • [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);

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

  • Replaced the usage of SQLAlchemy Inspector.from_engine() with the sqlalchemy.inspect() call, within several Alembic migration files as well as a test suite. SQLAlchemy will be deprecating the former syntax, so this change allows forwads compatibility with the next series of SQLAlchemy.