TL;DR: On-the-wire credential injection can let workloads call Amazon Bedrock with short-lived AWS credentials that are injected at request time, removing stored secrets from the client path according to Riptides. The governance issue is not authentication convenience, but whether NHI controls still assume credentials must exist on the workload to be usable.
NHIMG editorial — based on content published by Riptides: Federation On-the-Wire Credential Injection, Secretless AWS Bedrock Access example
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- Only 38% have automated certificate lifecycle management in place.
- 57% of organisations lack a complete inventory of their machine identities.
Questions worth separating out
Q: How should security teams govern workloads that use secretless cloud access?
A: Security teams should govern secretless access by treating workload identity, trust relationships, and request signing as one control chain.
Q: Why do short-lived NHI credentials still need strong trust controls?
A: Short-lived credentials reduce exposure time, but they do not remove authorization risk.
Q: What breaks when workloads depend on stored secrets for API access?
A: Stored secrets create a single point of exposure, revocation delay, and lateral movement risk.
Practitioner guidance
- Map every workload credential dependency Inventory where client applications still depend on local AWS keys, token files, or secret stores, then classify each dependency by runtime exposure and revocation difficulty.
- Constrain trust at the workload identity layer Require explicit workload selectors, audience claims, and role trust policies for every injected credential path.
- Separate request signing from secret storage Ensure SigV4 or equivalent service signing happens inside the identity mediation path rather than inside application code.
What's in the full article
Riptides' full analysis covers the operational detail this post intentionally leaves for the source:
- The exact Kubernetes custom resources used to bind workloads to injected AWS credentials.
- The full STS trust policy and OIDC provider setup for secretless Bedrock access.
- The libsigv4 request-signing flow that re-authorises traffic at the kernel layer.
- The step-by-step client configuration used to run the Streamlit example without real AWS keys.
👉 Read Riptides' analysis of secretless AWS Bedrock credential injection →
AWS Bedrock credential injection: what it means for NHI teams?
Explore further