2026.2 Series Release Notes

13.0.2

Security Issues

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

13.0.0

Upgrade Notes

• The deprecated AuthTokenPlugin has been removed. Due to this removal, the following configuration options, used by this plugin, have been also removed.

  • auth_host

  • auth_port

  • auth_admin_prefix

  • auth_protocol

  • identity_uri

  • admin_token

  • admin_user

  • admin_password

  • admin_tenant_name

• The deprecated [keystone_authtoken] auth_uri option was removed.

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

Security Issues

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