{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/github-actions-oidc-cloud-federation/", "item": { "id": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/", "slug": "github-actions-oidc-cloud-federation", "url": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation.md", "json": "https://update.dsesecurity.com/api/v1/posts/github-actions-oidc-cloud-federation/" }, "title": "Replace GitHub Actions cloud secrets with OpenID Connect federation", "summary": "GitHub Actions can exchange a GitHub-issued OIDC token for a short-lived cloud credential instead of storing a long-lived key. The security gain depends on strict trust claims, least-privilege cloud roles, protected environments, and tested revocation.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-11T10:01:00+00:00", "modified_at": "2026-08-11T14:48:24+00:00", "reviewed_on": "2026-08-11", "reading_minutes": 3, "word_count": 651, "potentially_affected": "GitHub Actions workflows; GitHub organizations, repositories, environments, reusable workflows, and runners; AWS, Azure, Google Cloud, Vault, and other OIDC-capable services; cloud IAM and deployment pipelines.", "dse_recommendation": "Inventory workflow-held cloud secrets, define an exact repository, ref, or environment trust boundary, create a least-privilege cloud role, pilot the official login action, then remove and revoke the legacy credential with evidence.", "primary_source": { "name": "GitHub Docs: Configuring OpenID Connect in cloud providers", "url": "https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers", "published_on": null, "authority": "docs.github.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts: federation replaces storage, not authorization design

\n

GitHub’s OIDC guidance says Actions workflows can access a cloud provider without storing long-lived cloud credentials as GitHub secrets. The cloud is configured to trust GitHub’s OIDC provider; a workflow requests a signed JSON Web Token, presents it to the provider, and receives a short-lived access token for that job.

\n

The job or workflow needs id-token: write to request the OIDC token. GitHub explicitly notes that this setting alone does not grant permission to modify GitHub or cloud resources. The cloud trust relationship and the permissions attached to the resulting cloud identity determine what the job can do.

\n

GitHub requires at least one trust condition so an untrusted repository cannot request access to the organization’s cloud resources. Claims such as issuer, audience, subject, repository, ref, and environment can define that boundary. GitHub recommends environment protection rules when environments participate in the OIDC policy and recommends the cloud provider’s official action for the token exchange when available.

\n

The current OIDC reference adds an operational detail for GitHub.com: repositories created after July 15, 2026 use an immutable default subject containing owner and repository IDs. Older repositories retain the prior name-based format unless they opt in, while later renames and transfers move to the immutable form. That rollout does not apply to GitHub Enterprise Server. Trust-policy migration must match the actual subject format.

\n\n

DSE recommendation: write the trust statement before the workflow

\n

For each deployment, state in plain language: “this repository, from this branch, tag, reusable workflow, or protected environment, may assume this cloud role for this purpose.” Translate that statement into exact GitHub claims and cloud conditions. Reject wildcard organization trust and broad repository patterns unless a documented design truly requires them.

\n
    \n
  1. Inventory reusable credentials. Find cloud keys in repository, organization, and environment secrets; workflow files; runner configuration; external secret stores; deployment scripts; and copied runbooks. Map each to the workflows and cloud actions that use it.
    2. \n
  2. Inspect the real token shape. Determine issuer, audience, subject format, repository and owner IDs, ref, environment, and reusable-workflow context for a controlled run. Account for repository age, rename, transfer, and the GitHub.com versus Enterprise Server boundary.
    3. \n
  3. Create a narrow cloud role. Limit trust to the approved claims and permissions to the required resource and action. Separate production from test, deployment from administration, and read from write. Keep token lifetime no longer than operationally necessary.
    4. \n
  4. Protect the path to the token. Restrict workflow and environment changes through branch protection, CODEOWNERS or equivalent review, environment reviewers, and limited repository administration. Pin third-party actions to reviewed immutable commits where the risk warrants it.
    5. \n
  5. Test positive and negative cases. Prove the approved branch or environment can deploy. Prove a pull request, fork, wrong branch, unprotected environment, different repository, and unauthorized resource cannot. Confirm cloud audit logs identify the federated principal and GitHub run.
    6. \n
  6. Revoke the old secret. Remove it from GitHub and runners, revoke it at the provider, search for copies, observe scheduled and rarely used workflows, and preserve rollback through a controlled break-glass process rather than restoring the shared key.
    7. \n
\n

Monitor failed token exchanges, unexpected subjects, role assumptions outside deployment windows, denied cloud actions, changes to trust policies, and workflows newly granted id-token: write. Review the design after repository transfer, rename, environment change, workflow reuse change, or cloud-role expansion. Federation reduces secret exposure and rotation burden, but a broad trust rule can turn any compromised workflow inside its scope into a credential mint. The security value comes from making that scope both narrow and observable.

\n

Keep an emergency revocation procedure that disables the cloud trust relationship without requiring a repository change. Test that action and the recovery approval path so a compromised workflow can be contained even when GitHub administration is unavailable.

\n\n

Official references

\n", "content_text": "Source facts: federation replaces storage, not authorization design\nGitHub’s OIDC guidance says Actions workflows can access a cloud provider without storing long-lived cloud credentials as GitHub secrets. The cloud is configured to trust GitHub’s OIDC provider; a workflow requests a signed JSON Web Token, presents it to the provider, and receives a short-lived access token for that job.\nThe job or workflow needs id-token: write to request the OIDC token. GitHub explicitly notes that this setting alone does not grant permission to modify GitHub or cloud resources. The cloud trust relationship and the permissions attached to the resulting cloud identity determine what the job can do.\nGitHub requires at least one trust condition so an untrusted repository cannot request access to the organization’s cloud resources. Claims such as issuer, audience, subject, repository, ref, and environment can define that boundary. GitHub recommends environment protection rules when environments participate in the OIDC policy and recommends the cloud provider’s official action for the token exchange when available.\nThe current OIDC reference adds an operational detail for GitHub.com: repositories created after July 15, 2026 use an immutable default subject containing owner and repository IDs. Older repositories retain the prior name-based format unless they opt in, while later renames and transfers move to the immutable form. That rollout does not apply to GitHub Enterprise Server. Trust-policy migration must match the actual subject format.\n\nDSE recommendation: write the trust statement before the workflow\nFor each deployment, state in plain language: “this repository, from this branch, tag, reusable workflow, or protected environment, may assume this cloud role for this purpose.” Translate that statement into exact GitHub claims and cloud conditions. Reject wildcard organization trust and broad repository patterns unless a documented design truly requires them.\n\nInventory reusable credentials. Find cloud keys in repository, organization, and environment secrets; workflow files; runner configuration; external secret stores; deployment scripts; and copied runbooks. Map each to the workflows and cloud actions that use it.\nInspect the real token shape. Determine issuer, audience, subject format, repository and owner IDs, ref, environment, and reusable-workflow context for a controlled run. Account for repository age, rename, transfer, and the GitHub.com versus Enterprise Server boundary.\nCreate a narrow cloud role. Limit trust to the approved claims and permissions to the required resource and action. Separate production from test, deployment from administration, and read from write. Keep token lifetime no longer than operationally necessary.\nProtect the path to the token. Restrict workflow and environment changes through branch protection, CODEOWNERS or equivalent review, environment reviewers, and limited repository administration. Pin third-party actions to reviewed immutable commits where the risk warrants it.\nTest positive and negative cases. Prove the approved branch or environment can deploy. Prove a pull request, fork, wrong branch, unprotected environment, different repository, and unauthorized resource cannot. Confirm cloud audit logs identify the federated principal and GitHub run.\nRevoke the old secret. Remove it from GitHub and runners, revoke it at the provider, search for copies, observe scheduled and rarely used workflows, and preserve rollback through a controlled break-glass process rather than restoring the shared key.\n\nMonitor failed token exchanges, unexpected subjects, role assumptions outside deployment windows, denied cloud actions, changes to trust policies, and workflows newly granted id-token: write. Review the design after repository transfer, rename, environment change, workflow reuse change, or cloud-role expansion. Federation reduces secret exposure and rotation burden, but a broad trust rule can turn any compromised workflow inside its scope into a credential mint. The security value comes from making that scope both narrow and observable.\nKeep an emergency revocation procedure that disables the cloud trust relationship without requiring a repository change. Test that action and the recovery approval path so a compromised workflow can be contained even when GitHub administration is unavailable.\n\nOfficial references\n\nGitHub Docs, Configuring OpenID Connect in cloud providers, living documentation reviewed August 11, 2026.\nGitHub Docs, OpenID Connect reference, including immutable subject-claim behavior effective July 15, 2026.", "content_markdown": "## Source facts: federation replaces storage, not authorization design\n\n[GitHub’s OIDC guidance](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers) says Actions workflows can access a cloud provider without storing long-lived cloud credentials as GitHub secrets. The cloud is configured to trust GitHub’s OIDC provider; a workflow requests a signed JSON Web Token, presents it to the provider, and receives a short-lived access token for that job.\n\nThe job or workflow needs id-token: write to request the OIDC token. GitHub explicitly notes that this setting alone does not grant permission to modify GitHub or cloud resources. The cloud trust relationship and the permissions attached to the resulting cloud identity determine what the job can do.\n\nGitHub requires at least one trust condition so an untrusted repository cannot request access to the organization’s cloud resources. Claims such as issuer, audience, subject, repository, ref, and environment can define that boundary. GitHub recommends environment protection rules when environments participate in the OIDC policy and recommends the cloud provider’s official action for the token exchange when available.\n\nThe current OIDC reference adds an operational detail for GitHub.com: repositories created after July 15, 2026 use an immutable default subject containing owner and repository IDs. Older repositories retain the prior name-based format unless they opt in, while later renames and transfers move to the immutable form. That rollout does not apply to GitHub Enterprise Server. Trust-policy migration must match the actual subject format.\n\n## DSE recommendation: write the trust statement before the workflow\n\nFor each deployment, state in plain language: “this repository, from this branch, tag, reusable workflow, or protected environment, may assume this cloud role for this purpose.” Translate that statement into exact GitHub claims and cloud conditions. Reject wildcard organization trust and broad repository patterns unless a documented design truly requires them.\n\n- Inventory reusable credentials. Find cloud keys in repository, organization, and environment secrets; workflow files; runner configuration; external secret stores; deployment scripts; and copied runbooks. Map each to the workflows and cloud actions that use it.\n\n- Inspect the real token shape. Determine issuer, audience, subject format, repository and owner IDs, ref, environment, and reusable-workflow context for a controlled run. Account for repository age, rename, transfer, and the GitHub.com versus Enterprise Server boundary.\n\n- Create a narrow cloud role. Limit trust to the approved claims and permissions to the required resource and action. Separate production from test, deployment from administration, and read from write. Keep token lifetime no longer than operationally necessary.\n\n- Protect the path to the token. Restrict workflow and environment changes through branch protection, CODEOWNERS or equivalent review, environment reviewers, and limited repository administration. Pin third-party actions to reviewed immutable commits where the risk warrants it.\n\n- Test positive and negative cases. Prove the approved branch or environment can deploy. Prove a pull request, fork, wrong branch, unprotected environment, different repository, and unauthorized resource cannot. Confirm cloud audit logs identify the federated principal and GitHub run.\n\n- Revoke the old secret. Remove it from GitHub and runners, revoke it at the provider, search for copies, observe scheduled and rarely used workflows, and preserve rollback through a controlled break-glass process rather than restoring the shared key.\n\nMonitor failed token exchanges, unexpected subjects, role assumptions outside deployment windows, denied cloud actions, changes to trust policies, and workflows newly granted id-token: write. Review the design after repository transfer, rename, environment change, workflow reuse change, or cloud-role expansion. Federation reduces secret exposure and rotation burden, but a broad trust rule can turn any compromised workflow inside its scope into a credential mint. The security value comes from making that scope both narrow and observable.\n\nKeep an emergency revocation procedure that disables the cloud trust relationship without requiring a repository change. Test that action and the recovery approval path so a compromised workflow can be contained even when GitHub administration is unavailable.\n\n## Official references\n\n- GitHub Docs, [Configuring OpenID Connect in cloud providers](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers), living documentation reviewed August 11, 2026.\n\n- GitHub Docs, [OpenID Connect reference](https://docs.github.com/en/actions/reference/security/oidc), including immutable subject-claim behavior effective July 15, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/", "url": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-11" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Replace GitHub Actions cloud secrets with OpenID Connect federation", "item": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/#article", "identifier": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/", "url": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/", "headline": "Replace GitHub Actions cloud secrets with OpenID Connect federation", "description": "GitHub Actions can exchange a GitHub-issued OIDC token for a short-lived cloud credential instead of storing a long-lived key. The security gain…", "abstract": "GitHub Actions can exchange a GitHub-issued OIDC token for a short-lived cloud credential instead of storing a long-lived key. The security gain depends on strict trust claims, least-privilege cloud roles, protected environments, and tested revocation.", "articleBody": "Source facts: federation replaces storage, not authorization design\nGitHub’s OIDC guidance says Actions workflows can access a cloud provider without storing long-lived cloud credentials as GitHub secrets. The cloud is configured to trust GitHub’s OIDC provider; a workflow requests a signed JSON Web Token, presents it to the provider, and receives a short-lived access token for that job.\nThe job or workflow needs id-token: write to request the OIDC token. GitHub explicitly notes that this setting alone does not grant permission to modify GitHub or cloud resources. The cloud trust relationship and the permissions attached to the resulting cloud identity determine what the job can do.\nGitHub requires at least one trust condition so an untrusted repository cannot request access to the organization’s cloud resources. Claims such as issuer, audience, subject, repository, ref, and environment can define that boundary. GitHub recommends environment protection rules when environments participate in the OIDC policy and recommends the cloud provider’s official action for the token exchange when available.\nThe current OIDC reference adds an operational detail for GitHub.com: repositories created after July 15, 2026 use an immutable default subject containing owner and repository IDs. Older repositories retain the prior name-based format unless they opt in, while later renames and transfers move to the immutable form. That rollout does not apply to GitHub Enterprise Server. Trust-policy migration must match the actual subject format.\n\nDSE recommendation: write the trust statement before the workflow\nFor each deployment, state in plain language: “this repository, from this branch, tag, reusable workflow, or protected environment, may assume this cloud role for this purpose.” Translate that statement into exact GitHub claims and cloud conditions. Reject wildcard organization trust and broad repository patterns unless a documented design truly requires them.\n\nInventory reusable credentials. Find cloud keys in repository, organization, and environment secrets; workflow files; runner configuration; external secret stores; deployment scripts; and copied runbooks. Map each to the workflows and cloud actions that use it.\nInspect the real token shape. Determine issuer, audience, subject format, repository and owner IDs, ref, environment, and reusable-workflow context for a controlled run. Account for repository age, rename, transfer, and the GitHub.com versus Enterprise Server boundary.\nCreate a narrow cloud role. Limit trust to the approved claims and permissions to the required resource and action. Separate production from test, deployment from administration, and read from write. Keep token lifetime no longer than operationally necessary.\nProtect the path to the token. Restrict workflow and environment changes through branch protection, CODEOWNERS or equivalent review, environment reviewers, and limited repository administration. Pin third-party actions to reviewed immutable commits where the risk warrants it.\nTest positive and negative cases. Prove the approved branch or environment can deploy. Prove a pull request, fork, wrong branch, unprotected environment, different repository, and unauthorized resource cannot. Confirm cloud audit logs identify the federated principal and GitHub run.\nRevoke the old secret. Remove it from GitHub and runners, revoke it at the provider, search for copies, observe scheduled and rarely used workflows, and preserve rollback through a controlled break-glass process rather than restoring the shared key.\n\nMonitor failed token exchanges, unexpected subjects, role assumptions outside deployment windows, denied cloud actions, changes to trust policies, and workflows newly granted id-token: write. Review the design after repository transfer, rename, environment change, workflow reuse change, or cloud-role expansion. Federation reduces secret exposure and rotation burden, but a broad trust rule can turn any compromised workflow inside its scope into a credential mint. The security value comes from making that scope both narrow and observable.\nKeep an emergency revocation procedure that disables the cloud trust relationship without requiring a repository change. Test that action and the recovery approval path so a compromised workflow can be contained even when GitHub administration is unavailable.\n\nOfficial references\n\nGitHub Docs, Configuring OpenID Connect in cloud providers, living documentation reviewed August 11, 2026.\nGitHub Docs, OpenID Connect reference, including immutable subject-claim behavior effective July 15, 2026.", "datePublished": "2026-08-11T10:01:00+00:00", "dateModified": "2026-08-11T14:48:24+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/github-actions-oidc-cloud-federation/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Replace GitHub Actions cloud secrets with OpenID Connect federation" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Important priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 651, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "GitHub Docs: Configuring OpenID Connect in cloud providers", "url": "https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers" } } ] } }