For years, engineers who migrated their GitHub Actions workflows to passwordless cloud authentication — eliminating stored AWS keys, GCP service account credentials, and Azure client secrets via workload identity federation — still had one persistent blind spot: the PAT or organization access token sitting in their GitHub secrets, waiting to authenticate a docker push. As of July 31, Docker closed that gap. The company published Docker's OIDC connections announcement, replacing stored Docker Hub credentials with per-run tokens that expire when the workflow run ends and leave nothing in the secret store to steal, rotate, or forget to revoke.

The announcement arrives as supply chain attackers have made CI/CD runner credentials their primary target. Nearly 29 million new hardcoded secrets appeared in public GitHub commits in 2025 alone, a 34 percent year-over-year increase and the largest single-year total on record, according to GitGuardian's State of Secrets Sprawl 2026. Across the supply chain attacks analyzed in that report, 59 percent of compromised machines were CI/CD runners rather than developer workstations. Eliminating the stored token from the runner removes the primary value an attacker extracts from runner access.

The Problem Stored PATs Created

Docker Hub authentication in GitHub Actions has followed the same pattern since pipelines first started pushing container images. A workflow injects a personal access token (PAT) or organization access token (OAT) as a GitHub encrypted secret. The workflow runs, authenticates, and completes. The token stays — valid, rotatable in theory but not in practice for most teams, and indistinguishable from a legitimate credential if stolen. According to GitGuardian's credential validity data, more than 64 percent of credentials confirmed valid in 2022 were still valid when retested in January 2026.

That longevity is the vulnerability. The March 2025 compromise of tj-actions/changed-files — a GitHub Action installed in more than 23,000 repositories — gave attackers a personal access token that cascaded through the supply chain and ultimately reached Coinbase as the original target, as documented in CISA's CVE-2025-30066 advisory. The attack chain began with a pull_request_target exploit, but the damage was proportional to how many long-lived credentials were stored where that action ran.

In early 2026, a campaign researchers named Pipe-Psiphon demonstrated the next evolution: a modified developer scanning tool that operated silently inside CI runner environments, scraping GitHub tokens, AWS credentials, npm authentication keys, and deployment secrets from memory across pipeline executions, as described in this Pipe-Psiphon memory-scraping campaign analysis. The tool did not crash anything. Most affected organizations saw no unusual alerts. It simply waited for pipelines to run.

GitGuardian's 2026 report found that 32.2 percent of internal repositories contain at least one hardcoded secret. For Docker Hub specifically, the April 2026 Checkmarx KICS compromise — part of the TeamPCP campaign tracked by Google Threat Intelligence as UNC6780 — simultaneously poisoned Docker Hub alongside VS Code's OpenVSX marketplace and GitHub Actions itself, as covered in TechTimes' TeamPCP coverage. Docker Hub credentials were a named target, not collateral.

How Docker OIDC Authentication Works

Docker's implementation follows the workload identity federation pattern that AWS, GCP, and Azure established for cloud resource access — the same JWT-bearer exchange, applied now to container registry authentication.

When a GitHub Actions workflow runs with the new configuration, GitHub's OIDC provider generates a signed JSON Web Token for that specific run. The token contains the repository name and numeric ID, the branch, the environment, and the actor that triggered the workflow — all encoded as claims in the JWT's sub field. The workflow passes this token to the docker/login-action repository (v4.5.0 or later), which presents it to Docker Hub.

Docker Hub verifies the token's cryptographic signature against GitHub's published public key registry, then checks the sub claim against rulesets configured by the organization's administrator. If a ruleset matches, Docker issues a short-lived access token scoped to the resources defined in that ruleset. The access token must be between 300 and 3,600 seconds — five minutes to one hour — as defined in the docker/login-action parameters, and cannot be reused after the workflow run ends.

Nothing persists. There is no credential to rotate and nothing to revoke if a runner is compromised.

The pattern is identical to what AWS STS has provided since 2021 via AWS GitHub Actions OIDC documentation and what GCP Workload Identity Federation offers for the same use case. Docker's announcement completes the picture for teams that had already eliminated stored cloud credentials but still depended on a PAT for the container push step.

Rulesets: The Access Control Layer

Beyond removing stored secrets, the feature introduces a ruleset model that gives administrators fine-grained control over which workflows can authenticate to Docker Hub at all.

Organizations can configure up to five rulesets per OIDC connection, each using subject claim matching to control access, per Docker's ruleset documentation. Supported patterns range from single-branch specificity (repo:my-org/my-repo:ref:refs/heads/main) to full organization-wide access (repo:my-org/*). Docker explicitly marks the organization-wide pattern as not recommended — a configuration that would effectively recreate the over-permissioning problem that long-lived credentials exhibit.

The ruleset model also handles a recent change to GitHub's OIDC token format. Repositories created after July 15, 2026 use immutable numeric identifiers in the default sub claim rather than mutable repository names — meaning a repository rename no longer breaks an existing trust policy or, critically, allows a renamed repository to inherit another repository's access permissions, per GitHub's immutable subject claims changelog. Ruleset patterns for new repositories must account for this format change.

What Changes in Practice

Migration is a one-time update: a connection created in Docker Home, up to five rulesets defined, a connection ID copied, and a small change to the workflow YAML.

The workflow update grants the id-token: write permission, passes the organization name as username, omits the password field entirely, and sets DOCKERHUB_OIDC_CONNECTIONID as an environment variable, as documented in Docker's OIDC getting started guide. Once the workflow runs successfully with the new configuration, the old PAT or OAT can be removed from GitHub secrets. Existing PATs and OATs continue to work during and after migration — Docker is not forcing a cutover, and the two authentication paths operate independently.

Docker's announcement is also clear about what does not change: the OIDC connection authenticates a workflow as if it were a user and then authorizes against the configured ruleset. Organization-level access for other Docker resources continues to be governed by OATs. OIDC connections and OATs serve distinct roles and do not replace each other for all use cases.

Coverage Remains Incomplete Without Scope Discipline

The feature is available immediately for Docker Team, Docker Business, Docker Hardened Images, and Docker Sponsored Open Source Program organizations. Other CI providers are not yet in scope; Docker says support for additional platforms will be evaluated based on demand.

The security benefit is structural — it removes the token rather than hardening the environment around it — but the ruleset configuration carries the risk that prior OIDC implementations have demonstrated. Unit 42's OIDC misconfiguration research from April 2025 documented how overly permissive subject claim matching — trusting any workflow from any branch of any repository in an organization — effectively grants the same broad access that a long-lived token provides, just with a shorter validity window. The security model depends on ruleset specificity, not on the OIDC mechanism alone.

For open source projects enrolled in the Docker Sponsored Open Source Program, the feature matters beyond the enterprise context. Open source repositories are high-value supply chain targets precisely because of their downstream trust. The availability of credential-free registry authentication for publicly maintained projects — the same model available to paying enterprise customers — removes one of the most common attack surfaces in the open source build pipeline.

Is Zero Long-Lived Credentials Now Achievable?

For a GitHub Actions pipeline that builds a container image and pushes it to Docker Hub, the answer is now yes — provided the organization uses Docker Team, Business, DHI, or DSOS, has already adopted OIDC for its cloud provider credentials, and configures Docker OIDC connections with appropriately scoped rulesets.

The remaining stored-credential exposures in most container pipelines are not architectural gaps in Docker or GitHub anymore. They are integration-specific credentials for services that have not yet adopted workload identity federation, legacy configurations that have not been migrated, and — per the GitGuardian report — the 64 percent of credentials from 2022 that are still valid because teams have not rotated them. The tooling to close the Docker Hub leg now exists. The credential debt that accumulates from not using it remains the industry's largest unaddressed exposure.

---

Frequently Asked Questions

Does this mean I no longer need to store a Docker Hub password or token in GitHub Secrets?

Yes — for workflows that push or pull images from Docker Hub as part of a GitHub Actions pipeline, the OIDC connection replaces the stored PAT or OAT entirely. Once you verify the OIDC workflow succeeds, you remove the old secret from the repository. The credential never exists in the secret store and has no value to an attacker who gains access to runner memory after the workflow completes, because the token that authenticated the run has already expired.

What is the difference between a Docker PAT, an OAT, and an OIDC connection?

A PAT (personal access token) is a long-lived credential tied to an individual Docker Hub account, stored as a GitHub secret and passed to every workflow that needs registry access. An OAT (organization access token) serves a similar purpose at the organization level, with broader access scope and centralized management. Both persist until manually revoked and require rotation to stay secure. An OIDC connection replaces both for GitHub Actions: instead of a stored credential, each workflow run receives a short-lived token derived from its own identity — which repository triggered it, which branch, which environment — and that token expires when the run ends. No persistent credential exists to steal, rotate, or audit.

How does Docker's OIDC implementation compare to how AWS and GCP handle GitHub Actions authentication?

The mechanism is identical. AWS STS and GCP Workload Identity Federation both accept GitHub's signed JWT as proof of workflow identity and exchange it for temporary cloud credentials scoped to a pre-configured trust policy. Docker's implementation applies the same pattern to container registry access: GitHub issues the JWT, Docker verifies its signature against GitHub's public key registry, checks the claims against administrator-defined rulesets, and issues a short-lived access token. The only difference is the resource being accessed — container registry rather than cloud API — and the trust policy format, which uses Docker's ruleset model rather than AWS IAM trust policies or GCP attribute conditions. For teams already using OIDC for cloud credentials, the Docker implementation follows the same mental model.

What happens if I configure an overly permissive ruleset?

A ruleset that matches any repository in the organization (repo:my-org/*) grants Docker Hub access to every GitHub Actions workflow across the organization, regardless of which repository or branch triggered it. This recreates the over-permissioning problem that long-lived credentials exhibit — any workflow, including one in a rarely-audited repository, can authenticate to Docker Hub. Docker explicitly marks this pattern as not recommended. The security model depends on scoping rulesets to specific repositories and branches (repo:my-org/my-repo:ref:refs/heads/main), not on OIDC authentication alone. Unit 42's 2025 research on OIDC misconfigurations documented how permissive trust policies become exploitable when attackers can trigger workflows from arbitrary branches or repositories.