JetBrains a annoncé la nouvelle extension OIDC JWT pour la plateforme TeamCity, destinée à permettre aux processus de build de s’authentifier auprès d’AWS, de Google Cloud et d’autres services prenant en charge OpenID Connect, sans dépendre de clés ou de mots de passe statiques dans l’environnement CI/CD. Cette extension vise à traiter l’une des sources de risques opérationnels et de sécurité des pipelines de build : les identifiants statiques peuvent être exposés dans les journaux ou les fichiers de build et nécessitent généralement une rotation périodique pour répondre aux exigences de sécurité.
Comment fonctionne l’authentification ?
Le flux repose sur l’émission par TeamCity d’un JSON Web Token signé cryptographiquement au nom du processus de build. Le jeton contient des revendications qui définissent l’identité de la charge de travail, sa période de validité, la partie destinataire et l’adresse de l’émetteur. À la réception du jeton, le service externe vérifie la signature à l’aide des clés publiques associées à l’émetteur, puis contrôle l’audience visée et la période de validité avant d’utiliser les revendications pour authentifier le processus de build.
Certains services acceptent directement le jeton du fournisseur d’identité, tandis que d’autres effectuent un échange de jetons afin d’émettre leurs propres identifiants temporaires. JetBrains laisse les détails de configuration de ce flux à chaque service et invite les utilisateurs à consulter la documentation d’AWS ou de Google Cloud lors de la configuration de l’audience et des conditions de vérification.
Qu’ajoute l’extension à TeamCity ?
OIDC JWT ajoute au serveur TeamCity les capacités de fournisseur d’identité nécessaires à l’émission des jetons. L’extension prend en charge la signature des jetons avec des algorithmes fondés sur RSA ou ECDSA, ainsi que la rotation des clés de signature depuis l’interface web ou via un point de terminaison HTTP dédié aux requêtes autorisées. Selon JetBrains, la rotation des clés ne désactive pas les processus de build en cours par défaut et n’invalide pas les jetons émis précédemment.
Pour les serveurs TeamCity accessibles au public, l’extension fournit le document .well-known/openid-configuration ainsi qu’un jeu de clés publiques JWKS. Pour les serveurs qui ne sont pas exposés sur Internet, il est possible de configurer une adresse d’émetteur personnalisée et d’héberger les documents de découverte sur un hôte public utilisant HTTPS, sans rendre le serveur TeamCity lui-même public. L’extension fournit également une API permettant à d’autres extensions d’ajouter de nouvelles méthodes de signature, notamment l’intégration avec des modules de sécurité matérielle HSM ou des services de gestion des clés tels que Google Cloud KMS.
Options d’émission des jetons et exigences d’utilisation
Après l’installation de l’extension depuis JetBrains Marketplace et son activation, elle peut être gérée depuis le chemin Admin | Integrations | OIDC Tokens. Elle nécessite Java 17 et prend en charge TeamCity 2025.11 ainsi que les versions ultérieures. L’administrateur peut définir l’adresse de l’émetteur, les paramètres de signature et gérer les clés de signature.
L’extension fournit deux fonctionnalités de build pour émettre des jetons. La première, OIDC Token (in build parameters), crée le jeton au démarrage du build et le stocke dans un paramètre de build spécifié. La durée de validité est configurable et correspond par défaut au délai d’expiration du build, ou à 10 minutes lorsqu’aucun délai n’est défini. Il est également possible d’émettre un jeton pour une ou plusieurs audiences, avec la possibilité d’ajouter une fonctionnalité distincte lorsque les services exigent des jetons indépendants pour une seule audience.
La fonctionnalité OIDC Token (on demand via HTTP request), quant à elle, convient aux processus de build de longue durée, car elle permet aux scripts de demander un jeton à courte durée de validité pendant l’exécution via HTTP. Ces jetons ont toujours une durée de validité de 5 minutes, qui ne peut pas être modifiée.
Pourquoi cette annonce est-elle importante ?
Le changement pratique consiste ici à faire passer l’authentification de secrets à longue durée de vie à des jetons associés au processus de build et limités dans le temps et à une audience donnée. Cela réduit la valeur du jeton en cas de fuite, mais n’élimine pas la nécessité de configurer les autorisations et de vérifier soigneusement l’adresse de l’émetteur et l’audience. JetBrains avertit que les modifications de la configuration de l’extension peuvent interrompre les intégrations existantes et recommande donc de la configurer avant de relier les processus de build à l’authentification via OIDC. En outre, l’efficacité de la solution dépend de la prise en charge d’OIDC par le service cible et de sa configuration officielle, des éléments qui doivent être vérifiés séparément pour chaque intégration.