Mettre en place la fédération d’identité de charge

Une charge de travail cloud-native ne devrait jamais embarquer une clé d’accès durable pour joindre un service cloud. La fédération d’identité remplace ce secret copié dans une variable d’environnement par un jeton temporaire, vérifié contre une relation de confiance entre l’exécuteur et le fournisseur cloud.

→ Lire l’explication complète de la marmotte

Jeton fédéré, identifiant cloud et relation de confiance

La fédération d’identité de charge de travail consiste à faire reconnaître une identité native d’exécution par un fournisseur cloud. Dans Kubernetes, cette identité provient généralement du compte de service attaché au pod. Dans une plateforme de fonctions, elle provient de l’identité d’exécution attribuée par la plateforme. Cette identité est matérialisée par un JSON Web Token (JWT), signé par un émetteur connu.

Le fournisseur cloud ne fait pas confiance à n’importe quel JWT tombé d’Internet, fort heureusement. Il vérifie une relation préconfigurée qui associe un émetteur, une audience et des revendications précises à une identité cloud autorisée. Une revendication est une propriété signée du jeton, par exemple le nom du compte de service Kubernetes, son espace de noms, ou l’identité d’une fonction.

Le mécanisme suit une séparation nette :

l’environnement d’exécution émet ou expose un jeton d’identité ;
la charge de travail présente ce jeton à un service d’échange ;
le fournisseur vérifie signature, émetteur, audience et revendications ;
il délivre des identifiants cloud temporaires, limités par un rôle ou une politique ;
le SDK (Software Development Kit) cloud renouvelle ces identifiants avant expiration.

Amazon Web Services propose ce modèle avec OpenID Connect (OIDC) et le service AWS Security Token Service (STS). Google Cloud exploite Workload Identity Federation ou Workload Identity pour Kubernetes. Microsoft Azure associe une identité managée ou une fédération d’identifiants à Microsoft Entra ID. Les noms changent, les conditions de confiance aussi, mais la propriété de sécurité visée reste identique : aucune clé longue durée n’est remise au processus.

Le compromis central est brutal : on gagne la disparition d’un secret statique exploitable longtemps, on paie une configuration de confiance plus exigeante et une dépendance au chemin d’émission de jetons. Ce paiement est obligatoire pour toute charge de travail déployée en production sur une plateforme compatible. Conserver une clé d’accès parce que la fédération comporte quatre ressources à déclarer revient à préférer un extincteur percé parce qu’il tient mieux dans le placard.

La fédération ne remplace pas la gouvernance IAM. Elle fournit une authentification de charge de travail. Les autorisations restent portées par des rôles, des politiques et des conditions. Un pod correctement fédéré avec un rôle pouvant lire tous les secrets, supprimer tous les buckets et administrer le réseau reste une catastrophe authentifiée.

Prérequis de plateforme et configuration de confiance

Dans Kubernetes, le cluster doit exposer un émetteur OIDC stable, accessible au fournisseur cloud et publié avec ses clés publiques de signature. Un jeton signé par un émetteur interne non joignable ne peut pas être vérifié par un service cloud externe. Exposer cet émetteur ne veut pas dire exposer l’interface de contrôle du cluster. Seuls les documents OIDC publics et le jeu de clés JSON Web Key Set (JWKS) doivent être accessibles.

Kubernetes doit être configuré pour projeter des jetons de compte de service avec audience et durée de vie bornées. Les anciens jetons montés automatiquement, non liés à une audience et valables jusqu’à révocation, constituent une dette de sécurité particulièrement collante. La version exacte dépend de la distribution, mais la projection de jetons bornés et l’émetteur OIDC doivent être validés avant toute conception de rôle cloud.

La relation de confiance doit contraindre au minimum :

l’émetteur exact du jeton ;
l’audience attendue par le fournisseur ;
l’identité précise du compte de service ;
l’espace de noms Kubernetes attendu ;
le rôle cloud cible ;
les actions et ressources autorisées par ce rôle.

Ne limiter que l’émetteur revient à autoriser tout compte de service du cluster à tenter l’échange. Ne limiter que le nom du compte de service permet parfois à un espace de noms homonyme d’obtenir le même privilège. Les revendications sont des frontières d’autorisation, pas des métadonnées décoratives ajoutées pour satisfaire une console cloud au design expérimental.

L’identité de charge de travail doit être séparée par application et par niveau de sensibilité. Un compte de service unique pour tous les pods d’un espace de noms facilite la première démonstration et détruit l’isolation dès le premier déploiement. Créer un rôle par microservice et par permission métier paraît fastidieux jusqu’au jour où il faut retirer l’accès d’un seul composant sans interrompre les autres.

La relation avec les métadonnées d’instance mérite une attention particulière. Sur certaines plateformes, une charge de travail peut encore interroger un service de métadonnées pour récupérer les identifiants du nœud ou de l’instance. Cette voie contourne l’identité applicative et étend les privilèges du nœud à chaque pod compromis. Les attaques par falsification de requête côté serveur sont précisément conçues pour atteindre ce type de cible. La page sur les SSRF vers les métadonnées cloud détaille ce chemin d’attaque, qui ne disparaît pas par incantation agile.

Exemple Kubernetes avec OIDC et rôle cloud

L’exemple suivant montre le principe pour un cluster Kubernetes déjà relié à un fournisseur OIDC et un rôle cloud déjà limité à la lecture d’un préfixe de stockage. Les identifiants de tenant, de compte et de rôle restent propres à chaque environnement, mais aucune clé d’accès n’est injectée dans le manifeste.

# ServiceAccount dédié à une seule application.
# L'annotation associe cette identité Kubernetes au rôle cloud préconfiguré.
apiVersion: v1
kind: ServiceAccount
metadata:
  name: lecteur-archives
  namespace: facturation
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/lecture-archives
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: archivage
  namespace: facturation
spec:
  replicas: 2
  selector:
    matchLabels:
      app: archivage
  template:
    metadata:
      labels:
        app: archivage
    spec:
      serviceAccountName: lecteur-archives
      containers:
        - name: worker
          image: public.ecr.aws/docker/library/alpine:3.20
          command: ["sh", "-c", "sleep 3600"]
          env:
            # Le SDK utilise ces variables et le jeton projeté, pas une clé statique.
            - name: AWS_ROLE_ARN
              value: arn:aws:iam::123456789012:role/lecture-archives
            - name: AWS_WEB_IDENTITY_TOKEN_FILE
              value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token

Le manifeste ne suffit pas. Le rôle cloud doit contenir une politique de confiance vérifiant au moins sub (subject, sujet), avec une valeur égale à system:serviceaccount:facturation:lecteur-archives, et aud (audience), avec la valeur attendue par le service d’échange. La politique de permissions doit ensuite restreindre les opérations, par exemple GetObject sur un préfixe précis, sans lister ou effacer le reste du stockage.

Tester l’identité depuis le pod doit confirmer le rôle effectif, pas seulement la présence d’un fichier de jeton. Un conteneur peut obtenir un JWT valide et être refusé lors de l’échange à cause d’une audience incorrecte, d’un certificat d’émetteur inaccessible ou d’une condition de confiance trop stricte. C’est le comportement attendu : un refus précoce vaut mieux qu’un accès hérité du nœud.

Surface d’attaque et limites de la fédération

Un jeton fédéré est un objet porteur. Celui qui le vole avant son expiration peut généralement l’échanger ou l’utiliser selon son audience. La courte durée réduit la fenêtre d’exploitation, elle ne transforme pas un processus compromis en organisme moralement irréprochable. Isoler les workloads, réduire les capacités Linux, protéger l’accès aux volumes projetés et empêcher l’exécution arbitraire restent nécessaires.

La validation doit fixer les algorithmes cryptographiques acceptés et vérifier signature, émetteur, audience, dates exp (expiration) et nbf (not before, pas avant). Accepter l’algorithme annoncé par le jeton permet des confusions de signature. Accepter une audience générique permet le rejeu d’un jeton conçu pour un autre service. Ces erreurs sont documentées depuis longtemps, ce qui n’empêche pas certains logiciels de les redécouvrir avec la régularité d’un pigeon sur une statue.

La compromission de l’autorité qui signe les jetons du cluster est plus grave qu’une fuite isolée de clé applicative : elle peut permettre de fabriquer des identités fédérées. Les clés de signature de l’émetteur OIDC doivent donc être protégées, rotées avec chevauchement de clés publiques, sauvegardées selon le modèle de contrôle du cluster et surveillées. Une rotation qui retire immédiatement l’ancienne clé casse les jetons encore légitimes. Une rotation qui conserve indéfiniment toutes les anciennes clés transforme le jeu de clés en cimetière cryptographique.

La fédération ne garantit pas :

que le code exécuté dans le pod est digne de confiance ;
que le rôle attribué respecte le moindre privilège ;
que les appels cloud sont autorisés depuis le réseau attendu ;
que les données consultées sont chiffrées ou correctement classifiées ;
que les journaux permettent d’attribuer un acte à une personne.

Elle ne remplace ni segmentation réseau, ni admission Kubernetes, ni signature d’images, ni revue des politiques. Les frontières entre identité de charge et identité humaine doivent aussi rester visibles : un développeur ne doit pas récupérer les privilèges d’une application parce qu’un dépannage s’éternise. La gestion des identités reste un domaine à part entière, détaillé dans la section identités.

Exploitation, rotation et reprise après incident

Les identifiants temporaires doivent durer assez peu pour limiter un vol, assez longtemps pour tolérer les redémarrages et les incidents de contrôle. Une durée comprise entre quinze minutes et une heure convient souvent aux appels machine-à-machine. Une durée de quelques minutes peut provoquer des échecs en cascade si le SDK renouvelle tardivement ou si le fournisseur connaît une indisponibilité transitoire. La durée n’est pas un concours de pureté : elle doit être compatible avec la disponibilité attendue.

Superviser quatre signaux est indispensable : échecs d’échange de jetons, refus de politique de confiance, utilisation de rôles depuis des identités inattendues, et appels aux services de métadonnées depuis des workloads qui ne devraient pas y accéder. Les journaux cloud doivent conserver le sujet fédéré, le rôle obtenu, l’action, la ressource et la source réseau lorsque le fournisseur l’expose. Sans ces champs, un incident se résume vite à contempler un identifiant de rôle très occupé.

La révocation n’agit pas rétroactivement sur les identifiants déjà délivrés. Retirer la relation de confiance bloque les prochains échanges, mais les sessions temporaires vivent jusqu’à leur expiration. En cas de compromission, supprimer ou durcir la confiance, réduire les permissions du rôle, arrêter les workloads concernés et examiner les journaux dans la fenêtre maximale de validité sont des actions distinctes. Oublier la session existante est le genre de détail qui fait survivre un incident après sa prétendue fermeture.

Les sauvegardes doivent couvrir la configuration déclarative : fournisseur OIDC, politiques de confiance, rôles, associations de comptes de service et paramètres d’audience. Sauvegarder seulement les manifests Kubernetes ne restaure pas le côté cloud. Sauvegarder seulement les rôles cloud ne restaure pas l’émetteur ni ses clés. La reprise exige les deux moitiés de la confiance, sinon la charge de travail revient vivante mais muette.

🐝 Ce qui arrive si on s’en passe

Sans fédération, l’accès cloud repose sur une clé longue durée stockée dans un secret, une variable d’environnement ou une image. Cette clé se retrouve dans les couches d’images publiées, les dumps de configuration, les journaux d’application qui impriment l’environnement au démarrage et les sauvegardes de manifestes, autant de copies qui survivent au conteneur qui les portait. Elle ne porte aucune indication d’origine : un appel cloud effectué avec cette clé ne distingue pas le pod légitime d’un poste de développement, ce qui rend l’attribution impossible et transforme toute rotation en opération de coupure, puisqu’il faut redéployer chaque consommateur pour remplacer le secret. Faute de date d’expiration, la fenêtre d’exploitation n’est bornée que par la découverte de la fuite, souvent tardive, et rien dans les journaux ne signale le moment où la clé a changé de mains.

🦫 Explication de la marmotte 🍫

Une application qui tourne dans un cluster ou dans une fonction cloud doit parfois lire un fichier, envoyer un message ou accéder à une base de données. Avant, elle gardait souvent une clé secrète dans sa configuration. Si cette clé était copiée, l’accès restait possible jusqu’à son remplacement, parfois pendant des mois.

Avec la fédération d’identité, l’environnement où tourne l’application fournit un jeton temporaire qui décrit précisément l’application. Ce jeton contient son nom, son emplacement et une date de fin. Il est signé par une autorité reconnue. L’application envoie ce jeton au fournisseur cloud et demande un accès.

Le fournisseur vérifie plusieurs points : qui a signé le jeton, pour quel service il a été créé, s’il n’est pas expiré, et si l’identité indiquée a le droit de demander cet accès. Si tout correspond, le fournisseur donne des identifiants temporaires limités aux actions autorisées. L’application les utilise, puis les renouvelle avant leur expiration.

Si le jeton est volé, son utilisation reste limitée dans le temps, mais le vol reste dangereux. Si la configuration de confiance est incorrecte, l’accès est refusé. Si les droits accordés sont trop larges, l’application peut faire trop de dégâts après une compromission. La fédération retire donc une clé durable, mais elle exige de limiter les droits, surveiller les refus et protéger l’environnement qui émet les jetons.

Pages voisines

La citent

Mettre en place la fédération d’identité de charge

Elle cite

: les deux pages se citent l’une l’autre.

Mettre en place la fédération d’identité de charge

Mettre en place la fédération d’identité de charge

Jeton fédéré, identifiant cloud et relation de confiance

Prérequis de plateforme et configuration de confiance

Exemple Kubernetes avec OIDC et rôle cloud

Surface d’attaque et limites de la fédération

Exploitation, rotation et reprise après incident

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines