POST /v3/credentials accepted a client-supplied trust_id (and
app_cred_id / access_token_id) in an EC2 blob and persisted it.
Anyone who learned an impersonation trust_id could forge it into
their own credential and exchange it via /ec2tokens or /s3tokens
for a project-scoped token as the trustor — including through
Swift's s3token middleware using only the service account.
Strip those fields on create and stamp them only from the caller's
auth context. Independently, require the EC2 credential's user_id
to be a party to the referenced trust (or to own the referenced
application credential / OAuth1 access token) at auth time, so
pre-existing forged blobs cannot mint tokens either.
Closes-Bug: #2165281
Change-Id: I5d8530c8ebdb955026cb2d9b6c0033c769a979b4
Signed-off-by: Grzegorz Grasza <xek@redhat.com>
Assisted-by: Cursor Composer <noreply@cursor.com>