Summary

  • id-token: write allows a GitHub Actions job or workflow to request an OIDC JSON Web Token; GitHub says that setting does not itself grant write access to external resources.
  • A cloud provider separately evaluates configured trust conditions and may exchange the JWT for a short-lived access token. The later cloud-resource decision is another control surface again.
  • A defensible cloud-authorization statement joins workflow revision and bounded claims, cloud trust-policy revision, exchange/session evidence, effective permission context, resource decision and a time-bounded target observation.

“The pipeline has cloud access through OIDC” can be a useful implementation summary. It becomes misleading when it collapses several separately governed decisions into one verdict. GitHub Actions can issue an OpenID Connect token to a job that has been allowed to request one. A cloud provider can be configured to trust GitHub's issuer and to check a selected set of claims. A successful exchange can yield a short-lived cloud credential for that job. A cloud service can then evaluate that credential against a role, resource policy, boundary, session policy, organization control, request context and the resource action itself.

Each link has a different actor, time and evidence surface.

GitHub draws the first line clearly. The id-token: write setting allows a workflow to request and use an OIDC JWT; it does not grant the workflow permission to modify other resources. That distinction matters because permission syntax is often copied into a release review as though it described the final privilege. It does not. A reviewer who sees the setting has learned something bounded: the job was eligible to request a GitHub identity token. They have not learned whether the request happened, which audience was requested, what claims were returned, whether a cloud provider trusted them, or whether a cloud resource later accepted an action.

The cloud trust relationship is a separate configuration and a separate decision. GitHub's cloud-provider guidance says that the provider validates token claims and, if successful, supplies an access token available to that job run. The provider's policy is where a subject, audience, repository identity, reusable-workflow reference or other available claim becomes an admission condition. A token may be well-formed while a trust condition rejects it. A condition may be broad while an expected claim is absent or changed. A cloud token may be issued but scoped more narrowly than a release author assumes.

Conversely, an action could be denied by a later resource policy even though the federation exchange succeeded.

AWS makes the separation concrete. GitHub's AWS guidance describes configuring an AWS trust relationship and recommends evaluating the OIDC sub condition key in a role trust policy. The existence of a GitHub sub claim is therefore not the same record as an AWS role session. Nor is a role session a record of every permission it carried in context. A role policy, permission boundary, session policy, organization-level restriction, resource policy and explicit deny can shape a particular decision. This article does not audit an AWS account; it identifies why a generic claim such as “OIDC authorized the deployment” leaves too much unspecified.

Reusable workflows add another reason to preserve the actual join. GitHub documents that a token for a job running in a reusable workflow includes ordinary job information and can include job_workflow_ref; support for custom claims varies by cloud provider. A workflow name in a repository is not proof that a relying provider checked that field. A caller may be known to GitHub but not included in the trust condition a provider can evaluate. A later customization of subject claims can also change the format that a provider expects. These are configuration facts to capture, not gaps to fill with the reassuring word “federated.”

The result is a seven-part cloud-authorization receipt. Preserve the exact workflow revision, triggering ref, job identity and id-token: write context. Preserve a bounded record of the requested audience and resulting claims, without exposing a live token. Preserve the cloud identity-provider and trust-policy revision that were in force. Preserve the exchange result and role or session identity, including expiry. Preserve the effective-permission context relevant to the intended action. Preserve the cloud resource's decision and request record. Finally, preserve a separately timed target observation. Sensitive account names, resource identifiers and values can remain protected. The point is to preserve the joins, not to publish credentials.

Sources

  1. GitHub Docs — Configuring OpenID Connect in cloud providers
  2. GitHub Docs — OpenID Connect reference
  3. GitHub Docs — Configuring OpenID Connect in Amazon Web Services
  4. GitHub Docs — Using OpenID Connect with reusable workflows