Skip to content
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@ versions:
children:
- /oidc-in-aws
- /oidc-in-azure
- /oidc-in-docker
- /oidc-in-google-cloud-platform
- /oidc-in-hashicorp-vault
- /oidc-in-jfrog
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,123 @@
---
title: Configuring OpenID Connect in Docker
shortTitle: OIDC in Docker
intro: Use OpenID Connect within your workflows to authenticate with Docker Hub without storing long-lived credentials.
versions:
fpt: '*'
ghec: '*'
contentType: how-tos
category:
- Secure your workflows
---

## Overview

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 %}.

Check failure on line 15 in content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md

View workflow job for this annotation

GitHub Actions / lint-content

Strings that contain "personal access token" should use the product variable instead

The string personal access tokens can be replaced with a variable. You should use one of the variables from data/variables/product.yml instead of the literal phrase(s).

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.

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.

For more information, see [OIDC connections](https://docs.docker.com/enterprise/security/oidc-connections/) in the Docker documentation.

## Prerequisites

{% data reusables.actions.oidc-link-to-intro %}

{% data reusables.actions.oidc-security-notice %}

{% data reusables.actions.oidc-on-ghecom %}

* You must have a Docker Business or Docker Team subscription.
* You must be an organization owner or editor in your Docker organization.
* 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.
Comment thread
gmondello marked this conversation as resolved.
Outdated

## Adding the identity provider to Docker Hub

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.

1. Sign in to [Docker Home](https://app.docker.com/) and navigate to your organization.
1. Go to **Identity & auth** > **OIDC connections**.
1. Select **Create OIDC connection**.
1. Configure at least one ruleset to define which GitHub repositories, branches, or workflows can authenticate. Each ruleset specifies:
Comment thread
gmondello marked this conversation as resolved.
Outdated
* **Rules**: Conditions matched against OIDC token claims (repository, branch, workflow path). Wildcard patterns like `repo:my-org/*` are supported.
* **Resources**: Docker Hub repositories or Docker Build Cloud projects the workflow can access.
* **Scopes**: Permission levels (`read`, `write`).
1. Save the connection and copy the **connection ID** for use in your workflow.

## Updating your {% data variables.product.prodname_actions %} workflow

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.

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.

```yaml

Check failure on line 54 in content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md

View workflow job for this annotation

GitHub Actions / lint-content

Code examples with third-party actions must include disclaimer reusable

Code examples with third-party actions must include the disclaimer reusable. Found third-party actions: 'docker/oidc-action@v1', 'docker/login-action@v4', 'docker/build-push-action@v6'. Add '{% data reusables.actions.actions-not-certified-by-github-comment %}' before or inside this code block.
Comment thread
gmondello marked this conversation as resolved.
name: Build and push with OIDC

on:
push:
branches: [main]

permissions:
id-token: write
contents: read

jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v4

Check failure on line 70 in content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md

View workflow job for this annotation

GitHub Actions / lint-content

GitHub-owned action references should not be hardcoded

The string actions/checkout@v4 is hardcoding a reference to a GitHub-owned action. You should use the reusables for the action. e.g. {% data reusables.actions.action-checkout %}.
Comment thread
gmondello marked this conversation as resolved.
Outdated

- name: Get Docker OIDC token
id: docker-oidc
uses: docker/oidc-action@v1

Check failure on line 74 in content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md

View workflow job for this annotation

GitHub Actions / lint-content

Code examples that use third-party actions must always pin to a full length commit SHA

Code examples that use third-party actions must always pin to a full length commit SHA.
Comment thread
gmondello marked this conversation as resolved.
Outdated
Comment thread
gmondello marked this conversation as resolved.
Outdated
with:
connection_id: YOUR_CONNECTION_ID

- name: Sign in to Docker Hub
uses: docker/login-action@v4

Check failure on line 79 in content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md

View workflow job for this annotation

GitHub Actions / lint-content

Code examples that use third-party actions must always pin to a full length commit SHA

Code examples that use third-party actions must always pin to a full length commit SHA.
Comment thread
gmondello marked this conversation as resolved.
Outdated
Comment thread
gmondello marked this conversation as resolved.
Outdated
with:
username: YOUR_DOCKER_ORG
password: {% raw %}${{ steps.docker-oidc.outputs.token }}{% endraw %}

- name: Build and push
uses: docker/build-push-action@v6

Check failure on line 85 in content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md

View workflow job for this annotation

GitHub Actions / lint-content

Code examples that use third-party actions must always pin to a full length commit SHA

Code examples that use third-party actions must always pin to a full length commit SHA.
Comment thread
gmondello marked this conversation as resolved.
Outdated
Comment thread
gmondello marked this conversation as resolved.
Outdated
with:
push: true
tags: YOUR_DOCKER_ORG/my-image:latest
```

### Key workflow settings

* **`permissions.id-token: write`** is required so that {% data variables.product.prodname_dotcom %} can issue an OIDC token for the workflow.
* 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.
* The `docker/login-action` uses the token output to authenticate with Docker Hub. The `username` field should be your Docker organization name.

### Subject claim matching

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:

```text
repo:<owner>/<repo>:ref:refs/heads/<branch>
```

Different workflow triggers produce different subject claims. For example:

| Trigger | Subject claim format |
|---------|---------------------|
| Branch push | `repo:my-org/my-repo:ref:refs/heads/main` |
| Pull request | `repo:my-org/my-repo:pull_request` |
| Tag | `repo:my-org/my-repo:ref:refs/tags/v1.0` |
| Environment | `repo:my-org/my-repo:environment:production` |

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.
Comment thread
gmondello marked this conversation as resolved.

For more information, see [Rulesets and subject claims](https://docs.docker.com/enterprise/security/oidc-connections/rulesets-claims/) in the Docker documentation.

## Further reading

* [OIDC connections overview](https://docs.docker.com/enterprise/security/oidc-connections/) in the Docker documentation
* [Create and manage OIDC connections](https://docs.docker.com/enterprise/security/oidc-connections/create-manage/) in the Docker documentation
* [Rulesets and subject claims](https://docs.docker.com/enterprise/security/oidc-connections/rulesets-claims/) in the Docker documentation
* [AUTOTITLE](/actions/concepts/security/openid-connect)
Comment thread
gmondello marked this conversation as resolved.
Outdated
Loading