FR
live

Docker Enables OIDC for GitHub Actions — The End of Static Tokens in CI/CD Pipelines

Docker Hub now supports OpenID Connect for GitHub Actions. Workflows authenticate with short-lived, per-run tokens instead of storing PATs or OATs in GitHub secrets. Manual credential rotation is officially obsolete.

A single USB security key plugged into an empty server port, amber LED glowing against a dark technical rack

On July 31, 2026, Docker announced native OpenID Connect (OIDC) support for GitHub Actions. A workflow that pushes or pulls images from Docker Hub no longer needs to store a Personal Access Token (PAT) or Organization Access Token (OAT) in repository secrets. Every run receives an ephemeral token, signed by GitHub, verified by Docker, and valid for only a few minutes.

This closes a gap that has persisted since 2019: software supply chains were authenticating with static secrets that nobody ever rotated.

The problem with stored credentials

In a typical CI/CD pipeline, Docker Hub authentication works like this:

  1. A developer generates a PAT in their Docker Hub account settings.
  2. The token gets copied into a GitHub Secret (DOCKER_TOKEN).
  3. The workflow calls docker/login-action, then runs docker push or docker pull.

This model has three structural defects:

  • Long-lived: a PAT expires after 90 days at best, but in practice nobody rotates them. The token remains active until manual revocation.
  • Wide blast radius: a token leaked through a build log, an environment variable dump, or unauthorized repository access grants full registry access — both push and pull.
  • Rotation doesn’t scale: when an organization grows from 5 to 50 workflows, each new pipeline adds another secret to track. Manual rotation becomes an operational nightmare, and stale tokens are a recurring audit finding.

Docker explicitly calls out all three in its announcement. The verdict is blunt: static tokens are the weakest link in modern CI/CD, and the industry has known this since AWS and GCP migrated to OIDC for cloud resource access in 2023.

How GitHub Actions OIDC ↔ Docker Hub works

The new authentication flow eliminates secrets entirely:

  1. GitHub issues a signed JWT that encodes the repository, branch, environment, and other metadata about the current workflow run.
  2. The workflow invokes docker/login-action in OIDC mode, which presents this JWT to Docker.
  3. Docker verifies the JWT signature against GitHub’s public key registry (https://token.actions.githubusercontent.com/.well-known/jwks), then checks the token’s claims against rulesets configured in the Docker Admin Console.
  4. If the token matches a ruleset, Docker issues a short-lived access token, scoped to the resources defined in that ruleset.
  5. docker/login-action uses this token for subsequent pull, push, and build commands.

The Docker token expires in minutes and cannot be reused. There are no secrets to store, no secrets to rotate, and no secrets to leak.

This architecture is identical to what AWS (aws-actions/configure-aws-credentials) and GCP (google-github-actions/auth) have used since 2023 for cloud resource access. Docker is now applying it to container image registries.

Setup in two steps

Adoption is simple enough to ship in a single Pull Request.

Step 1: Create an OIDC connection in Docker Home

From the Docker Admin Console (hub.docker.com), the organization admin navigates to OIDC connections and creates a connection. The connection defines up to five rulesets that control:

  • Which GitHub repositories (owner/repo) can authenticate
  • Which branches (refs/heads/main) are allowed
  • Which environments (production, staging) are eligible
  • Which Docker Hub namespaces (myorg/*) are accessible

Step 2: Update the workflow YAML

yaml
- name: Login to Docker Hub
  uses: docker/login-action@v3
  with:
    registry: docker.io
    username: ${{ vars.DOCKER_USERNAME }}
    # No password or token — OIDC handles it

The docker/login-action automatically detects the GitHub Actions OIDC context and initiates the token exchange. No additional workflow-side configuration is required.

What doesn’t change — and what’s still missing

OIDC support is available to organizations on Docker Team, Docker Business, or Docker Hardened Images (DHI) subscriptions, as well as organizations eligible for the Docker Sponsored Open Source (DSOS) program. Docker Free accounts are not covered.

This is an understandable economic choice, but it creates a security divide: the smallest open-source projects — which are also the most exposed to secret compromises due to limited resources — remain on the PAT/OAT model.

Another technical limitation: OIDC currently only covers GitHub Actions. Organizations using GitLab CI, Bitbucket Pipelines, CircleCI, or Jenkins must continue managing static tokens. Docker has indicated that GitLab support is « under evaluation » without providing a timeline.

The AWS precedent: why adoption will be fast

When AWS launched OIDC support for GitHub Actions in 2023, teams migrated en masse within six months. The reason is straightforward: IAM key rotation is a compliance requirement under SOC 2, ISO 27001, and PCI DSS, and OIDC makes it automatic.

The same dynamic applies to Docker Hub. Teams pushing images to a production registry face identical compliance obligations. A static token that survives six sprints is an audit failure. OIDC eliminates that risk with zero ongoing effort.

Verdict

If your organization uses GitHub Actions and a Docker Team subscription or higher, set up the OIDC connection this week. The workflow YAML change takes ten minutes, and you permanently remove the risk of Docker Hub credential leaks in your pipelines.

If you’re on Docker Free, the migration path is blocked — and this is an argument to upgrade to Docker Team if your pipeline pushes to production. A subscription (starting at $9/user/month) costs less than a security incident caused by a leaked token.

OIDC for container registries was the missing anomaly in the CI/CD landscape. Docker just fixed it. The next audit report that flags static tokens in GitHub secrets will be much harder to justify.

References

  • Docker Blog, « Docker OIDC connections for GitHub Actions available for Docker Orgs », July 31, 2026
  • GitHub Docs, « About security hardening with OpenID Connect », accessed August 11, 2026
  • AWS Docs, « Configuring OpenID Connect in Amazon Web Services », updated 2025
  • GCP Docs, « Workload Identity Federation for GitHub Actions », updated 2025

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

← Back to the feed

Type at least two characters.

navigate open esc dismiss