Eliminate Stored Credentials in Your CI/CD Pipelines
TL;DR: Docker now supports OpenID Connect (OIDC) for GitHub Actions. Your workflows can authenticate with short-lived, per-run tokens instead of stored PATs or OATs. No secrets to rotate, no credentials to leak.
GitHub OIDC connections are available to organizations with Docker Team, Docker Business, or Docker Hardened Images (DHI) subscriptions, as well as organizations enrolled in the Docker Sponsored Open Source Program (DSOS).
Table of contents
The problem with stored credentials
Who should use this
How OIDC connections work
Getting started
What doesn’t change
Learn more
OIDC token exchange flow between GitHub Actions and Docker
The problem with stored credentials
Every GitHub Actions workflow that pushes or pulls images from Docker Hub authenticates with a personal access token (PAT) or organization access token (OAT) stored as a GitHub secret. These credentials are long-lived. Someone has to remember to rotate them. A leaked token grants access to your registry — pulling private images, pushing malicious ones — and that access persists until someone discovers and revokes it. Rotation is manual and does not scale. As pipelines multiply, so do the credentials that need tracking, and stale tokens are a common audit finding.
Who should use this
GitHub issues a signed identity token (a JWT) that encodes the repository, branch, environment, and other metadata about the workflow run.
The workflow calls docker/login-action, which presents this token to Docker.
Docker verifies the token’s signature against GitHub’s public key registry and checks it against rulesets configured in the Admin Console.
If the token matches a ruleset, Docker returns a short-lived access token scoped to the resources defined in that ruleset.
docker/login-action uses this token to authenticate to Docker Hub. From there, docker pull, docker push, and docker build commands work as usual.
The entire exchange happens without any stored secrets, API keys, or access tokens. The short-lived Docker access token expires in minutes and cannot be reused.
This is the same pattern that AWS and GCP already use for cloud resource access (AWS OIDC for GitHub Actions, GCP Workload Identity Federation). Docker is applying it to container registry access.
Getting started
Setup is a one-time connection in Docker Home plus a small update to your workflow YAML.
Step 1: Create a connection
Sign in to Docker Home, select your organization, and navigate to OIDC connections. Select Create OIDC connection and configure the rulesets that control which repositories, branches, and workflows can access which Docker Hub resources. You can create up to five rulesets per connection. When a workflow triggers an OIDC exchange, Docker checks the token against every ruleset defined in your connection. If a ruleset’s conditions are satisfied, Docker grants access based on the parameters set by that ruleset.
Rulesets use OIDC subject claims to match incoming tokens. You can pin to specific repos and branches as a recommended security best practice:
repo:my-org/my-repo:ref:refs/heads/main — only the main branch of a specific repo
repo:my-org/my-repo:ref:refs/heads/release-* — all release branches
repo:my-org/my-repo:* – all branches of this repo
repo:my-org/* — any repo in the organization (not recommended)
Copy the connection ID when you are done.
Note: GitHub repositories created after July 15, 2026 use immutable identifiers for default subject claims. For example: repo:octocat@123456/my-repo@456789:ref:refs/heads/main. See the GitHub changelog for more details.
Step 2: Update your workflow
Update your GitHub Actions workflow. Replace <YOUR_CONNECTION_ID> with the ID from the previous step and <YOUR_ORG_NAME> with your Docker organization name:
permissions:
contents: read
id-token: write
steps:
– name: Docker login
uses: docker/login-action@v4 # v4.5.0+
with:
username: <YOUR_ORG_NAME>
env:
DOCKERHUB_OIDC_CONNECTIONID: <YOUR_CONNECTION_ID>
The id-token: write permission lets the workflow request a GitHub OIDC token. The docker/login-action handles the token exchange and Docker login in a single step when DOCKERHUB_OIDC_CONNECTIONID is set. From there, docker pull, docker push, and docker build commands work as usual.details of the incoming claim sub value, which you can use to diagnose why the connection failed.
Step 3: Verify the OIDC connection works
Run your workflow and confirm it completes successfully. If you encounter an error, the Failures tab of the OIDC connection page will show the details of the incoming claim sub value, which you can use to diagnose why the connection failed.
Step 4: Remove the stored credential
After verifying your workflow runs successfully with OIDC, remove the old PAT or OAT from your GitHub repository secrets. You no longer need it.
Migration Checklist
Create a connection
Update your workflow
Verify the OIDC connection works
Remove stored credentials
What doesn’t change
Existing PATs and OATs keep working. Organizations can migrate workflows to OIDC connections at their own pace.
Images, registries, and build workflows are unchanged. OIDC connections only replace the authentication step; everything downstream is the same.
Local development and non-GitHub CI still use PATs and OATs. OIDC connections are the recommended replacement for GitHub Actions specifically. Other CI providers will follow based on demand.
Learn more
Learn more about OpenID Connect
Visit Docker Home to get started
Read the documentation
Quelle: https://blog.docker.com/feed/
