|
| 1 | +--- |
| 2 | +title: Configuring OpenID Connect in Docker |
| 3 | +shortTitle: OIDC in Docker |
| 4 | +intro: Use OpenID Connect within your workflows to authenticate with Docker Hub without storing long-lived credentials. |
| 5 | +versions: |
| 6 | + fpt: '*' |
| 7 | + ghec: '*' |
| 8 | +contentType: how-tos |
| 9 | +category: |
| 10 | + - Secure your workflows |
| 11 | +--- |
| 12 | + |
| 13 | +## Overview |
| 14 | + |
| 15 | +OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to authenticate with [Docker Hub](https://hub.docker.com/) to push and pull container images without storing Docker passwords, personal access tokens (PATs), or organization access tokens (OATs) in {% data variables.product.company_short %}. |
| 16 | + |
| 17 | +Instead of managing long-lived credentials, you configure a trust relationship between your {% data variables.product.prodname_dotcom %} organization and your Docker organization. When a workflow runs, {% data variables.product.prodname_dotcom %} issues a short-lived OIDC token that Docker validates against your configured rulesets, then issues a scoped access token for the workflow. |
| 18 | + |
| 19 | +This guide gives an overview of how to configure Docker Hub to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and demonstrates how to use this configuration in a {% data variables.product.prodname_actions %} workflow. |
| 20 | + |
| 21 | +For more information, see [OIDC connections](https://docs.docker.com/enterprise/security/oidc-connections/) in the Docker documentation. |
| 22 | + |
| 23 | +## Prerequisites |
| 24 | + |
| 25 | +{% data reusables.actions.oidc-link-to-intro %} |
| 26 | + |
| 27 | +{% data reusables.actions.oidc-security-notice %} |
| 28 | + |
| 29 | +{% data reusables.actions.oidc-on-ghecom %} |
| 30 | + |
| 31 | +* You must have a Docker Business or Docker Team subscription. |
| 32 | +* You must be an organization owner or editor in your Docker organization. |
| 33 | +* You should plan which repositories, branches, and workflows need access to Docker Hub, and configure rulesets accordingly. For more information, see [Rulesets and subject claims](https://docs.docker.com/enterprise/security/oidc-connections/rulesets-claims/) in the Docker documentation. |
| 34 | + |
| 35 | +## Adding the identity provider to Docker Hub |
| 36 | + |
| 37 | +To use OIDC with Docker, establish a trust relationship between {% data variables.product.prodname_actions %} and Docker Hub by creating an OIDC connection. For more information about this process, see [Create and manage OIDC connections](https://docs.docker.com/enterprise/security/oidc-connections/create-manage/) in the Docker documentation. |
| 38 | + |
| 39 | +1. Sign in to [Docker Home](https://app.docker.com/) and navigate to your organization. |
| 40 | +1. Go to **Identity & auth** > **OIDC connections**. |
| 41 | +1. Select **Create OIDC connection**. |
| 42 | +1. Configure at least one ruleset to define which GitHub repositories, branches, or workflows can authenticate. Each ruleset specifies: |
| 43 | + * **Rules**: Conditions matched against OIDC token claims (repository, branch, workflow path). Wildcard patterns like `repo:my-org/*` are supported. |
| 44 | + * **Resources**: Docker Hub repositories or Docker Build Cloud projects the workflow can access. |
| 45 | + * **Scopes**: Permission levels (`read`, `write`). |
| 46 | +1. Save the connection and copy the **connection ID** for use in your workflow. |
| 47 | + |
| 48 | +## Updating your {% data variables.product.prodname_actions %} workflow |
| 49 | + |
| 50 | +Once you have created an OIDC connection in Docker Hub, update your workflow to authenticate using the [`docker/oidc-action`](https://github.com/docker/oidc-action) and [`docker/login-action`](https://github.com/docker/login-action) actions. |
| 51 | + |
| 52 | +The following example uses the placeholder `YOUR_CONNECTION_ID` for the connection ID you copied from Docker Hub, and `YOUR_DOCKER_ORG` for your Docker organization name. |
| 53 | + |
| 54 | +```yaml |
| 55 | +name: Build and push with OIDC |
| 56 | + |
| 57 | +on: |
| 58 | + push: |
| 59 | + branches: [main] |
| 60 | + |
| 61 | +permissions: |
| 62 | + id-token: write |
| 63 | + contents: read |
| 64 | + |
| 65 | +jobs: |
| 66 | + build: |
| 67 | + runs-on: ubuntu-latest |
| 68 | + steps: |
| 69 | + - name: Check out repository |
| 70 | + uses: actions/checkout@v4 |
| 71 | + |
| 72 | + - name: Get Docker OIDC token |
| 73 | + id: docker-oidc |
| 74 | + uses: docker/oidc-action@v1 |
| 75 | + with: |
| 76 | + connection_id: YOUR_CONNECTION_ID |
| 77 | + |
| 78 | + - name: Sign in to Docker Hub |
| 79 | + uses: docker/login-action@v4 |
| 80 | + with: |
| 81 | + username: YOUR_DOCKER_ORG |
| 82 | + password: {% raw %}${{ steps.docker-oidc.outputs.token }}{% endraw %} |
| 83 | + |
| 84 | + - name: Build and push |
| 85 | + uses: docker/build-push-action@v6 |
| 86 | + with: |
| 87 | + push: true |
| 88 | + tags: YOUR_DOCKER_ORG/my-image:latest |
| 89 | +``` |
| 90 | +
|
| 91 | +### Key workflow settings |
| 92 | +
|
| 93 | +* **`permissions.id-token: write`** is required so that {% data variables.product.prodname_dotcom %} can issue an OIDC token for the workflow. |
| 94 | +* The `docker/oidc-action` exchanges the {% data variables.product.prodname_dotcom %} OIDC token for a short-lived Docker access token based on your connection's rulesets. |
| 95 | +* The `docker/login-action` uses the token output to authenticate with Docker Hub. The `username` field should be your Docker organization name. |
| 96 | + |
| 97 | +### Subject claim matching |
| 98 | + |
| 99 | +Docker evaluates the `sub` claim from the {% data variables.product.prodname_dotcom %} OIDC token against the rulesets you configured. The default subject claim format is: |
| 100 | + |
| 101 | +```text |
| 102 | +repo:<owner>/<repo>:ref:refs/heads/<branch> |
| 103 | +``` |
| 104 | + |
| 105 | +Different workflow triggers produce different subject claims. For example: |
| 106 | + |
| 107 | +| Trigger | Subject claim format | |
| 108 | +|---------|---------------------| |
| 109 | +| Branch push | `repo:my-org/my-repo:ref:refs/heads/main` | |
| 110 | +| Pull request | `repo:my-org/my-repo:pull_request` | |
| 111 | +| Tag | `repo:my-org/my-repo:ref:refs/tags/v1.0` | |
| 112 | +| Environment | `repo:my-org/my-repo:environment:production` | |
| 113 | + |
| 114 | +You can use wildcard patterns in your rulesets to match multiple repositories or branches. For example, `repo:my-org/*` matches all repositories in your organization. |
| 115 | + |
| 116 | +For more information, see [Rulesets and subject claims](https://docs.docker.com/enterprise/security/oidc-connections/rulesets-claims/) in the Docker documentation. |
| 117 | + |
| 118 | +## Further reading |
| 119 | + |
| 120 | +* [OIDC connections overview](https://docs.docker.com/enterprise/security/oidc-connections/) in the Docker documentation |
| 121 | +* [Create and manage OIDC connections](https://docs.docker.com/enterprise/security/oidc-connections/create-manage/) in the Docker documentation |
| 122 | +* [Rulesets and subject claims](https://docs.docker.com/enterprise/security/oidc-connections/rulesets-claims/) in the Docker documentation |
| 123 | +* [AUTOTITLE](/actions/concepts/security/openid-connect) |
0 commit comments