Tokens minted from an EC2 or S3 credential exchange (POST /v3/ec2tokens
or POST /v3/s3tokens) have always recorded the ec2credential auth
method, which was never a registered auth method. The fernet token
provider encodes methods as a bitmask of [auth] methods, so the marker
was silently dropped on the token payload round-trip: on any validation
that re-read the payload (cache miss, different process) the token
looked like it had been issued with no auth methods at all, and the
guard that rejects such tokens from authorizing requests in Keystone
could not recognize them. A stolen EC2 or S3 access/secret key pair
could therefore be exchanged for a token and used to authorize
requests in Keystone.
Register ec2credential as a deliberately non-functional auth method so
the marker has a bit in the fernet methods bitmask and survives the
round-trip, and is recognized as delegated-credential derived by all of
the guards that reject such tokens (Keystone authorization, token
re-scoping, trust, application credential, and OAuth1 management). The
plugin can never authenticate: EC2 and S3 credentials must still be
exchanged at their respective endpoints, and attempts to authenticate
via /v3/auth/tokens are rejected with 401.
The method is appended to the end of the default [auth] methods list
on purpose: the fernet method bitmask is positional, so appending
preserves the bits of all existing methods and existing tokens
continue to validate.
While the method is removed from [auth] methods, POST /v3/ec2tokens
and POST /v3/s3tokens refuse to issue tokens (HTTP 503): a token
minted without the marker would not be recognized as
delegated-credential derived on a token payload round-trip, so the
endpoints fail closed rather than re-opening the vulnerability.
Operators pinning an explicit methods list must add the method after
upgrading.
Also ensure ec2credential can never be reclassified as a primary auth
method via [auth] additional_primary_auth_methods, which would
otherwise silently re-open the rescope path the guards block.
The notes in OSSA-2026-037 defer the EC2/S3 credential handling
weakness to a separate advisory; this change is that fix.
Related-bug: #2153453
Assisted-by: Qwen-3.8
Change-Id: I520f24617c8ec16e2d007e13e3fff99944e71260
Signed-off-by: Artem Goncharov <artem.goncharov@gmail.com>
Artem Goncharov
0e2166742f