Docker OIDC connections for GitHub Actions available for Docker Orgs

If you’ve been managing Docker credentials in GitHub Actions workflows, you’re probably familiar with that nagging feeling: somewhere in your secrets manager is a Personal Access Token (PAT) or Organization Access Token (OAT) that needs rotating, could accidentally get logged, or might outlive its usefulness. Docker’s new OIDC support for GitHub Actions eliminates that problem entirely. Instead of storing long-lived credentials, your GitHub Actions workflows can now exchange GitHub’s OIDC token for short-lived Docker credentials—tokens that exist only for the duration of your workflow run and are automatically invalidated when it completes.

Here’s how it works technically. When your GitHub Actions job runs, GitHub automatically generates an OIDC token that identifies your workflow with cryptographic proof: which repository it came from, which branch triggered it, even which specific commit. Docker now trusts GitHub’s OIDC provider, so your workflow can present this GitHub-issued token to Docker and receive temporary credentials in return. Your docker build, docker push, or docker pull commands authenticate using these ephemeral tokens instead of static secrets. No credentials to rotate quarterly, no PATs sitting in your secrets vault indefinitely, and no risk of someone accidentally echoing $DOCKER_PASSWORD in job logs from three years ago.

The practical impact is significant for teams running containerized workloads at any scale. Imagine you’re maintaining a microservices architecture where ten different repositories push images to Docker Hub or your Docker registry. Previously, you’d have one shared PAT stored in each repo’s secrets, and rotating it meant updating ten separate locations. Now, each workflow gets its own temporary credential that expires after 15 minutes. You’re also eliminating a whole class of supply-chain risks—compromised repositories can’t leak credentials that work elsewhere because there are no permanent credentials to leak. For organizations already using OIDC with AWS IAM or other cloud providers, this brings consistency to your authentication model across your entire CI/CD stack.

To get started, you’ll need Docker Team, Docker Business, or Docker Hardened Images tier. The configuration in your GitHub Actions workflow is straightforward: instead of docker login with stored credentials, you configure the OIDC connection between your Docker organization and GitHub, then your workflows authenticate automatically. If you’re already familiar with OIDC flows from assuming AWS IAM roles in GitHub Actions (the aws-actions/configure-aws-credentials approach), Docker’s implementation follows the same pattern—just with Docker’s credential endpoint instead of AWS’s. It’s a good reminder that the infrastructure-as-code practices you’ve learned in one context—treating credentials as temporary and workload-specific—apply broadly across your cloud and container ecosystem.