Identité machine et workload identity

45 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 16 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Quand un service A doit appeler un service B, la méthode traditionnelle est de partager un secret : mot de passe, jeton, clé d'API. Ce secret se copie, fuit et dure trop longtemps. L'identité machine, ou workload identity, propose autre chose : le service prouve qui il est grâce à un document cryptographique court, émis par une autorité que le destinataire sait vérifier. Cette leçon s'adresse au DevOps qui veut savoir quand cette approche remplace un secret, et quand elle ne le peut pas.

Les mécanismes ont été mesurés : les durées de vie des documents que délivre SPIRE (version 1.15.3) et le contenu d'un jeton Kubernetes projeté, sur un cluster local kind (Kubernetes 1.37). Les mesures sont données là où chaque notion est expliquée.

Pour le cloud, la leçon décrit et compare : elle ne fait pas configurer un cloud. Les extraits GKE, EKS et AKS montrent ce que chaque fournisseur exige, pour que vous choisissiez en connaissance de cause. Deux points surprennent souvent : GKE ne demande plus l'annotation de ServiceAccount, et AKS exige un label de pod que beaucoup de tutoriels oublient.

Ce que vous allez apprendre

Distinguer une identité machine d'un secret partagé
Séparer les deux familles : identité interne (SPIFFE/SPIRE) et fédération cloud (OIDC)
Décoder un jeton de ServiceAccount projeté et ce que le cloud y vérifie
Comparer la fédération sur GKE, EKS et AKS et repérer les prérequis réels de chaque cloud
Choisir entre identité machine, secret dynamique et secret statique selon le système cible
Relier cette démarche à l'exigence SOCLE-SEC-GEN-5 sur les identités courtes

Quels prérequis pour suivre cette leçon ?

Cette leçon se lit sans compte cloud ni cluster : aucune commande n'est à rejouer pour suivre le raisonnement. Trois notions sont en revanche supposées connues :

le secret statique et son coût, vus dans Pourquoi les secrets statiques posent problème ;
le secret zéro, le premier secret qui permet de s'authentifier, expliqué dans Le problème du secret zéro ;
le vocabulaire de base de Kubernetes, pod, namespace et ServiceAccount, détaillé dans ServiceAccounts pour développeurs.

Deux notions facilitent la lecture sans être indispensables : la différence entre authentification et autorisation (bases de l'IAM) et ce qu'est un JWT signé (OpenID Connect). Rejouer les extraits cloud exigerait en plus un compte cloud, un cluster managé (GKE, EKS ou AKS) et des droits IAM, que cette leçon ne fournit pas. La section sur l'infrastructure à prévoir liste ce qu'un vrai déploiement demande.

Le problème du secret partagé

Avant d'examiner les solutions, il faut voir ce qui casse dans le modèle habituel. Le secret partagé ne pose pas seulement un problème de confidentialité : il rend aussi la traçabilité impossible et la rotation coûteuse. Ces trois défauts se tiennent, et c'est ensemble qu'ils justifient de changer d'approche.

Scénario classique

Le service payment-api doit appeler user-api pour valider un utilisateur. L'approche traditionnelle place une clé d'API commune dans la configuration des deux côtés. Le tableau qui suit le fichier résume ce que cette clé partagée coûte en sécurité et en exploitation.

# ❌ payment-api/config.yaml
user_api:
  url: https://user-api.internal
  api_key: "shared-secret-between-services"

Problème	Conséquence
Secret partagé	Si un service est compromis, l'autre l'est aussi
Copié partout	Configurations, variables d'environnement, sauvegardes
Pas d'attribution	Impossible de savoir quel service a fait quelle requête
Rotation pénible	Changer le secret oblige à redéployer tous les services

L'alternative : prouver son identité

Au lieu de partager un secret, chaque service prouve qui il est avec un document cryptographique, un certificat X.509 ou un JWT signé. Le service cible vérifie trois choses, dans cet ordre. La troisième relève de l'autorisation, distincte de l'identité, comme le montre la section « Identité et autorisation » plus bas.

Le document est valide : signé par une autorité de confiance, non expiré.
L'identité correspond au service attendu.
Le service a le droit d'appeler cette API.

Il n'y a plus de secret applicatif partagé de longue durée. Chaque service a sa propre identité, courte et vérifiable. Elle n'est pas « impossible à copier » : un jeton volé reste utilisable jusqu'à son expiration, d'où l'importance de durées en minutes ou en heures.

Qu'est-ce qu'une identité machine

Le terme recouvre une réalité précise, à ne pas confondre avec un simple compte de service muni d'un mot de passe. Une identité machine se définit par ce qu'elle contient, par ce qui la distingue d'un secret, et par le mécanisme qui la délivre.

Définition

Une identité machine (ou workload identity) est un document cryptographique qui identifie un workload (pod, VM, service, fonction) de façon vérifiable. Ce n'est pas un mot de passe : c'est le résultat d'une attestation, « ce workload est bien celui qu'il prétend être, et voici la preuve signée ».

Composants d'une identité machine

Quatre éléments sont toujours présents, quelle que soit la technologie. Le plus souvent négligé est le dernier : sans attestation, un workload pourrait simplement réclamer une identité qui ne lui appartient pas, et tout l'édifice s'effondre.

Composant	Rôle
Identifiant unique	Nom du workload (par exemple `spiffe://example.org/payment-api`)
Document cryptographique	Certificat X.509 ou JWT signé
Durée de vie courte	Minutes ou heures, pas des mois
Attestation	Preuve que le workload tourne bien là où il le prétend

Différence avec un secret

La distinction est fondamentale. Un secret partagé est une valeur que quiconque la détient peut présenter, n'importe où, pendant des mois. Une identité machine est émise pour un workload attesté, porte son nom et expire vite.

Aspect	Secret partagé	Identité machine
Nature	Valeur sensible à protéger	Document signé et vérifiable
Émission	Créé une fois, copié à la main	Émis pour un workload attesté
Durée	Souvent longue	Courte (de quelques minutes à quelques heures)
Attribution	Difficile	Directe, une identité par workload
Fin de vie	Révocation manuelle, souvent incomplète	Expiration automatique, renouvellement

Deux familles d'identité de workload

Quand on parle d'identité machine, il faut distinguer deux sous-modèles qui partagent le même principe mais répondent à des besoins différents. Le schéma les présente l'une après l'autre : des services qui s'authentifient entre eux, puis un pod qui accède à une API cloud, l'IAM du cloud étant mis en évidence parce que c'est lui qui décide.

Source · SVG

Identité interne (M2M)

L'identité sert à authentifier les services entre eux, à l'intérieur d'une infrastructure, ce qu'on appelle le M2M (machine to machine). C'est le domaine de SPIFFE/SPIRE et des service meshes (Istio, Linkerd, Cilium). Les certificats X.509 ou JWT sont signés par une autorité propre à l'organisation, et servent au mTLS (TLS mutuel, où les deux côtés présentent un certificat).

SPIFFE est le standard qui décrit ces identités, SPIRE son implémentation de référence ; le document remis à un workload s'appelle un SVID, détaillé plus bas. Cette famille est indépendante du fournisseur cloud. Elle demande en revanche un agent local (SPIRE Agent) ou un proxy auxiliaire (Envoy) pour livrer et utiliser l'identité.

Fédération d'identité vers le cloud

L'identité sert à accéder à des services cloud (S3, GCS, Azure Key Vault) depuis un workload, sans clé statique. C'est le domaine de Workload Identity Federation for GKE, d'IRSA et d'EKS Pod Identity chez AWS, et de Microsoft Entra Workload ID sur AKS.

Le principe le plus répandu repose sur l'émetteur OIDC du cluster Kubernetes : le cloud vérifie le jeton du pod et rend des identifiants temporaires. Chaque cloud a ses propres prérequis, et AWS propose une variante, EKS Pod Identity, qui se passe de fournisseur OIDC.

Identité et autorisation : deux questions distinctes

L'identité répond à « qui est ce workload ? », jamais à « que peut-il faire ? ». Ce sont deux mécanismes séparés, configurés à deux endroits. Le tableau les met en regard avec leurs outils habituels.

Question	Mécanisme	Exemples
Qui suis-je ?	Identité (attestation)	SVID SPIFFE, jeton OIDC
Que puis-je faire ?	Autorisation (politique)	Politiques IAM, AuthorizationPolicy Istio, politiques Vault

Un workload peut avoir une identité valide et se voir refuser l'accès si la politique ne l'autorise pas. L'inverse est plus dangereux : une politique trop large, du type « tout workload authentifié », rend l'identité inutile. Chaque couche porte donc sa propre politique :

Service mesh : AuthorizationPolicy (Istio) ou politique réseau fondée sur l'identité (Cilium)
Vault ou OpenBao : politiques liées au SPIFFE ID ou au rôle Kubernetes
IAM cloud : rôle associé au ServiceAccount (GKE, IRSA, EKS Pod Identity, AKS)
Application : vérification du sub du JWT ou du SAN du certificat

Comment fonctionne l'attestation

Le mécanisme d'attestation varie selon la famille. SPIRE atteste lui-même le nœud puis le workload ; la fédération cloud s'appuie sur le jeton que Kubernetes a déjà signé. Les deux flux sont détaillés ci-dessous, avec ce que la mesure en montre.

Attestation avec SPIRE

SPIRE procède en deux phases : il atteste d'abord le nœud, puis le workload qui tourne dessus. Le diagramme suit l'échange entre le workload, l'agent et le serveur, jusqu'à la livraison d'un SVID renouvelé automatiquement.

Source · SVG

Attestation du nœud

Le SPIRE Agent prouve l'identité de son nœud au SPIRE Server. Selon l'environnement, la preuve est un document d'identité d'instance cloud, un certificat TPM (puce de sécurité matérielle), un jeton de ServiceAccount Kubernetes, ou un join token à usage unique.
Attestation du workload

Quand un processus appelle la Workload API (une socket Unix), l'agent identifie l'appelant par son PID et en déduit des sélecteurs : unix:uid, namespace et ServiceAccount Kubernetes, labels. Ces sélecteurs sont comparés aux entrées d'enregistrement du serveur.
Émission du SVID

Si une entrée correspond, le workload reçoit un SVID. Mesuré sur SPIRE 1.15.3, avec une entrée unix:uid:0 : un X509-SVID valable 1 heure (default_x509_svid_ttl) et un JWT-SVID de 5 minutes (default_jwt_svid_ttl), renouvelés automatiquement.

$ spire-agent api fetch x509 -socketPath /tmp/agent.sock
SPIFFE ID:          spiffe://example.org/payment-api
SVID Valid After:   2026-10-01 13:44:19 +0000 UTC
SVID Valid Until:   2026-10-01 14:44:29 +0000 UTC
CA #1 Valid Until:  2026-10-02 13:44:21 +0000 UTC

La CA intermédiaire du serveur vaut 24 heures par défaut (ca_ttl) : même l'autorité qui signe se renouvelle vite. C'est cette chaîne de durées courtes, plus que le chiffrement, qui limite la valeur d'un SVID volé.

Flux cloud : fédération OIDC

Les solutions cloud suivent un flux différent, qui repose sur l'émetteur OIDC du cluster. Le diagramme montre les quatre temps : le kubelet projette un jeton dans le pod, le pod l'échange auprès de l'IAM du cloud, qui vérifie la signature avec les clés publiques de l'émetteur, puis rend des identifiants temporaires.

Source · SVG

Ce que contient le jeton projeté : mesuré

Le jeton projeté est un JWT signé par l'API du cluster. Pour le voir, un pod payment-api monte un volume projeté serviceAccountToken avec une audience dédiée, sts.amazonaws.com, et une durée de 3600 secondes. Mesuré sur kind 0.33 avec Kubernetes 1.37, en décodant la partie centrale du jeton :

# Extrait du pod : volume projeté avec audience et durée
volumes:
  - name: cloud-token
    projected:
      sources:
        - serviceAccountToken:
            path: token
            audience: sts.amazonaws.com
            expirationSeconds: 3600

{
  "aud": ["sts.amazonaws.com"],
  "iss": "https://kubernetes.default.svc.cluster.local",
  "sub": "system:serviceaccount:payment:payment-api",
  "exp": 1790865974,
  "iat": 1790862374,
  "kubernetes.io": {
    "namespace": "payment",
    "pod": { "name": "payment-api", "uid": "22baa468-7e25-4636-9220-51caa006d630" },
    "serviceaccount": { "name": "payment-api", "uid": "960d1fb7-2b94-4d0f-bdee-fa36a5f4ff50" }
  }
}

Trois champs font la sécurité de la fédération. L'audience (aud) empêche de rejouer le jeton auprès d'un autre service, le sujet (sub) désigne précisément le namespace et le ServiceAccount, et l'écart exp - iat vaut 3600 secondes. Le cloud vérifie la signature avec les clés publiées à /.well-known/openid-configuration puis /openid/v1/jwks.

Le champ kubernetes.io.pod lie le jeton à son pod : la mesure montre que le jeton est invalidé dès que ce pod est supprimé, ce qu'un mot de passe copié ne fait jamais. Deux autres mesures complètent ce constat. Une durée inférieure à 10 minutes est refusée par l'API : expirationSeconds: 300 donne may not specify a duration less than 10 minutes. Et le jeton par défaut monté dans le même pod (audience de l'API Kubernetes) affichait un an de validité, effet de l'option --service-account-extend-token-expiration de l'API server, active par défaut pour la compatibilité. D'où l'intérêt d'un jeton dédié, court et à audience précise, pour toute fédération.

SPIFFE : un standard pour l'identité de workload

SPIFFE (Secure Production Identity Framework For Everyone) est un standard de la CNCF, où le projet et son implémentation SPIRE ont atteint le statut graduated. Il fixe le format des identités et la façon de les livrer, indépendamment du cloud et de l'orchestrateur.

SPIFFE ID

Le SPIFFE ID est un identifiant unique par workload, écrit sous forme d'URI. Sa première partie, le trust domain, désigne l'autorité qui garantit l'identité ; le chemin qui suit décrit le workload selon une convention que vous choisissez, souvent calquée sur le namespace et le ServiceAccount Kubernetes.

spiffe://trust-domain/path/to/workload

# Exemples
spiffe://example.org/payment-api
spiffe://example.org/ns/production/sa/frontend
spiffe://mycompany.com/region/eu-west-3/service/checkout

SVID (SPIFFE Verifiable Identity Document)

Le SVID est le document cryptographique qui porte le SPIFFE ID et prouve qu'il appartient à ce workload. Il existe en deux formats, et ce n'est pas un détail : le format conditionne ce que le système cible doit savoir vérifier.

Format	Usage
X.509-SVID	Certificat pour le mTLS entre services
JWT-SVID	Jeton pour les API et proxies qui ne gèrent pas le mTLS

SPIRE

SPIRE (SPIFFE Runtime Environment) est l'implémentation de référence des API SPIFFE. Il se compose de trois éléments, dont le premier devient un composant critique de l'infrastructure : sans lui, plus aucun SVID n'est émis ni renouvelé.

Composant	Rôle
SPIRE Server	Autorité centrale, signe les SVID, vérifie les attestations
SPIRE Agent	Tourne sur chaque nœud, atteste les workloads, livre les SVID
Workload API	Socket Unix par laquelle les workloads récupèrent leurs SVID

Le SPIRE Server s'exploite avec les exigences d'un service central : haute disponibilité, base de données partagée, supervision des échecs d'attestation. Une panne ne coupe pas tout immédiatement, les agents gardent leurs SVID en cache ; mais sans renouvellement, ces SVID d'une heure expirent les uns après les autres.

Cloud Workload Identity

Les trois grands clouds proposent leur fédération d'identité entre Kubernetes et leur IAM. Le principe est commun, mais les prérequis diffèrent, et c'est là que les déploiements échouent : une annotation seule, sans la configuration côté cluster et côté IAM, n'a aucun effet. Les extraits qui suivent sont à lire, pas à rejouer tels quels : ils supposent un projet ou un compte cloud, un cluster managé et des droits d'administration IAM, et leurs identifiants (PROJECT_ID, 123456789012, 00000000-...) sont des valeurs d'exemple. Ils n'ont pas été mesurés sur un cloud. Le tableau en fin de section les compare.

Workload Identity Federation for GKE

Sur GKE, la fédération s'active au niveau du cluster avec un pool d'identités, puis les rôles IAM s'accordent directement au ServiceAccount Kubernetes par un identifiant de principal. C'est la bonne pratique affichée par la documentation Google, qui ne demande alors aucune annotation.

# Activer la fédération sur le cluster
gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --workload-pool=PROJECT_ID.svc.id.goog

# Donner un rôle directement au ServiceAccount Kubernetes payment/payment-api
gcloud projects add-iam-policy-binding projects/PROJECT_ID \
  --role=roles/storage.objectViewer \
  --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/payment/sa/payment-api

L'ancienne méthode reste possible quand une API Google ne sait pas encore reconnaître ce principal : on lie le ServiceAccount Kubernetes à un compte de service IAM, ce qui exige à la fois une politique accordant roles/iam.workloadIdentityUser et l'annotation iam.gke.io/gcp-service-account sur le ServiceAccount.

AWS : IRSA ou EKS Pod Identity

AWS propose deux mécanismes. IRSA (IAM Roles for Service Accounts) suppose un fournisseur OIDC IAM pour le cluster, une relation de confiance sur le rôle avec des conditions StringEquals sur le sub et l'aud du jeton, et l'annotation du ServiceAccount. Le compte AWS a 12 chiffres :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-api
  namespace: payment
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/payment-api

EKS Pod Identity est l'alternative que la documentation AWS présente comme plus simple : pas de fournisseur OIDC, une association déclarée dans EKS entre un rôle et un ServiceAccount, un agent (EKS Pod Identity Agent) en DaemonSet, et un seul principal de confiance, pods.eks.amazonaws.com, pour tous les clusters. Elle ne fonctionne que sur EKS, avec des nœuds Linux EC2 : ni Fargate, ni nœuds Windows, ni EKS Anywhere, ni Outposts.

Microsoft Entra Workload ID sur AKS

Sur AKS Standard, il faut activer l'émetteur OIDC et Workload ID sur le cluster, puis créer un federated identity credential qui lie le ServiceAccount à l'identité managée. Côté Kubernetes, deux éléments sont à poser, et le second est celui qu'on oublie :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-api
  namespace: payment
  annotations:
    azure.workload.identity/client-id: 00000000-0000-0000-0000-000000000000
---
# Dans le gabarit du pod : sans ce label, le webhook n'injecte rien
metadata:
  labels:
    azure.workload.identity/use: "true"

La documentation Microsoft est explicite : seuls les pods portant le label azure.workload.identity/use: "true" sont modifiés par le webhook, qui injecte le jeton projeté et la variable AZURE_FEDERATED_TOKEN_FILE. Le jeton projeté par ce webhook vaut 3600 secondes par défaut, réglable de 3600 à 86 400 : c'est un réglage d'Azure Workload Identity, distinct du minimum de 10 minutes que l'API Kubernetes impose à expirationSeconds. Sur AKS Automatic, l'émetteur OIDC et Workload ID sont préconfigurés. Ce mécanisme remplace AAD Pod Identity (pod-managed identity), déprécié le 24 octobre 2022 et dont le projet open source est archivé depuis septembre 2023 : ne le choisissez pas pour un nouveau cluster.

Que choisir entre GKE, EKS et AKS ?

Le cloud est le plus souvent imposé par l'hébergement du cluster, pas choisi pour sa fédération. Le tableau sert donc à anticiper ce que chaque fournisseur demande et les points de vigilance de chacun.

Cloud	À activer sur le cluster	Lien de fédération	Point de vigilance
GKE	Pool d'identités du cluster (`--workload-pool`)	Rôle IAM accordé à un identifiant `principal://`	L'annotation `iam.gke.io/gcp-service-account` ne sert qu'à l'ancienne méthode ; les pods en `hostNetwork: true` n'en bénéficient pas
EKS (IRSA)	Fournisseur OIDC IAM pour le cluster	Relation de confiance sur le `sub` et l'`aud` du jeton, plus annotation	Sans condition sur le `sub`, la confiance n'est pas limitée à un ServiceAccount précis
EKS (Pod Identity)	Agent EKS Pod Identity en DaemonSet (inutile avec EKS Auto Mode)	Association rôle et ServiceAccount, principal `pods.eks.amazonaws.com`	Nœuds Linux EC2 seulement : ni Fargate, ni Windows, ni EKS Anywhere
AKS	Émetteur OIDC et Workload ID	Federated identity credential et annotation `client-id` du ServiceAccount	Label `azure.workload.identity/use: "true"` sur le pod

Sur EKS, la documentation AWS recommande de préférer EKS Pod Identity « chaque fois que possible », ce qui suppose des nœuds Linux EC2 ; hors de ce cas, il reste IRSA, avec sa condition sur le sub. Dans les trois cas, la fédération ne vaut que par la politique IAM qui limite ce que l'identité obtenue peut faire.

L'identité ne suffit pas : il faut un point d'intégration

Avoir une identité ne sert à rien si le workload ne sait pas l'utiliser. L'identité doit être consommée par une couche d'intégration, et le choix de cette couche décide souvent de l'effort : modifier le code, ou confier l'identité à l'infrastructure.

Point d'intégration	Fonctionnement
Proxy Envoy auxiliaire	Le proxy gère le mTLS et présente le certificat
Service mesh (Istio, Linkerd, Cilium)	Identité injectée par proxy auxiliaire ou eBPF
SDK cloud (AWS SDK, Google Cloud, Azure Identity)	Le SDK détecte les identifiants fédérés
Agent Vault ou pilote CSI	Échange l'identité contre un secret dynamique
Bibliothèque applicative	L'application charge elle-même le certificat ou le JWT

Si vos applications ne gèrent pas le mTLS, commencez par un proxy ou un service mesh : l'identité est gérée sans modification du code. Les SDK cloud récents lisent seuls les identifiants fédérés ; un SDK trop ancien continue de chercher une clé statique.

On ne supprime pas toute confiance initiale

L'identité machine supprime le secret applicatif partagé de longue durée. Elle ne supprime pas toute confiance initiale : une chaîne d'éléments reste nécessaire, et chacun devient une surface d'attaque à protéger, auditer et maintenir.

Élément de confiance	Rôle
Ancre de confiance (CA racine)	Signe les certificats SPIFFE
Trust bundle	Distribué aux workloads pour vérifier les SVID
Émetteur OIDC	Publie les clés que le cloud utilise pour vérifier les jetons
Configuration de fédération	Lie le ServiceAccount au rôle ou à l'identité cloud
Plugin d'attestation	Vérifie l'identité du nœud au démarrage

On remplace donc un secret partagé de longue durée par une infrastructure de confiance cryptographique plus robuste. La leçon sur le secret zéro explique pourquoi cette racine, et non un mot de passe, devient le point critique (voir Le problème du secret zéro).

Cas d'usage

Les quatre situations suivantes couvrent l'essentiel de la production. Deux sont pures : l'identité suffit du début à la fin. Les deux autres sont hybrides : l'identité sert à obtenir autre chose, un secret dynamique ou des identifiants cloud temporaires.

Service à service (mTLS)

Deux microservices communiquent avec des certificats SPIFFE : chacun vérifie l'identité de l'autre, sans secret partagé. En pratique, le mTLS passe par un proxy (Envoy, géré par un mesh) ou une bibliothèque qui charge les X.509-SVID depuis la Workload API.

Pod vers base de données

PostgreSQL, MySQL et la plupart des bases relationnelles ne savent pas vérifier un SVID : elles attendent un identifiant et un mot de passe. L'identité machine ne remplace donc pas l'identifiant, elle sert à l'obtenir auprès d'un coffre, au lieu d'un mot de passe statique.

Le pod a une identité (SPIFFE ou jeton Kubernetes).
Il la présente à Vault ou OpenBao.
Le coffre la vérifie et génère des identifiants de base dynamiques.
Le pod se connecte avec ces identifiants temporaires.

C'est un usage hybride, et le mieux outillé aujourd'hui : la leçon sur le cycle de vie (voir Cycle de vie d'un secret) mesure ces identifiants dynamiques, un utilisateur PostgreSQL distinct d'une heure par lecture.

CI/CD vers cloud

C'est le cas le plus rapide à mettre en place : GitHub Actions émet un jeton OIDC qui décrit le dépôt et la branche, et AWS comme GCP savent le vérifier. Au lieu de clés stockées dans les secrets du dépôt, le job obtient des identifiants temporaires. Le workflow suivant passe actionlint, zizmor 1.30.0 et poutine 1.1.6 sans constat.

name: deploy

on:
  push:
    branches: [main]

permissions: {}

jobs:
  deploy:
    runs-on: ubuntu-24.04
    environment: production
    permissions:
      id-token: write # émission du jeton OIDC du job
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Obtenir des identifiants AWS temporaires
        uses: aws-actions/configure-aws-credentials@e1253824e5c10ff9df46874f81ed3ec929e19cfd # v6.3.0
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: eu-west-3
          role-duration-seconds: 900

      - name: Vérifier l'identité obtenue
        run: aws sts get-caller-identity

Sans role-duration-seconds, l'action demande une heure, valeur par défaut de son action.yml. La leçon sur les secrets en CI/CD détaille la relation de confiance côté AWS, qui doit contraindre le sub du jeton au dépôt et à l'environnement. Pour configurer pas à pas l'OIDC de GitHub Actions chez AWS, Azure ou GCP, suivez OIDC GitHub Actions : AWS, Azure, GCP.

Proxy ou service mesh

C'est la voie à privilégier quand vous ne pouvez pas modifier les applications : l'identité est gérée hors du code, par l'infrastructure. Chaque pod reçoit un proxy auxiliaire ou un agent eBPF porteur de l'identité, le trafic entre pods est chiffré en mTLS, et l'autorisation se fonde sur l'identité, pas sur des secrets.

Identité, secret dynamique ou secret statique ?

Pour choisir, une seule question compte : le système cible sait-il vérifier un certificat ou un JWT, ou attend-il un mot de passe ? Le tableau décline la réponse par situation ; la comparaison détaillée des deux autres modèles est dans secrets statiques ou dynamiques.

Besoin	Approche recommandée	Pourquoi
Pod Kubernetes vers API cloud (S3, GCS)	Fédération native (GKE, IRSA ou EKS Pod Identity, AKS)	Pas de secret, jeton vérifié par le cloud
Service interne vers service interne	SPIFFE/SPIRE ou service mesh	mTLS avec identité, pas de secret M2M
Service vers base de données classique	Secret dynamique (Vault, OpenBao)	La base ne comprend pas les certificats SPIFFE
API tierce avec clé fixe	Secret statique sous coffre-fort	L'API impose une clé
Accès SSH court	Certificat SSH signé (Vault SSH)	Pas de clé SSH permanente
CI/CD vers cloud	Fédération OIDC (GitHub vers AWS ou GCP)	Pas de clé d'accès stockée
Application ancienne sans mTLS	Secret dynamique ou statique sous coffre	L'application ne sait pas consommer un certificat

La règle de décision tient en trois cas. Identité machine quand la cible vérifie un certificat ou un JWT ; secret dynamique quand elle attend un mot de passe mais tolère la rotation ; secret statique sous coffre quand aucune alternative n'existe.

Quand ne pas utiliser l'identité machine

L'identité machine n'est pas toujours le bon point de départ. Elle peut être la bonne réponse à terme sans être la priorité immédiate, et un projet SPIRE lancé trop tôt immobilise une équipe pendant que les secrets restent dans le code.

Situation	Pourquoi reporter	Commencer par
Application ancienne non modifiable	Ne sait pas recharger un certificat	Secret dynamique ou statique sous coffre
API externe à clé fixe	L'API impose son modèle	Clé rangée dans un coffre-fort
Équipe sans culture des certificats (PKI) ni d'OIDC	Courbe d'apprentissage	Coffre-fort et rotation automatique
Secrets encore dans le code	La priorité est de les sortir	Détection et coffre-fort
Infrastructure hors Kubernetes	Moins d'attestation native	Coffre avec une méthode d'authentification adaptée

Si l'équipe n'a pas encore sorti ses secrets du code source, déployer SPIFFE/SPIRE est prématuré. La détection de secrets et la migration vers un coffre-fort sont des étapes préalables.

Quelle infrastructure prévoir avant de déployer ?

Les prérequis de lecture sont en début de leçon ; ceux-ci concernent un vrai déploiement. Avant de déployer une solution d'identité machine, vérifiez que votre infrastructure est prête. Les deux familles n'ont pas le même coût : SPIRE revient à opérer une PKI interne, la fédération cloud délègue l'essentiel au fournisseur.

Pour SPIFFE/SPIRE

Une infrastructure à clés publiques (PKI) est l'ensemble qui émet, distribue et renouvelle des certificats : déployer SPIRE revient à en opérer une en interne. Les deux lignes les plus sous-estimées sont la distribution du trust bundle, sans laquelle les workloads ne peuvent vérifier leurs pairs, et la synchronisation de l'heure, qui invalide silencieusement des certificats d'une heure quand elle dérive.

Prérequis	Détail
Ancre de confiance	CA racine ou autorité amont pour signer les SVID
SPIRE Server en haute disponibilité	Réplication, base partagée (PostgreSQL, MySQL)
SPIRE Agent sur chaque nœud	DaemonSet Kubernetes ou agent système
Plugin d'attestation	Adapté à l'environnement (Kubernetes, AWS, GCP, TPM)
Observabilité	Métriques et journaux des échecs d'attestation
Distribution du trust bundle	Mécanisme pour livrer et renouveler le bundle
Synchronisation de l'heure	NTP surveillé sur tous les nœuds

Pour la fédération cloud

La liste est plus courte, car le cloud opère l'essentiel. Votre travail se limite à exposer l'émetteur OIDC (sauf avec EKS Pod Identity), à créer le rôle et à décrire la relation de confiance. Attention au dernier point du tableau : un SDK ancien ne sait pas lire les identifiants fédérés.

Prérequis	Détail
Émetteur OIDC du cluster	Configuration propre à chaque cloud
Rôle IAM ou identité managée	Créé avec des permissions minimales
Lien de fédération	Propre à chaque cloud, comparé dans le tableau de la section « Que choisir entre GKE, EKS et AKS ? »
SDK compatible	Version qui détecte les identifiants fédérés

Pièges courants

Ces six erreurs reviennent dans les premiers déploiements. Les deux premières sont les plus coûteuses, car elles donnent une fausse impression de sécurité : le workload s'authentifie, les journaux sont propres, et la protection est nulle parce que l'autorisation est trop large ou que la configuration côté cluster n'a jamais été activée.

Piège	Conséquence	Comment l'éviter
Croire que l'identité remplace l'autorisation	Workloads authentifiés mais trop autorisés	Politiques d'autorisation fines
Penser qu'une annotation suffit	Sans configuration cluster et IAM, aucun effet	Vérifier les prérequis (émetteur OIDC, pool, label AKS)
Supposer que toutes les applications gèrent le mTLS	L'application ignore le certificat	Proxy auxiliaire ou service mesh
Ignorer le renouvellement	Le certificat expire, l'application tombe	Surveiller les TTL, tester les renouvellements
Multiplier les identités sans gouvernance	Explosion des SPIFFE ID et des politiques	Convention de nommage, politiques en code
Ne pas surveiller le SPIRE Server	Plus aucun SVID renouvelé	Alertes sur les métriques SPIRE

Limites et défis

Là où les pièges relèvent de l'erreur de configuration, les limites ci-dessous sont structurelles : il faut les budgéter. Deux décident souvent du calendrier : la capacité réelle des applications à exploiter un certificat, et le plan de contrôle d'identité qui devient un service critique de plus.

Limite	Effet réel	Atténuation
Intégration applicative	L'application ne sait pas exploiter un certificat ou un JWT	Proxy, service mesh ou SDK
Plan de contrôle critique	Panne SPIRE : renouvellements en échec	Haute disponibilité, cache local, supervision
Débogage plus difficile	Échec d'authentification, d'autorisation ou de transport difficile à isoler	Journaux structurés par couche
Compatibilité partielle	Certains systèmes ne parlent ni mTLS ni OIDC	Secret dynamique ou statique sous coffre
Gouvernance d'identité	Explosion des identités et des politiques	Convention de nommage, politiques en code
Dérive d'horloge	Certificats courts rejetés	NTP surveillé
Cas hybrides	Tout le système d'information ne parle pas SPIFFE ou OIDC	Approche progressive

Migration progressive

Une bascule en une fois n'est pas réaliste : les six étapes ci-dessous décrivent une trajectoire où chaque flux migre indépendamment et reste réversible. L'ordre compte, surtout la dernière étape : tant que les anciens secrets existent, ils restent utilisables et la surface d'attaque n'a pas diminué.

Inventoriez les flux M2M

Listez les communications entre services qui utilisent des secrets partagés, et repérez les plus sensibles.
Priorisez par criticité et faisabilité

Commencez par les flux sensibles (paiement, données personnelles) et compatibles (services déjà dans Kubernetes, mTLS possible par le mesh).
Déployez l'infrastructure d'identité

SPIRE pour le M2M interne, fédération native pour les accès cloud. Les deux coexistent.
Migrez service par service

Remplacez chaque secret partagé par du mTLS avec identité ou par la fédération OIDC, et validez chaque migration seule.
Gardez le secret dynamique pour l'existant

Les systèmes qui ne parlent ni mTLS ni OIDC restent sur Vault ou OpenBao, avec des identifiants dynamiques.
Révoquez les anciens secrets

Une fois la migration observée en production, révoquez puis supprimez les secrets devenus inutiles.

Ressources

Ces documentations officielles ont servi à vérifier les prérequis de cette leçon. Elles évoluent vite, en particulier côté cloud : relisez-les avant un déploiement, notamment pour les annotations et les labels exigés.

SPIFFE : standard d'identité de workload (CNCF)
Concepts SPIRE : attestation, SVID, trust bundles
Workload Identity Federation for GKE : documentation Google Cloud
EKS Pod Identity et IRSA : documentation AWS
Microsoft Entra Workload ID sur AKS : documentation Microsoft
Envoy avec des X.509-SVID : intégration par proxy

À retenir

Une identité machine est un document signé, émis pour un workload attesté, et court : 1 heure pour un X509-SVID, 5 minutes pour un JWT-SVID (SPIRE 1.15.3).
Deux familles : identité interne (SPIFFE/SPIRE, mTLS) et fédération cloud (OIDC), complémentaires.
L'identité ne remplace pas l'autorisation : une politique trop large rend l'identité inutile.
Un jeton projeté porte une audience, un sujet et une durée ; mesuré, il est invalidé à la suppression de son pod.
Les trois clouds se comparent par leurs prérequis : pool et principal sur GKE (sans annotation), fournisseur OIDC ou EKS Pod Identity sur AWS, label azure.workload.identity/use sur AKS. La leçon décrit ces prérequis sans les faire configurer.
L'identité a besoin d'un point d'intégration : proxy, mesh, SDK ou agent du coffre.
Elle n'est pas toujours la priorité : sortir les secrets du code et adopter un coffre viennent d'abord.
La preuve attendue par SOCLE-SEC-GEN-5 est l'usage d'identités courtes ou éphémères (OIDC) plutôt que de secrets de longue durée.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

Identité machine et workload identity

Ce que vous allez apprendre

Quels prérequis pour suivre cette leçon ?

Le problème du secret partagé

Scénario classique

L'alternative : prouver son identité

Qu'est-ce qu'une identité machine

Définition

Composants d'une identité machine

Différence avec un secret

Deux familles d'identité de workload

Identité interne (M2M)

Fédération d'identité vers le cloud

Identité et autorisation : deux questions distinctes

Comment fonctionne l'attestation

Attestation avec SPIRE

Flux cloud : fédération OIDC

Ce que contient le jeton projeté : mesuré

SPIFFE : un standard pour l'identité de workload

SPIFFE ID

SVID (SPIFFE Verifiable Identity Document)

SPIRE

Cloud Workload Identity

Workload Identity Federation for GKE

AWS : IRSA ou EKS Pod Identity

Microsoft Entra Workload ID sur AKS

Que choisir entre GKE, EKS et AKS ?

L'identité ne suffit pas : il faut un point d'intégration

On ne supprime pas toute confiance initiale

Cas d'usage

Service à service (mTLS)

Pod vers base de données

CI/CD vers cloud

Proxy ou service mesh

Identité, secret dynamique ou secret statique ?

Quand ne pas utiliser l'identité machine

Quelle infrastructure prévoir avant de déployer ?

Pour SPIFFE/SPIRE

Pour la fédération cloud

Pièges courants

Limites et défis

Migration progressive

Ressources

À retenir

Contrôle de connaissances

Contrôle de connaissances

Informations

Score par domaine

Bilan

Points forts

Points faibles

À faire ensuite