Contexte et besoin de sécurité
Dans les pipelines DevOps, les clés d’API persistantes représentent une surface d’attaque importante. Elles sont souvent stockées dans des variables d’environnement ou des coffres secrets, ce qui augmente le risque de fuite ou d’utilisation non autorisée. L’OpenID Connect (OIDC) offre une alternative : des jetons d’identité temporaires qui peuvent être validés par le fournisseur d’identité sans exposer de secrets permanents. Cependant, la plupart des implémentations actuelles génèrent des jetons valables plusieurs heures, limitant l’avantage de rotation fréquente.
Mécanisme de génération OIDC dans Pulumi ESC
Pulumi ESC (Escrow) introduit le nouveau fournisseur fn::open::oidc. Ce composant crée des jetons OIDC dont la durée de vie est plafonnée à une heure. La génération s’effectue à la volée, directement depuis le moteur d’infrastructure, sans nécessiter de service externe supplémentaire. Le processus consiste à signer le jeton avec la clé privée du projet Pulumi, à inclure les revendications standards (iss, sub, aud, exp) et à le renvoyer au consommateur. Parce que le jeton est éphémère, aucune donnée d’identification permanente n’est conservée dans le code ou les fichiers de configuration.
Utilisation pratique et services compatibles
Les jetons produits par fn::open::oidc peuvent être présentés à tout service acceptant OIDC, notamment les API d’Anthropic, Cloudsmith, JFrog Artifactory et Aembit. L’intégration se fait via les fournisseurs natifs de ces services : le développeur indique simplement le provider OIDC dans la définition Pulumi, et le moteur injecte le jeton au moment de l’appel. Cette approche supprime le besoin de stocker des clés API statiques dans les dépôts de code, réduisant ainsi le vecteur d’attaque lié aux fuites de secrets.
Implications et limites
En limitant la validité à une heure, Pulumi ESC élimine la plupart des scénarios d’exploitation de clés compromises : même si un jeton était intercepté, il deviendrait rapidement inutilisable. La contrainte principale réside dans la synchronisation des horloges entre le serveur Pulumi et les services consommateurs ; un décalage supérieur à quelques minutes peut entraîner des rejets d’authentification. De plus, l’absence de mécanisme de révocation immédiate signifie que la mitigation repose uniquement sur l’expiration temporelle. Enfin, la fonctionnalité est déjà déployée dans toutes les organisations Pulumi Cloud, ce qui garantit une disponibilité immédiate pour les équipes CI/CD cherchant à renforcer leur posture de sécurité.