2,000+ comptes de service sans propriétaire : le problème de l'IAM multicloud

Les grands environnements cloud produisent un type de panique bien à eux. Elle n'arrive pas le premier jour, ni même la première année. Elle arrive vers la troisième année, après la troisième acquisition et le cinquième cluster Kubernetes, quand quelqu'un demande : « Attendez… combien de comptes de service avons-nous exactement ? »

Dans ce cas, la réponse était 2,000+ identités machine réparties entre AWS, Azure et GCP. Aucun inventaire centralisé, aucune politique de rotation cohérente, juste un mélange de rôles IAM, de service principals, de workload identities et d'identités de pods Kubernetes. C'est une bombe à retardement pour la gouvernance, bien au-delà du « un peu en désordre ».

Et les contraintes sont brutales :

• Découverte automatisée des identités machine
• Rotation sans temps d'arrêt des applications
• Recommandations de moindre privilège fondées sur l'usage réel
• Intégration CI/CD (Jenkins, GitHub Actions)
• Architecture API-first
• Aucun agent
• Aucune modification de code
• Aucun projet expérimental de six mois

Le sujet porte aussi explicitement sur le cycle de vie des identités machine à grande échelle, le PAM pour les humains étant hors périmètre. La plupart des entreprises calent à ce stade sans le dire, ce qui justifie de regarder ce qui est réellement faisable.

Il n'existe pas de bouton magique unifié

Vous l'avez déjà constaté pendant vos évaluations. CyberArk est puissant et cher, et donne l'impression d'arriver avec un char d'assaut à une bagarre au couteau.

HashiCorp Vault est solide, mais il faut quelqu'un pour le faire tourner : clusters HA, backends de stockage, moteurs de secrets et dérive des politiques finissent par représenter le travail d'une équipe entière.

Les gestionnaires de secrets natifs du cloud comme AWS Secrets Manager et Azure Key Vault fonctionnent, mais ils sont fragmentés, et vous vous retrouvez à gérer trois plans de contrôle différents. C'est justement la fragmentation qui vous a menés là.

Le secteur n'a toujours pas produit de « gouverneur d'identités machine multicloud » propre et indépendant des éditeurs qui ne demande aucun effort d'exploitation. Alors, que font réellement les entreprises ? Elles règlent le problème par l'architecture, et aucun produit ne fait le travail à lui seul.

Le modèle qui s'impose : supprimer les identifiants statiques

Regardez le signal le plus fort de la discussion :

Workload identity + fédération pour les appels entre clouds. Évitez de stocker des clés ou des identifiants statiques.

C'est une stratégie plus qu'une recommandation de produit. Au lieu d'assurer la rotation de clés d'accès à longue durée de vie, de suivre la prolifération des secrets et de gérer le cycle de vie des mots de passe, les équipes éliminent carrément le problème.

Dans Kubernetes, cela passe en général par la fédération OIDC : les charges de travail endossent des rôles dynamiquement et échangent des jetons à courte durée de vie entre clouds. AWS le permet avec les rôles IAM pour comptes de service, GCP avec la workload identity federation, et Azure avec les identifiants fédérés pour les service principals.

Quand vous les reliez correctement, les pods ne stockent pas d'identifiants. Ils les demandent, les identifiants expirent, et ils se renouvellent automatiquement. Pas de temps d'arrêt lié à la rotation, pas d'agent, et pas de modification de code si vous utilisez déjà les fournisseurs d'identifiants par défaut des SDK. Voilà pourquoi cette approche passe à l'échelle.

Et la découverte, dans tout ça ?

C'est là que les choses deviennent concrètes. Vous n'avez pas d'inventaire centralisé, et avant d'optimiser la rotation, il vous faut de la visibilité. Les entreprises s'y prennent de trois façons principales.

1. Inventaire natif du cloud + agrégation

Récupérez les données d'identité depuis AWS IAM, Azure Entra ID, GCP IAM et l'API Kubernetes, puis versez-les dans une plateforme de données centrale (même quelque chose d'aussi simple que des exports planifiés vers un entrepôt de données).

C'est peu glorieux, mais vous obtenez une liste des identités machine, des liaisons de rôles, des horodatages de dernière utilisation et des politiques attachées, sur laquelle vous pouvez bâtir des recommandations de moindre privilège. Ce n'est pas clé en main, mais cela reste plus rapide que de déployer une énorme plateforme PAM.

2. Policy-as-code + surveillance de la dérive

Les entreprises qui misent sur des modèles API-first traitent l'IAM comme de l'infrastructure. État Terraform + journaux cloud + métriques d'utilisation = carte des permissions effectives.

À partir de là, vous pouvez repérer les actions inutilisées, détecter les rôles trop privilégiés et ouvrir automatiquement des pull requests avec des politiques réduites. L'automatisation reste partielle, mais cela passe mieux à l'échelle qu'une revue manuelle, et cela respecte votre exigence « API-first ».

3. Outils de graphe d'identités (catégorie émergente)

Une nouvelle famille d'outils construit des graphes d'identités entre clouds. Ils ingèrent les attributions de rôles, les politiques de confiance, les relations de fédération et la télémétrie d'usage, puis font ressortir les privilèges excessifs, les erreurs de configuration de confiance entre clouds et les comptes de service dormants.

Ils sont plus légers que les suites PAM complètes et souvent sans agent. La contrepartie, c'est qu'ils servent d'abord à la visibilité sur la gouvernance, l'automatisation du cycle de vie passant parfois au second plan.

Pourquoi Vault paraît lourd (et pourquoi il l'emporte parfois quand même)

On écarte Vault au motif de sa « charge d'exploitation », et elle est bien réelle. Certaines entreprises le choisissent pourtant, attirées par les identifiants dynamiques plus que par le stockage de secrets.

Vault peut générer des identifiants de base de données à courte durée de vie, émettre des jetons d'accès cloud temporaires et imposer des politiques de TTL et de renouvellement. Si vous êtes prêt à le faire tourner correctement, il devient un courtier d'identités machine.

C'est toutefois un engagement, et si vous n'avez pas le personnel pour, ça fera mal. La ligne de partage tient à votre envie d'y affecter des gens, bien plus qu'à une liste de fonctionnalités.

La réalité de l'intégration CI/CD

Il vous faut une intégration avec Jenkins et GitHub Actions. La plupart des entreprises s'en sortent en utilisant la fédération OIDC de GitHub Actions vers les rôles cloud, en laissant Jenkins endosser dynamiquement des rôles cloud et en supprimant complètement les identifiants CI statiques.

Cela réduit le risque de fuite d'identifiants, les cycles de rotation manuelle et la prolifération des secrets dans les pipelines. Cela respecte aussi votre contrainte « aucune modification de code », puisque les SDK modernes prennent déjà en charge l'injection de jetons par l'environnement.

Ce que les entreprises déploient vraiment en 2026

La réponse honnête est une combinaison :

1. La workload identity federation partout où c'est possible
2. Des identifiants à courte durée de vie plutôt que la rotation
3. Un reporting centralisé de l'inventaire des identités
4. Des outils d'analyse des politiques
5. Des gestionnaires de secrets minimaux, uniquement là où la fédération est impossible

Elles n'unifient pas tout sous une méga-plateforme, elles standardisent des modèles. La question à laquelle elles répondent est « comment éliminer les identifiants machine statiques », et le choix d'un éditeur vient après.

Ce qu'il vaut sans doute mieux éviter

À éviter :

• Vouloir centraliser tous les secrets dans un seul coffre en six mois
• Forcer les applications à changer de mode d'authentification
• Déployer des agents sur 2,000 charges de travail
• Tenter d'ajuster à la main chaque politique IAM

C'est comme ça que les calendriers explosent. Vos contraintes sont claires, l'architecture doit donc les respecter.

Si c'était mon environnement

Avec 2,000+ comptes de service sur trois clouds, mes priorités seraient :

Phase 1 (90 jours) :

• Inventorier les identités machine sur tous les clouds
• Activer la workload identity federation pour les nouvelles charges de travail
• Retirer les nouveaux identifiants statiques de la CI/CD

Phase 2 (les 90 jours suivants) :

• Remplacer les clés à longue durée de vie par des jetons fédérés là où c'est possible
• Introduire un élagage des politiques fondé sur l'usage
• Construire des tableaux de bord sur la propriété des identités

Phase 3 :

• Évaluer si une plateforme légère de gouvernance des identités apporte quelque chose

Vous remarquerez qu'il n'y a aucun déploiement de plateforme géante là-dedans. Votre véritable ennemi est la prolifération, bien plus qu'un manque d'outils.

La conclusion qui dérange

La gouvernance des identités machine en multicloud est un problème d'architecture, et acheter un produit ne le réglera pas. Les entreprises qui s'en sortent :

• Cessent d'assurer la rotation des secrets et commencent à les éliminer
• Cessent de centraliser à la main et commencent à fédérer automatiquement
• Cessent de penser « tout mettre dans un coffre » et commencent à penser « échange de confiance »

Une meilleure rotation des mots de passe compte moins que le fait d'en avoir moins au départ. Les équipes qui l'intègrent tôt sont celles qui cessent de se réveiller à 3 heures du matin en se demandant quel compte de service oublié a encore un accès admin à la production.