Control objective
Credential injection lets a trusted intermediary obtain or add the credential that an upstream service needs after it authorizes the incoming request. It keeps upstream credentials away from the client and can bind them to a narrower audience or identity.
Credential flow
Authenticate the requester, authorize the named route and action, select a credential from trusted configuration or exchange, bind it to the intended upstream and lifetime, remove untrusted client copies of the field, and send it only over an authenticated upstream connection.
Evidence and rotation
Record safe credential identity, subject, audience, route, policy, issue and expiry, and upstream result. Rotate or revoke stored credentials. Verify that the upstream rejects a client-supplied replacement and old values.
Failure and residual risk
A shared credential can collapse all users into one upstream principal. A broad token can work at another target. Header injection, direct upstream access, logs, retries, and credential cache can expose or replay authority. Gateway allow does not grant every upstream object action.
Pomerium boundary
Pomerium supports documented upstream identity and credential patterns. Operators own target credential scope, custody, rotation, upstream validation, direct-path isolation, and application authorization. Do not treat injected identity as trustworthy on a path that can bypass Pomerium.
Evaluation checklist
- Is the injected credential required, narrow, audience-bound, and short-lived?
- Can the client override or observe it?
- Does the upstream authenticate the Pomerium connection and reject direct requests?
- Are user identity and application action preserved separately?
- Can old, wrong-audience, and replayed credentials be rejected and traced?
