2025.1 Series Release Notes

27.1.0

Notes de mises à jours

  • New config option [auth] ban_ec2credential_tokens, default True. Deployments with an existing, undocumented dependency on using EC2-derived tokens directly against the keystone API (beyond token validation) can set this to False to restore the previous behavior.

  • bug 2153453: A token issued via a custom, third-party auth plugin (for example a site-specific SSO integration) is now treated as a delegated credential by default and rejected from managing trusts, application credentials, and OAuth1 access tokens, unless its method name is listed in the new [auth] additional_primary_auth_methods option. Deployments that run a custom auth plugin beyond keystone’s own built-in methods (password, totp, mapped, saml2, openid, external, kerberos, x509, token) must add its method name to this option to avoid regressing self-service workflows for users authenticated through it, such as switching active project.

  • LP#2154645: If you have overridden identity:list_role_assignments or identity:list_role_assignments_for_tree in policy.yaml, add not None:%(target.domain_id)s to any branch that contains domain_id:%(target.domain_id)s, for example:

    identity:list_role_assignments_for_tree: >-
  (rule:admin_required) or
  (role:reader and system_scope:all) or
  (role:reader and domain_id:%(target.domain_id)s and
   not None:%(target.domain_id)s)

    Deployments using the default policies are protected automatically.

  • LP#2158538: Authenticating with the token method using an application credential or EC2 credential token is now rejected with HTTP 403 (Forbidden). Previously, application credential tokens without an explicit scope would fall through to the user’s default project, and EC2 credential tokens could be re-scoped to any project. Callers that relied on exchanging an application credential token via the token method must authenticate with the application credential directly instead.

Problèmes de sécurités

  • Tokens issued via EC2 credential authentication (ec2credential) are now rejected by the auth middleware for every keystone API operation except validating the token, which Swift’s S3 protocol support relies on. This closes off EC2-derived tokens from being used as a general-purpose bearer credential against the rest of the keystone API. Backported from a change already on master.

  • [bug 2153453] EC2-derived tokens (methods: ['ec2credential']) could still create, list, read, or delete trusts (/v3/OS-TRUST/trusts), create, list, read, or delete application credentials (/v3/users/{user_id}/application_credentials), and authorize OAuth1 request tokens (PUT /v3/OS-OAUTH1/authorize/{request_token_id}), because none of the delegation guards on those endpoints recognized ec2credential as a delegated method. OAuth1 access-token-scoped tokens had the same gap for trust management. A stolen EC2 access/secret key pair or OAuth1 access token could therefore bootstrap a trust, application credential, or OAuth1 access token delegation that outlives revocation of the original credential.

    These endpoints now use the same primary-auth-method allowlist already used by /v3/credentials and the OS-EC2 compat endpoints: any token whose methods aren’t entirely primary (interactive) auth methods, or that carries a trust_id, is rejected. Application credential tokens keep their existing, documented behavior on each endpoint (the opt-in trust-escalation escape hatch, and the unrestricted/restricted distinction for creating further application credentials); OAuth1 and EC2 credentials have no such use case and are blocked unconditionally.

  • LP#2154645: Any user holding role:reader on any project could list all role assignments under any domain by passing a domain ID as scope.project.id to GET /v3/role_assignments?include_subtree. Domain projects store domain_id=null, which matched the null domain_id of any project-scoped token in the oslo.policy string comparison, bypassing the domain-reader restriction. An explicit not None:%(target.domain_id)s guard has been added to the affected policy rules.

  • LP#2158538: Tokens issued via delegated credentials (application credentials and EC2 credentials) could be exchanged for a broader-scoped token using the token authentication method.

    An application credential token could omit the scope parameter during token-method reauthentication, causing the new token to fall through to the user’s default project, escaping the application credential’s project binding. EC2 credential tokens had no such guard and could be re-scoped to any project the underlying user has a role on, not just the project the EC2 credential was bound to.

27.0.2

Notes de mises à jours

  • [bug 2148398] The identity:create_trust policy rule now uses %(target.trust.trustor_user_id)s instead of %(trust.trustor_user_id)s. The trust data from the request body is now passed explicitly via target_attr rather than relying on the JSON body merge. This aligns create_trust with all other trust policy rules which already use the target.trust.* prefix. Deployments that override the identity:create_trust policy and reference %(trust.trustor_user_id)s must update to %(target.trust.trustor_user_id)s.

  • [bug 2150089] Two new [security_compliance] options control opt-in insecure behaviour for operators with workflows that break after this upgrade:

    allow_insecure_admin_trust_cross_project_credentials_access (default False): set to True if admin-role trusts or application credentials need to access credentials across multiple projects (e.g. Mistral cron triggers syncing EC2 credentials system-wide).

    allow_insecure_application_credential_trust_escalation (default False): set to True if application credentials must create or manage trusts (e.g. Heat stacks authenticated via application credentials). Use OIDC federation flows (v3oidcclientcredentials, v3oidcdeviceauthz) as the proper long-term alternative.

    Both options are intentionally named to signal that enabling them is insecure. Migrate affected workflows away from these options.

Erreurs critiques

  • [bug 2148398] The RBAC enforcer unconditionally merged the raw JSON request body into the policy enforcement dictionary after trusted target data had been set from the database. An attacker could include a target key in the JSON body to overwrite database-sourced RBAC target attributes, causing all %(target.*)s policy substitutions to evaluate against attacker-controlled values. This affected 88 endpoint/method combinations across all Keystone API resource areas. Any authenticated user could exploit this to read every credential secret in the deployment, create EC2 credentials for arbitrary users, or revoke other users” tokens. A domain administrator could escalate to full cloud admin by creating inherited role grants on other domains. The vulnerability has been present since the Rocky release (14.0.0).

Problèmes de sécurités

  • [bug 2148398] The RBAC policy enforcer now namespaces JSON request body data under a request_body key in the policy dictionary instead of merging it at the top level. This prevents user-controlled input from overwriting security-critical keys such as target (populated from the database by build_target or target_attr) and URL path parameters like user_id. All upstream policy rules are unaffected by this change. Deployments with custom policy rules that reference JSON body fields directly via %(field_name)s substitutions (not under target.) will need to update those references to %(request_body.field_name)s.

  • [bug 2150089] Delegated tokens (trusts, application credentials, OAuth1 access tokens) are now restricted to credentials whose project_id matches the token’s project scope. This closes a cross-project lateral movement vector where a delegated token could read, modify, or delete credentials belonging to a different project, including EC2 keys and TOTP/MFA seed bindings.

    Application credential tokens are now blocked from all trust operations (create, delete, list, get). Allowing an application credential to bootstrap a trust creates a new delegation context whose token can access authentication material outside the delegation chain, breaking the audit trail. The unrestricted flag governs credential management, not trust management.

27.0.1

Problèmes de sécurités

  • A potential security related issue is fixed where a token of the user from a read-only backend (i.e. LDAP) continues being accepted after the user is disabled in the backend. This is caused by the fact that Keystone does not receive any notification for that and is not able to revoke such tokens. See https://bugs.launchpad.net/keystone/+bug/2122615 for details.

Corrections de bugs

  • Ldap identity backend did not interpret the enabled field as boolean.

27.0.0

Nouvelles fonctionnalités

  • A new module, keystone.wsgi, has been added as a place to gather WSGI application objects. This is intended to ease deployment by providing a consistent location for these objects. For example, if using uWSGI then instead of:

    [uwsgi]
wsgi-file = /bin/keystone-wsgi-public

    You can now use:

    [uwsgi]
module = keystone.wsgi.api:application

    This also simplifies deployment with other WSGI servers that expect module paths such as gunicorn.

  • User and group listing supports pagination. Query parameters limit and marker are added and work as described in API-SIG doc

  • New configuration variable max_db_limit is added to set an absolute limit amount of entries fetched from the database at a single time. It is used in resource pagination. Existing option list_limit is optional and describes preferred count of entries while max_db_limit sets top limit applied to user input and individual list_limit options.

  • Project and domain listing supports pagination. Query parameters limit and marker are added and work as described in API-SIG doc

Notes de mises à jours

  • Dependency on abandoned library passlib has been dropped in favor of using bcrypt and cryptography directly. It was ensured that passwords hashed with passlib are still supported, but absence of cornercases can not be guaranteed. If users are not able to login using old password such password must be rotated.

  • Python 3.8 support was dropped. The minimum version of Python now supported is Python 3.9.

  • The templated catalog driver has been removed. The [catalog] template_file option, which was used by the templated catalog driver has also been removed.

Notes dépréciées

  • The [DEFAULT] max_param_size option has been deprecated. This option was used in identity v2 APU but identity v2 API was removed in 13.0.0 release.

  • This is the last release where passwords hashed using sha512_crypt algorithm are supported. Since even support of that is being dropped in python 3.13 it would be physically dropped from Keystone in the next release (Epoxy).

Autres notes

  • The sha512_crypt password hashing module has been removed, completing the deprecation process and dropping use of the crypt module which has been dropped in Python >= 3.13.