2025.2 Series Release Notes¶

10.13.0¶

The service_token_roles_required option now defaults to True. This means that service tokens must contain a role from the service_token_roles list (default: ['service']) to be considered valid. Operators should verify that:
- Service users have one of the roles listed in service_token_roles (by default, the service role).
- If your deployment intentionally relied on the previous permissive behavior (accepting any valid token as a service token), you can restore it by explicitly setting service_token_roles_required=False in the [keystone_authtoken] section, though this is strongly discouraged for security reasons.
If service tokens are rejected after upgrading, ensure the service users have the appropriate role assigned in Keystone.

[bug 2162748] auth_token middleware no longer treats the mere presence of an X-Service-Token header as sufficient to skip application credential access_rules checks or token binding (enforce_token_bind, including Kerberos). Both paths now require the service token to also be valid (service_token_valid). Previously an arbitrary X-Service-Token value could bypass access_rules and, when delay_auth_decision was enabled, skip Kerberos (or other) binding so a stolen bound user token would be marked Confirmed without a Negotiate session.

The service_token_roles_required option in [keystone_authtoken] now defaults to True instead of False. This fixes a security issue where any valid token could be used as a service token when the default was False. With the previous default, a user token placed in X-Service-Token would be accepted as a valid service token, which could bypass application credential access-rules checks and weaken composite-auth protections intended to distinguish service-to-service requests from end-user requests.

Support for Python 3.9 has been removed. Now Python 3.10 is the minimum version supported.