Docker’s OIDC Push Turns GitHub Actions Security Into an Organization-Tier Feature

Docker rolled out OpenID Connect (OIDC) support for GitHub Actions on July 31, 2026, letting workflows authenticate to Docker Hub with short-lived, per-run tokens instead of the long-lived personal access tokens (PATs) and organization access tokens (OATs) that have historically sat in GitHub secrets. The change targets a real, well-measured source of CI/CD compromise. It just does not reach everyone: OIDC connections are limited to Docker Team, Docker Business, and Docker Hardened Images (DHI) subscriptions, plus organizations accepted into the Docker Sponsored Open Source Program (DSOS). Docker’s free Personal plan and its paid, individual-focused Pro plan are both left out, because OIDC connections are configured at the organization level in Docker Home, not on a personal account.

Why Stored CI/CD Credentials Are a Real Problem

Every GitHub Actions workflow that pushes or pulls images from Docker Hub has needed a PAT or OAT saved as a GitHub secret. Docker’s own announcement is blunt about what that setup costs: a leaked token hands over registry access, letting an attacker pull private images or push malicious ones, and that access holds until someone notices and revokes it. Rotating those tokens is a manual chore that does not scale as pipelines multiply, and stale credentials are a routine audit finding.

That is not a hypothetical risk. GitGuardian’s State of Secrets Sprawl 2026 report, published in March 2026, counted 28.65 million hardcoded secrets newly exposed on public GitHub in 2025, a 34 percent year-over-year increase and the largest single-year jump the company has recorded. The figure most relevant to Docker’s announcement: of the machines GitGuardian found compromised in secret-leak incidents, 59 percent were CI/CD runners rather than personal workstations. A credential embedded in a pipeline does not just expose one developer’s access. It can let an attacker manipulate the workflow itself and move laterally across everything that pipeline touches.

How Docker’s OIDC Connections Work

The mechanics mirror the OIDC pattern GitHub already documents for AWS and Google Cloud. For every workflow run, GitHub issues a signed JSON Web Token (JWT) carrying claims about that specific run: the repository, repository owner and ID, the ref and commit SHA, the environment, the workflow and run ID, the actor who triggered it, and standard issued-at and expiry timestamps. Docker’s docker/login-action (v4.5.0 or later) presents that token to Docker, which checks its signature against GitHub’s public key registry and matches it against rulesets configured in the Docker Home admin console.

A single connection can hold up to five rulesets, each scoping access to specific repositories, branches, or workflows. Docker’s documentation recommends pinning rulesets tightly, for example to only the main branch of one repository, rather than granting access to every branch across an entire organization. When a ruleset matches, Docker issues a short-lived access token, valid for minutes and usable only once, which docker/login-action then uses for the actual docker pull, docker push, and docker build calls.

The Four-Step Migration

Setting it up follows a short, reversible checklist: create a connection and its rulesets in Docker Home, add id-token: write to the workflow’s permissions block and point the login step at the connection ID, confirm the workflow still runs successfully, then delete the old PAT or OAT from GitHub secrets. Docker is explicit that migration is opt-in and gradual: existing PATs and OATs keep working, organizations can move workflows over on their own schedule, and everything downstream of authentication (images, registries, build steps) is unchanged.

A Wrinkle Docker’s Own Setup Guide Flags

Docker’s instructions call out a detail GitHub changed earlier this year. A GitHub changelog entry from April 23, 2026 set July 15, 2026 as the date new repositories would start receiving OIDC tokens with an immutable subject claim format, one built from the numeric owner ID and repository ID (for example, repo:octocat@123456/my-repo@456789:ref:refs/heads/main) instead of the older format built from organization and repository names (repo:octocat/my-repo:ref:refs/heads/main). The old format had a real weakness: if an organization or repository name was ever freed up and reused, a different account could end up matching the same subject string and mint tokens against trust policies meant for the original owner. Repositories created before July 15, 2026 keep the legacy format for now, so teams writing Docker’s rulesets need to check which subject format their specific repository actually issues before writing a matching rule.

Following AWS and GCP, With One Difference

Docker is not claiming to have invented this pattern. Its announcement points directly to AWS’s and Google Cloud’s existing OIDC federation for GitHub Actions as precedent, and GitHub’s own OIDC documentation describes the identical trade: instead of a workflow holding a long-lived secret, the provider checks a short-lived, cryptographically signed token against a preconfigured trust policy and hands back credentials that expire automatically. AWS IAM’s OIDC identity providers and GCP’s Workload Identity Federation are both standard, no-extra-cost parts of their respective identity and access management products, available on any account regardless of pricing tier.

Docker’s version of that mechanism is not a standard part of every account. It is scoped to organizations, specifically to organizations on Docker Team ($15 to $16 per user per month), Docker Business ($24 per user per month), or DHI subscriptions, plus organizations Docker has separately accepted into DSOS. Docker Personal, the free individual tier, is not eligible. Neither is Docker Pro, the $9 to $11 per month individual professional tier, because OIDC connections are configured against an organization in Docker Home rather than a personal account. A solo developer or a small team paying for Docker Pro authenticates to Docker Hub in GitHub Actions exactly as they did before OIDC connections existed: with a stored PAT that has to be rotated by hand.

What This Means for Teams Evaluating the Move

For organizations already on Team, Business, or DHI, the migration path Docker describes is low-risk. It runs alongside existing credentials, it is verifiable before the old token gets deleted, and it directly addresses a documented, measurable source of CI/CD compromise. Those teams have a clear reason to work through the four-step checklist soon, particularly for any repository created after July 15, 2026, where the new immutable subject claim format already applies by default.

For everyone else, the guidance has not changed. Individual maintainers, small teams on Docker Pro, and open-source projects that have not gone through DSOS still depend on manually rotated PATs or OATs for Docker Hub access from GitHub Actions. GitGuardian’s numbers suggest that population, stored credentials that a human has to remember to rotate, is exactly where CI/CD compromises keep originating.