Docker active l’OIDC pour GitHub Actions — la fin des tokens statiques dans les pipelines CI/CD

Le 31 juillet 2026, Docker a annoncé le support natif d’OpenID Connect (OIDC) pour GitHub Actions. Concrètement, un workflow qui pousse ou tire des images depuis Docker Hub n’a plus besoin de stocker un Personal Access Token (PAT) ou un Organization Access Token (OAT) dans les secrets du dépôt. Chaque exécution reçoit un token éphémère, signé par GitHub, vérifié par Docker, et valable quelques minutes seulement.

C’est la fin d’une anomalie qui durait depuis 2019 : la supply chain logicielle s’authentifiait avec des secrets statiques que personne ne tournait jamais.

Le problème des credentials stockés

Dans un pipeline CI/CD classique, l’authentification à Docker Hub fonctionne comme ceci :

1. Un développeur génère un PAT dans les paramètres de son compte Docker Hub.
2. Ce token est copié dans un GitHub Secret (DOCKER_USERNAME, DOCKER_PASSWORD ou DOCKER_TOKEN).
3. Le workflow utilise docker/login-action pour s’authentifier, puis exécute docker push ou docker pull.

Ce modèle a trois défauts structurels :

• Longue durée de vie : un PAT expire au mieux après 90 jours, mais en pratique personne ne les tourne. Le token reste actif jusqu’à révocation manuelle.
• Surface d’attaque élargie : un token volé via un log de build, un dump de variables d’environnement, ou un accès non autorisé au dépôt donne un accès complet au registre — push et pull.
• Rotation non scalable : quand une organisation passe de 5 à 50 workflows, chaque nouveau pipeline ajoute un secret à gérer. La rotation manuelle devient un cauchemar opérationnel, et les tokens périmés sont une découverte d’audit récurrente.

Docker cite explicitement ces trois problèmes dans son annonce. Le verdict est sans appel : les tokens statiques sont le maillon faible de la CI/CD moderne, et l’industrie le sait depuis qu’AWS et GCP ont migré vers l’OIDC pour l’accès aux ressources cloud en 2023.

Comment fonctionne l’OIDC GitHub Actions ↔ Docker Hub

Le nouveau flux d’authentification élimine entièrement les secrets :

1. GitHub émet un JWT signé qui encode le repository, la branche, l’environnement et d’autres métadonnées du workflow en cours d’exécution.
2. Le workflow appelle docker/login-action en mode OIDC, qui présente ce JWT à Docker.
3. Docker vérifie la signature du JWT via le registre de clés publiques de GitHub (https://token.actions.githubusercontent.com/.well-known/jwks), puis compare les claims du token aux rulesets configurés dans la console d’administration Docker.
4. Si le token correspond à un ruleset, Docker émet un token d’accès éphémère, scopé aux ressources définies dans ce ruleset.
5. docker/login-action utilise ce token pour les commandes pull, push et build suivantes.

Le token Docker expire en quelques minutes et ne peut pas être réutilisé. Il n’y a aucun secret à stocker, aucun secret à tourner, et aucun secret à fuir.

Cette architecture est identique à celle qu’AWS (aws-actions/configure-aws-credentials) et GCP (google-github-actions/auth) utilisent depuis 2023 pour l’accès aux ressources cloud. Docker l’applique maintenant au registre de conteneurs.

Configuration en deux étapes

La mise en place est suffisamment simple pour être adoptée en une seule Pull Request.

Étape 1 : créer une connexion OIDC dans Docker Home

Depuis la console d’administration Docker (hub.docker.com), l’administrateur d’organisation navigue vers OIDC connections et crée une connexion. La connexion définit jusqu’à cinq rulesets qui contrôlent :

• Quels repositories GitHub (owner/repo) peuvent s’authentifier
• Quelles branches (refs/heads/main) sont autorisées
• Quels environnements (production, staging) sont éligibles
• Quels namespaces Docker Hub (myorg/*) sont accessibles

Étape 2 : modifier le workflow YAML

- name: Login to Docker Hub
  uses: docker/login-action@v3
  with:
    registry: docker.io
    username: ${{ vars.DOCKER_USERNAME }}
    # Plus de mot de passe ni de token stocké

Le docker/login-action détecte automatiquement le contexte OIDC de GitHub Actions et initie l’échange de tokens. Aucune configuration supplémentaire n’est requise côté workflow.

Ce qui ne change pas — et ce qui bloque encore

La fonctionnalité OIDC est disponible pour les organisations ayant souscrit à Docker Team, Docker Business ou Docker Hardened Images (DHI), ainsi que pour les organisations éligibles au programme Docker Sponsored Open Source (DSOS). Les comptes Docker Free ne sont pas couverts.

C’est un choix économique compréhensible mais qui crée une fracture de sécurité : les projets open source les plus modestes, qui sont aussi les plus exposés aux compromissions de secrets faute de moyens, restent sur le modèle PAT/OAT.

Autre limite technique : l’OIDC ne couvre actuellement que GitHub Actions. Les organisations utilisant GitLab CI, Bitbucket Pipelines, CircleCI ou Jenkins doivent continuer à gérer des tokens statiques. Docker a indiqué que le support GitLab était « en cours d’évaluation » sans donner de calendrier.

Le précédent AWS : pourquoi l’adoption va être rapide

Quand AWS a lancé son support OIDC pour GitHub Actions en 2023, les équipes ont massivement migré en moins de six mois. La raison est simple : la rotation des clés IAM est une obligation de conformité dans SOC 2, ISO 27001 et PCI DSS, et l’OIDC la rend automatique.

La même dynamique s’applique à Docker Hub. Les équipes qui poussent des images vers un registre de production sont soumises aux mêmes exigences de conformité. Un token statique qui survit à six sprints est un échec d’audit. L’OIDC élimine ce risque sans effort supplémentaire.

Verdict

Si votre organisation utilise GitHub Actions et un abonnement Docker Team ou supérieur, configurez la connexion OIDC cette semaine. Le changement de workflow YAML prend dix minutes, et vous éliminez définitivement le risque de fuite de credentials Docker Hub dans vos pipelines.

Si vous êtes sur Docker Free, la migration vous est inaccessible — c’est un argument pour passer à Docker Team si votre pipeline pousse en production. Le coût d’un abonnement (à partir de 9 $/mois/utilisateur) est inférieur au coût d’un incident de sécurité lié à un token volé.

L’OIDC pour les registres de conteneurs était une anomalie manquante dans le paysage de la CI/CD. Docker vient de la combler. Le prochain rapport d’audit qui pointera des tokens statiques dans les secrets GitHub sera beaucoup plus difficile à justifier.

Références

• Docker Blog, « Docker OIDC connections for GitHub Actions available for Docker Orgs », 31 juillet 2026
• GitHub Docs, « About security hardening with OpenID Connect », consulté le 11 août 2026
• AWS Docs, « Configuring OpenID Connect in Amazon Web Services », mise à jour 2025
• GCP Docs, « Workload Identity Federation for GitHub Actions », mise à jour 2025