Passkeys en CI/CD : où automatiser sans casser la sécu

Les passkeys ne sont plus seulement un sujet grand public lié à la connexion sans mot de passe. Depuis quelque temps, elles remontent aussi dans les discussions autour des outils d’entreprise, des consoles cloud, des plateformes Git et des workflows d’administration. Côté DevOps, la question arrive vite de manière très concrète : est-ce qu’on peut intégrer des passkeys, du WebAuthn ou une forme de MFA moderne dans une chaîne CI/CD sans transformer chaque déploiement en impasse opérationnelle ?

La réponse courte est simple : oui, mais pas partout. Et surtout pas de la manière souvent suggérée par les discours marketing. Une passkey est excellente pour authentifier un humain vers une interface ou une action sensible. Elle est beaucoup moins adaptée à un job non interactif qui tourne à 3 heures du matin sur un runner éphémère. En pratique, l’enjeu n’est pas de “mettre des passkeys dans le pipeline”, mais de décider précisément où une preuve forte doit rester humaine et où l’automatisation doit reposer sur des identités machine conçues pour ça.

Dans cet article, on va séparer les cas d’usage réalistes des promesses floues : pourquoi les passkeys remontent dans les chaînes DevOps, ce qui peut réellement être automatisé, les patterns qui tiennent sur le terrain, et un plan d’adoption progressif pour ne pas casser des déploiements existants.

Pourquoi les passkeys remontent dans les chaînes DevOps

Le sujet remonte pour plusieurs raisons techniques et organisationnelles. D’abord, les plateformes critiques utilisées par les équipes DevOps renforcent progressivement l’authentification des comptes humains : SSO, MFA, WebAuthn, clés de sécurité matérielles, politiques d’accès conditionnel. Ensuite, la pression de conformité et de réduction du risque pousse à supprimer les mots de passe réutilisés, les comptes partagés et les accès persistants trop larges.

Dans ce contexte, les passkeys s’inscrivent dans l’écosystème WebAuthn et des standards portés notamment par la FIDO Alliance. Elles améliorent l’authentification des utilisateurs en s’appuyant sur de la cryptographie asymétrique et sur le déverrouillage local d’un appareil. Pour un administrateur qui se connecte à GitHub, GitLab, Google Cloud, Microsoft Entra ID, AWS IAM Identity Center ou à un portail interne, c’est une avancée réelle.

Mais en CI/CD, les accès ne sont pas tous du même type. On mélange souvent trois familles très différentes :

L’authentification humaine interactive vers une console, un portail, un bastion ou un outil d’administration.
L’authentification machine-to-machine entre un runner CI, un orchestrateur, un registre d’images, un cloud provider ou une API.
Les approbations humaines au milieu d’un flux automatisé, par exemple avant une mise en production.

Les passkeys répondent très bien au premier cas, parfois au troisième, et beaucoup moins au deuxième. C’est là que les confusions commencent. Un pipeline n’est pas un utilisateur. Un runner éphémère n’a ni biométrie, ni présence utilisateur, ni geste d’approbation local. Vouloir lui faire “utiliser une passkey” comme un humain revient souvent à forcer un mauvais modèle d’identité.

Passkeys, WebAuthn, MFA : remettre les termes au bon endroit

Avant de parler architecture, il faut clarifier les mots. WebAuthn est une API et un standard d’authentification pour le web. Une passkey est une implémentation orientée usage de ces mécanismes, généralement synchronisée entre appareils ou stockée localement selon les plateformes. Une clé de sécurité matérielle de type YubiKey peut aussi servir avec WebAuthn, mais ce n’est pas synonyme de passkey synchronisée.

Autre point important : le terme MFA est souvent utilisé de façon trop large. Dans les workflows DevOps, il faut distinguer :

le MFA pour un compte humain, avec présence utilisateur et éventuellement vérification locale ;
les garanties fortes pour les identités machine, qui passent plutôt par des jetons courts, de la fédération d’identité, de l’attestation de workload, de l’OIDC ou des certificats.

Par exemple, les grands systèmes CI modernes savent déjà échanger une identité de job contre des credentials temporaires sans stocker de secret long terme. C’est le cas de l’OIDC de GitHub Actions, de la fédération OIDC dans GitLab CI/CD ou des mécanismes équivalents côté cloud provider. Ce n’est pas une passkey, mais c’est souvent la bonne réponse sécurité pour un pipeline.

Le bon réflexe n’est pas de demander “comment mettre du WebAuthn dans mon job CI ?”, mais “quelle preuve d’identité convient à ce type d’acteur : humain, service ou exécution éphémère ?”

Ce qui peut vraiment être automatisé en CI/CD

Dans une chaîne CI/CD, certaines briques se prêtent très bien à une automatisation forte sans secret statique. C’est là qu’il faut concentrer l’effort, bien plus que sur une transposition artificielle des passkeys vers les jobs.

Fédération d’identité pour obtenir des credentials courts

Le pattern le plus propre consiste à faire porter au pipeline une identité vérifiable, puis à l’échanger contre des droits temporaires. Concrètement, un job GitHub Actions ou GitLab CI peut présenter un jeton OIDC signé, et le cloud provider émet ensuite des credentials limités dans le temps et dans le périmètre.

Ce modèle apporte plusieurs bénéfices très concrets :

pas de clé cloud longue durée stockée dans les variables CI ;
périmètre d’accès plus fin par dépôt, branche, environnement ou workflow ;
rotation implicite, puisque les credentials expirent vite ;
meilleure traçabilité de l’origine d’une action.

Chez AWS, ce pattern passe généralement par IAM et un fournisseur OIDC. Chez Google Cloud, on parle de Workload Identity Federation. Chez Microsoft, on retrouve des approches de fédération pour les workloads via Microsoft Entra Workload ID.

Secrets éphémères et accès just-in-time

Quand un pipeline doit parler à une base, un registre, un cluster ou un service interne, l’objectif est le même : éviter les secrets persistants copiés partout. Des outils comme HashiCorp Vault permettent d’émettre des credentials dynamiques selon une politique donnée. Kubernetes peut aussi s’appuyer sur des mécanismes natifs ou sur des opérateurs dédiés pour limiter la durée de vie et la diffusion des secrets.

Ce modèle est automatisable parce qu’il est pensé pour des workloads. On ne demande pas au job de “prouver sa présence” comme un utilisateur ; on lui donne une identité technique vérifiable et des droits minimaux, temporaires et auditables.

Signatures et attestations non interactives

Un autre pan automatisable concerne l’intégrité des artefacts. La signature d’images, de paquets ou de provenance peut être intégrée dans le pipeline avec des mécanismes adaptés au non interactif. Des outils comme Sigstore et Cosign ont précisément émergé pour répondre à ce besoin dans les chaînes logicielles modernes.

Ici encore, on est dans une logique d’identité de workload et de confiance sur l’exécution, pas dans une logique de passkey utilisateur.

Ce qui doit rester humain, même dans une chaîne très automatisée

À l’inverse, certains points d’un workflow gagnent à rester explicitement humains, avec authentification forte. C’est souvent là que les passkeys ont le plus de valeur côté DevOps.

Accès aux consoles d’administration

L’accès à la console d’un fournisseur cloud, à l’interface d’un gestionnaire de secrets, à un portail d’observabilité ou à l’administration d’une forge logicielle doit rester protégé par une authentification forte pour les comptes humains. Dans ce contexte, les passkeys améliorent à la fois l’expérience et la sécurité par rapport aux mots de passe seuls ou aux OTP faibles.

Pour un administrateur de GitHub Enterprise, GitLab, AWS, Google Cloud, Grafana, Datadog ou Vault, l’usage de WebAuthn ou de clés de sécurité matérielles est cohérent. Ce sont des actions interactives, sensibles, et souvent peu fréquentes.

Approbations de production et break-glass

Les mises en production critiques, les changements de politique IAM, l’ouverture d’un accès réseau, la rotation d’une clé racine ou l’usage d’un compte de secours sont de bons candidats à une étape humaine. Beaucoup d’outils CI/CD permettent des approbations manuelles ou des environnements protégés. Dans ce cas, demander à l’approbateur de s’authentifier via SSO fort, WebAuthn ou clé matérielle a du sens.

Le point important est de ne pas confondre l’étape d’approbation avec l’exécution du déploiement. L’humain approuve, la machine exécute. Si on mélange les deux, on finit souvent avec des contournements : comptes partagés, jetons copiés à la main, sessions persistantes, ou pire, désactivation temporaire des contrôles pour “faire passer la prod”.

Opérations exceptionnelles à fort impact

Un accès break-glass à un cluster, à un coffre de secrets ou à une base de production doit suivre une politique différente d’un déploiement standard. Ici, il est légitime d’exiger une présence utilisateur, une justification, une traçabilité et des journaux d’audit. Les passkeys peuvent renforcer cette couche, mais elles ne remplacent ni la séparation des rôles ni les procédures d’urgence.

Patterns concrets côté runners, comptes de service et environnements

Sur le terrain, les équipes avancent rarement avec un “grand soir” de l’authentification. Elles mettent en place des patterns robustes, compatibles avec l’existant, puis réduisent progressivement les secrets persistants.

Pattern 1 : runner éphémère + OIDC + rôle minimal

C’est souvent le meilleur point de départ. Le runner est créé à la demande, exécute un job, récupère un jeton d’identité du système CI, l’échange contre des credentials temporaires, puis disparaît. On limite ainsi le risque de persistance locale, de fuite de secret et de réutilisation d’un environnement compromis.

Ce pattern est particulièrement adapté pour :

publier une image dans un registre ;
déployer sur un cluster Kubernetes ;
appliquer une infrastructure as code avec Terraform ou OpenTofu ;
lancer des scans ou des signatures d’artefacts.

Il demande en revanche un vrai travail de cadrage IAM : conditions sur le dépôt, la branche, le tag, l’environnement, et séparation claire entre staging et production.

Pattern 2 : compte de service dédié par usage, pas par équipe

Un piège fréquent consiste à créer un seul compte de service “ci-prod” utilisé par tous les projets. C’est pratique au début, puis ingérable. Mieux vaut découper par usage ou par domaine de responsabilité : publication d’artefacts, déploiement applicatif, migrations, accès lecture à un registre, etc.

Ce découpage apporte plusieurs avantages :

droits plus petits et plus lisibles ;
révocation ciblée en cas d’incident ;
audit plus simple ;
moindre blast radius si un workflow est compromis.

Les passkeys n’ont pas de rôle direct ici. Ce qui compte, c’est la qualité du modèle d’identité machine.

Pattern 3 : approbation forte sur l’environnement, pas dans le script

Quand une validation humaine est nécessaire, il vaut mieux la porter au niveau de la plateforme : environnement protégé, règle de déploiement, politique de changement, workflow d’approbation. Il faut éviter les bricolages dans les scripts shell ou les demandes d’OTP saisies à la main dans un terminal.

Par exemple, un environnement de production peut exiger un ou plusieurs approbateurs identifiés via le SSO d’entreprise. Une fois l’approbation donnée, le job de déploiement reçoit seulement les permissions nécessaires pour cette cible. On garde ainsi une séparation nette entre identité humaine et identité machine.

Pattern 4 : secrets courts pour les systèmes qui ne savent pas fédérer

Tout l’écosystème n’est pas encore compatible OIDC ou fédération moderne. Dans ce cas, le compromis réaliste consiste à générer des secrets à durée de vie courte, à usage restreint, idéalement depuis un broker ou un coffre. Ce n’est pas aussi propre qu’une fédération native, mais c’est déjà bien meilleur qu’un token statique valable des mois.

Ce pattern est fréquent avec des outils legacy, des appliances, certains serveurs SFTP, ou des APIs internes anciennes. L’objectif reste le même : réduire la durée de vie, limiter le périmètre, journaliser l’usage.

Les limites pratiques des passkeys en automatisation

Le discours marketing laisse parfois croire qu’une passkey pourrait remplacer tout type d’authentification, y compris pour les machines. Sur le terrain, plusieurs limites apparaissent vite.

Une passkey suppose généralement un contexte utilisateur

Le modèle WebAuthn est conçu autour d’un utilisateur, d’un appareil, d’un navigateur ou d’un client compatible, et souvent d’un geste local. Ce n’est pas le modèle naturel d’un runner headless ou d’un job batch.

On peut toujours imaginer des montages spécifiques, mais ils deviennent vite fragiles : dépendance à un poste utilisateur, à un agent local, à un périphérique branché, à une session interactive, ou à un composant de bureau impossible à reproduire proprement en exécution serveur.

Le partage et la récupération sont délicats

Un pipeline doit être reproductible, opérable et transmissible. Si son authentification dépend de la passkey d’une personne, on crée un point de blocage évident : absence, départ, changement d’appareil, perte du facteur, ou impossibilité d’exécuter une opération critique en dehors des heures ouvrées.

C’est acceptable pour une approbation ponctuelle. Ce ne l’est pas pour une authentification machine continue.

Le risque de faux sentiment de sécurité

Remplacer un mot de passe par une passkey sur un compte humain améliore la sécurité de ce compte. Mais si le pipeline continue à utiliser un token d’API très large, stocké en variable CI et partagé entre plusieurs projets, le risque principal n’a pas disparu. On a sécurisé la porte d’entrée d’un administrateur, pas l’identité des workloads.

Autrement dit, les passkeys ne compensent pas un mauvais design des comptes de service.

Plan d’adoption pragmatique sans casser les déploiements existants

Pour une équipe qui gère déjà des pipelines en production, la bonne stratégie n’est pas de tout réécrire autour de WebAuthn. Il faut avancer par couches, en commençant par ce qui réduit le plus le risque avec le moins de friction.

1. Cartographier les accès du pipeline

Listez les interactions réelles : registre, cloud, cluster, base, coffre de secrets, API interne, serveur de transfert, outil d’observabilité. Pour chaque accès, identifiez :

qui agit : humain ou machine ;
si l’action est interactive ou non ;
la durée de vie du credential ;
le niveau de criticité ;
la possibilité de remplacer un secret statique par de la fédération ou du dynamique.

Cette étape révèle souvent des anomalies simples : un token admin utilisé pour publier une image, une clé cloud commune à plusieurs dépôts, un secret copié entre CI et scripts locaux, ou un accès production utilisé aussi en préproduction.

2. Sécuriser d’abord les comptes humains

Activez l’authentification forte sur les consoles, les forges, les gestionnaires de secrets et les accès d’administration. Si votre fournisseur d’identité supporte les passkeys ou WebAuthn, c’est un excellent usage. C’est aussi le bon moment pour supprimer les comptes partagés et imposer le SSO quand c’est possible.

Le bénéfice est immédiat sans toucher au cœur des pipelines.

3. Remplacer les secrets longs par de l’identité fédérée là où c’est possible

Commencez par les flux les plus sensibles et les mieux supportés par l’écosystème : accès cloud depuis GitHub Actions ou GitLab CI, publication d’artefacts, déploiements Kubernetes, Terraform/OpenTofu. Le gain est généralement net et rapide.

Si vous avez déjà des articles internes ou des pratiques autour de la réduction des erreurs humaines et de la supervision bout en bout, ce chantier s’intègre naturellement dans une démarche plus large de fiabilisation des pipelines.

4. Isoler les exceptions legacy

Tout ce qui ne peut pas encore passer en fédération doit être explicitement identifié comme exception. Pour ces cas, appliquez des garde-fous : secret court, rotation, coffre centralisé, journalisation, périmètre minimal, et plan de remplacement. Le danger vient souvent des exceptions invisibles qui durent des années.

5. Introduire des approbations fortes uniquement aux bons endroits

Ajoutez des validations humaines sur les changements à fort impact : production, IAM, réseau, données sensibles, break-glass. Connectez ces étapes au SSO et à une authentification forte. Évitez d’en mettre partout, sinon les équipes chercheront à les contourner.

Une approbation utile est rare, explicite et liée à un vrai niveau de risque.

6. Mesurer la friction opérationnelle

Un bon design sécurité en CI/CD ne se juge pas seulement sur le papier. Il faut observer :

le temps perdu en déblocage d’accès ;
les incidents liés aux secrets expirés ou aux rôles trop larges ;
les déploiements retardés par des validations mal placées ;
les contournements apparus dans les équipes.

Si les gens stockent des tokens ailleurs “pour aller plus vite”, c’est que le modèle ne colle pas encore au terrain.

Ce qu’il faut retenir pour 2026 côté DevOps

En 2026, on verra probablement davantage de passkeys dans les outils utilisés par les équipes techniques, mais cela ne veut pas dire que les pipelines eux-mêmes deviendront des utilisateurs WebAuthn. La trajectoire la plus réaliste est plutôt la suivante :

des comptes humains mieux protégés par passkeys, clés de sécurité et SSO fort ;
des workloads authentifiés par fédération d’identité, jetons courts, certificats ou attestations ;
des approbations humaines plus ciblées sur les changements à fort impact ;
moins de secrets statiques, moins de comptes partagés, moins d’accès persistants.

C’est moins spectaculaire qu’un slogan “passwordless everywhere”, mais c’est beaucoup plus solide. Et surtout, c’est compatible avec l’objectif principal d’une chaîne CI/CD : livrer de façon fiable sans transformer chaque contrôle de sécurité en panne de production potentielle.

Conclusion

Les passkeys ont une vraie place dans l’écosystème DevOps, mais pas comme réponse universelle. Elles sont excellentes pour les humains : accès aux consoles, approbations sensibles, opérations d’administration. Pour les machines, la bonne direction reste l’identité fédérée, les secrets courts et les comptes de service strictement bornés.

Si vous devez faire évoluer vos pipelines, commencez par une question simple : quelle identité agit ici, et de quel type de preuve a-t-elle réellement besoin ? C’est ce cadrage, bien plus que le buzz autour de WebAuthn, qui évite de casser la sécurité ou les déploiements. Et si vous voulez aller plus loin sur les compromis concrets d’automatisation et de fiabilisation, le reste des contenus de Pipeline Brut suit exactement cette ligne : moins de promesses, plus de terrain.