Docker Hub prend désormais en charge OpenID Connect pour GitHub Actions. Un workflow n’a plus besoin de conserver un mot de passe ou un jeton d’accès longue durée pour pousser une image. GitHub émet une identité signée pour le job, Docker vérifie ses attributs puis remet un jeton court et limité à cette exécution.

La réponse rapide

QuestionRéponse
Quel secret disparaît ?Le PAT ou jeton d’organisation Docker stocké dans GitHub.
Le workflow peut-il pousser partout ?Non si les règles OIDC limitent dépôt, branche et environnement.
Faut-il modifier l’action de connexion ?docker/login-action gère l’échange avec l’identifiant de connexion.
Est-ce disponible pour tous ?Docker le réserve à certaines offres Team, Business, DHI et projets open source sponsorisés.
OIDC suffit-il à sécuriser la CI ?Non. Les permissions GitHub et la protection des workflows restent essentielles.

Une identité différente à chaque job

GitHub Actions fournit au job un JWT contenant des claims sur le dépôt, la référence, l’environnement et l’organisation. Docker compare ces informations aux règles configurées. Si elles correspondent, il émet un jeton temporaire autorisant les opérations prévues.

Avec un secret permanent, une fuite peut rester exploitable jusqu’à sa révocation. Avec OIDC, le jeton obtenu expire rapidement et n’existe qu’après validation du contexte. Le risque ne disparaît pas, mais sa durée et sa portée diminuent fortement.

Les règles font toute la différence

Une connexion Docker peut comporter jusqu’à cinq règles. Elles doivent être aussi précises que possible : organisation GitHub, dépôt, branche ou environnement protégé. Autoriser toutes les branches d’un dépôt signifie qu’une modification de workflow sur une branche moins contrôlée peut tenter d’obtenir un accès au registre.

La meilleure configuration réserve le push de production à un environnement GitHub protégé, avec revue éventuelle, et donne aux merge requests un accès en lecture ou aucun accès. Le nom DOCKERHUB_OIDC_CONNECTIONID identifie la connexion, mais ce n’est pas un mot de passe à traiter comme le jeton qu’il remplace.

Migrer sans interrompre les publications

Créez la connexion et ses règles dans Docker Hub, puis ajoutez les permissions OIDC au workflow. Testez un push vers un dépôt ou un tag temporaire. Vérifiez ensuite qu’une branche non autorisée échoue réellement : un contrôle de sécurité non testé n’est qu’une intention.

Quand le chemin fonctionne, retirez le PAT du workflow puis révoquez-le dans Docker Hub. Le supprimer uniquement des secrets GitHub laisse un jeton valide qui pourrait avoir été copié ailleurs. Inspectez aussi les workflows réutilisables et les anciens runners.

Ce qu’OIDC ne corrige pas

Un workflow compromis sur une branche autorisée peut toujours publier une image malveillante. Protégez les fichiers .github/workflows, épinglez les actions tierces sur des versions fiables et limitez GITHUB_TOKEN. Signez les images et conservez les attestations de provenance lorsque la chaîne le permet.

La disponibilité commerciale peut enfin imposer de conserver temporairement des jetons sur certains projets. Dans ce cas, utilisez un jeton dédié à un dépôt, avec le minimum de droits et une rotation courte.

OIDC transforme l’authentification Docker en décision prise pour chaque job plutôt qu’en secret copié une fois. C’est une réduction de risque concrète, à condition que les règles de branche et d’environnement soient réellement restrictives.