Notifications
Clear all
Topic starter
11/06/2026 10:32 pm
TL;DR: Secretless OCI access replaces stored keys with SPIFFE-based workload identities and runtime token exchange, allowing the OCI CLI to authenticate without secrets on disk or in application code, according to Riptides. The governance shift is clear: access now depends on verifiable workload identity and runtime enforcement, not durable credentials.
NHIMG editorial — based on content published by Riptides: Federation Secretless OCI Authentication with SPIFFE-based workload identity
Questions worth separating out
Q: How should security teams replace OCI credentials with workload identity?
A: Security teams should first register a trusted workload identity issuer, then map that identity to a narrowly scoped OCI principal, and finally bind access to the specific workload and destination.
Q: Why do secretless workloads change the NHI governance model?
A: Secretless workloads change the model because the security object is no longer a stored credential.
Q: What breaks when applications still expect local credentials?
A: What breaks is the assumption that the client must own a reusable secret to authenticate.
Practitioner guidance
- Inventory workload identities before replacing secrets Map every OCI-facing workload to a named identity, an approved destination, and a responsible owner before introducing secretless access.
- Separate federation trust from application access Establish the trust relationship between OCI and the identity issuer as a distinct control, then review it like any other privileged federation path.
- Scope credentials to process and endpoint together Bind each workload credential to a specific process identity and a narrow egress target set, then test that the credential cannot be reused from another process or destination.
What's in the full article
Riptides' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step OCI identity-domain configuration for workload federation and service-user impersonation.
- Kernel-level request interception and re-signing behaviour for OCI CLI traffic.
- Fallback sysfs-based credential handling when on-the-wire injection is not feasible.
- Concrete custom resource examples for WorkloadIdentity, WorkloadCredential, and CredentialSource setup.
👉 Read Riptides' secretless OCI authentication walkthrough with SPIFFE workload identity →
Secretless OCI authentication: what it means for workload identity?
Explore further
12/06/2026 6:28 am
Secretless access does not eliminate NHI governance, it relocates it. The control question shifts from where the secret lives to how the workload proves identity and receives a time-bound authorization decision. That matters because the application is no longer the bearer of a durable credential, but it still represents a non-human identity with access rights. Practitioners need to govern workload identity, federation trust, and runtime scope as one access path, not three separate tools.
A few things that frame the scale:
- 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
- 61% rely on spreadsheets or manual tracking for machine identity management, which means many runtime identity decisions still sit on weak operational foundations.
A question worth separating out:
Q: How do you know secretless access is actually reducing risk?
A: You know it is working when the application never stores usable credentials, authentication is issued just in time for the request, and access is limited to the approved workload and endpoint. You should also verify that refresh happens transparently and that the same workload cannot reuse the credential from another process. Those are the signs that risk has moved out of the app boundary.
👉 Read our full editorial: Secretless OCI authentication exposes the limits of credential-based access
