Build1 publisher2 min readPublished Updated
OCI's Workload Identity Federation exchanges a GitHub OIDC token for a short-lived session
In a dev.to write-up, Jorge RN traces the chain from a workload's own identity to an ephemeral OCI session token, where the authorization decision reads claims such as repository, workflow and branch.
The Engineer · Build desk
What happened
- A dev.to write-up describes OCI Workload Identity Federation as letting an external workload present an identity issued by a trusted platform and exchange it for temporary access to OCI resources.
- The setup it replaces keeps five values in CI configuration: OCI_USER_OCID, OCI_TENANCY_OCID, OCI_FINGERPRINT, OCI_PRIVATE_KEY and OCI_REGION.
- The temporary credential is what the write-up says Oracle calls an ephemeral Resource Principal Session Token, issued to the workload for the length of a session.
- The post says Oracle summarises the model around three outcomes: No Standing Users, No Standing Credentials and Claim-Based Authorization.
- The identity sources named are a GitHub Actions OIDC token, a Kubernetes service account token, and a platform-issued cloud identity.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Adopting this retires a queue of identity chores for technical users, including creation, periodic review, disabling, cleanup and offboarding, and replaces them with a policy someone has to write and defend.
- exposure For workloads that migrate, there is no long-lived OCI API key left to find in GitHub Secrets, a container image, a notebook or an agent configuration file.
- capability Pinning claims lets a single policy admit one workflow on one branch in one repository, a distinction an API key cannot encode.
- constraint Authentication now depends on an external issuer at run time, and a job that cannot get a token has no stored key to fall back on.
Count the links. The chain the post replaces has four: workload, OCI user, API key, OCI resource [5]. The chain it proposes has six: workload, a verifiable external identity, OCI Workload Identity Federation, a temporary OCI credential, an OCI IAM policy, the resource [6]. Two more elements sit between the caller and the thing it wants [7], and both of the new ones are in the request path.
The post, by Jorge RN on dev.to, says the workload keeps its original identity, and that OCI validates that identity and determines which actions it can perform [17][20]. OCI therefore does not have to hold a permanent identity for each external workload [16].
The custody work the post attributes to the old approach starts with protecting the private key, then controlling who can read the secret, rotating it, deleting it when it is no longer used, keeping it out of images, repositories and logs, and auditing which workload actually used that identity [4].
Claim-based authorization is the part that changes review. A GitHub identity carries organization, repository, workflow, branch, environment and issuer [12]. A Kubernetes service account token carries cluster, namespace, service account, issuer and subject [13]. Those attributes can become context that OCI IAM uses for authorization decisions [14]. The post's example aims at one caller, the repository company/payment-api, the workflow deploy-production.yml, on branch main [15]. Write the policy that way and the session goes to whoever can cause a run on main [19].
The post's text ends where the GitHub Actions flow begins, so it does not include the policy syntax, a session lifetime, or the list of issuers OCI will trust beyond the three families it names [18]. For the pattern to transfer to a given pipeline, the issuer's token has to carry the fields you intend to pin, OCI's policy language has to match them tightly enough to separate two workflows in one repository, and the session has to outlast the longest step in the job.
In my view this is the right default for a job that runs for minutes and then exits, and the context is that such a job already runs on a platform whose issuer someone else operates. A GitHub OIDC token is only as good as GitHub's issuer and the rules on the branch named in the claim [9][12]. Swapping a key you hold for a token an external issuer mints is a real trade, and the model in the post puts that issuer inside your authorization path [6][9].
What to watch
- Oracle publishing policy examples with the exact claim-matching syntax, including whether wildcards are allowed on repository or workflow.
- A stated RPST lifetime, and refresh guidance for Kubernetes jobs that run longer than one session.
- Whether AI agent runtimes, which the post lists alongside CI/CD and Kubernetes, get a named identity source of their own.