Identité machine et workload identity

Quand un service A doit appeler un service B, la méthode traditionnelle est de partager un secret (mot de passe, token, clé API). Le problème : ce secret peut être copié, fuité, et dure souvent trop longtemps.

L’identité machine (ou workload identity) propose une approche différente : au lieu de partager un secret, le service prouve son identité grâce à un document cryptographique. Plus de secret applicatif partagé longue durée, attribution précise, durée de vie courte.

Ce que vous allez apprendre

• Ce qu’est une identité machine vs un secret partagé
• Les deux familles d’identité de workload : interne (M2M) et fédération cloud
• Comment fonctionne l’attestation (SPIRE vs OIDC cloud)
• Pourquoi l’identité ne remplace pas l’autorisation
• Quand utiliser l’identité machine, un secret dynamique ou un secret statique
• Les pré-requis techniques et pièges courants

Prérequis

Pourquoi les secrets statiques sont un problème Comprendre les limites des credentials persistants

Secrets statiques vs dynamiques Les alternatives aux secrets longue durée

Le problème du secret partagé

Scénario classique

Le service payment-api doit appeler le service user-api pour valider un utilisateur. Approche traditionnelle :

payment-api/config.yaml

user_api:
  url: https://user-api.internal
  api_key: "shared-secret-between-services"

Problèmes :

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

Glissez pour voir

L’alternative : prouver son identité

Au lieu de partager un secret, chaque service prouve qui il est grâce à un document cryptographique (certificat X.509 ou JWT signé). Le service cible vérifie :

1. Le document est valide (signé par une autorité de confiance)
2. L’identité correspond bien au service attendu
3. Le service a le droit d’appeler cette API

Plus de secret applicatif partagé longue durée. Chaque service a sa propre identité, courte, vérifiable, non copiable.

Qu’est-ce qu’une identité machine

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 une attestation : “Ce workload est bien qui il prétend être, et voici la preuve cryptographique”.

Composants d’une identité machine

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

Glissez pour voir

Différence avec un secret

La distinction est fondamentale. Un secret peut être copié et utilisé n’importe où, tandis qu’une identité machine est cryptographiquement liée à un workload spécifique.

Aspect	Secret	Identité machine
Nature	Donnée sensible à protéger	Document cryptographique vérifiable
Partage	Peut être copié	Liée cryptographiquement au workload
Durée	Souvent longue	Courte (certificat temporaire)
Attribution	Difficile	Triviale (identité unique)
Révocation	Manuelle, incomplète	Automatique à expiration

Glissez pour voir

Deux familles d’identité de workload

Quand on parle d’identité machine, il faut distinguer deux sous-modèles qui répondent à des besoins différents, même s’ils partagent le même principe de base.

Identité interne (M2M)

L’identité sert à authentifier les services entre eux, à l’intérieur d’une infrastructure. C’est le domaine de SPIFFE/SPIRE et des service meshes (Istio, Linkerd, Cilium).

Caractéristiques :

• Certificats X.509 ou JWT signés par une autorité propre
• Communication mTLS entre services
• Indépendant du cloud provider
• Nécessite un agent local (SPIRE Agent) ou un sidecar proxy (Envoy) pour l’intégration

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

L’identité sert à accéder à des services cloud (S3, GCS, Azure Key Vault) depuis un workload Kubernetes, sans clé statique. C’est le domaine de GKE Workload Identity Federation, EKS IRSA et AKS Workload Identity.

Caractéristiques :

• Repose sur le fournisseur OIDC du cluster Kubernetes
• Le cloud vérifie le token OIDC et attribue des credentials temporaires
• Spécifique à chaque cloud provider
• Ne nécessite pas d’agent SPIRE : le cluster expose un OIDC issuer, le cloud fait la fédération

Ne pas confondre les deux modèles

SPIFFE/SPIRE et les workload identity cloud sont complémentaires, pas interchangeables. SPIFFE résout le M2M interne. La fédération cloud résout l’accès aux APIs cloud. Un même cluster peut utiliser les deux.

Identité et autorisation : deux questions distinctes

L’identité répond à “qui est ce workload ?”. Mais elle ne répond pas à “que peut-il faire ?”. Ce sont deux mécanismes séparés.

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

Glissez pour voir

Un workload peut avoir une identité valide et se voir refuser l’accès si la politique d’autorisation ne l’autorise pas. L’inverse aussi : une politique trop permissive (“allow all authenticated”) rend l’identité inutile.

En pratique, chaque couche a sa propre politique d’autorisation :

• Service mesh : AuthorizationPolicy (Istio) ou NetworkPolicy avec identité (Cilium)
• Vault : policies basées sur le SPIFFE ID ou le rôle Kubernetes
• IAM cloud : rôle IAM associé au ServiceAccount (IRSA, GKE WIF, AKS WI)
• Application : vérification du subject du JWT ou du CN du certificat

Principe clé

L’identité sans politique d’autorisation ne protège rien. Vérifiez toujours les deux : “Ce workload est-il qui il prétend être ?” et “A-t-il le droit de faire cette action ?”

Comment fonctionne l’attestation

Le mécanisme d’attestation varie selon le modèle choisi. SPIRE et les solutions cloud suivent des flux différents.

Exemple d’attestation avec SPIRE

SPIRE procède en deux phases : il atteste d’abord le nœud, puis le workload qui tourne sur ce nœud. Les deux phases doivent réussir pour qu’un SVID soit émis.

1. Attestation du nœud

   Le SPIRE Agent prouve l’identité du nœud au SPIRE Server. Selon l’environnement, les preuves peuvent être un instance identity document AWS, un certificat TPM, ou un token de jointure.

2. Attestation du workload

   L’agent collecte les preuves du workload : namespace Kubernetes, ServiceAccount, labels, PID du processus. Ces preuves sont comparées aux registration entries configurées dans le serveur.

3. Émission du SVID

   Si les deux attestations réussissent, le workload récupère un SVID (certificat X.509 ou JWT) via la Workload API, avec un TTL de quelques heures. Le renouvellement est automatique.

Flux cloud : fédération OIDC

Les solutions cloud (GKE, EKS, AKS) suivent un flux différent qui repose sur le fournisseur OIDC intégré au cluster Kubernetes.

1. Le pod reçoit un JWT projeté

   Kubernetes projette un token JWT dans le pod, lié à son ServiceAccount.

2. Le cloud vérifie le token OIDC

   Le cloud provider (AWS IAM, Google IAM, Microsoft Entra) vérifie le JWT auprès de l’OIDC issuer du cluster.

3. Émission de credentials temporaires

   Si la vérification réussit et que la politique IAM l’autorise, le cloud émet des credentials temporaires (STS token AWS, access token GCP, etc.).

4. Accès aux services cloud

   Le pod utilise ces credentials pour accéder aux APIs cloud (S3, GCS, Azure Key Vault…).

SPIFFE : un standard majeur pour l’identité de workload

SPIFFE (Secure Production Identity Framework for Everyone) est un standard CNCF pour les identités de workload, particulièrement pertinent pour les architectures cloud-native et les communications M2M.

SPIFFE ID

Un identifiant unique pour chaque workload :

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-1/service/checkout

SVID (SPIFFE Verifiable Identity Document)

Le document cryptographique qui prouve l’identité. Deux formats :

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

Glissez pour voir

SPIRE

SPIRE (SPIFFE Runtime Environment) est l’implémentation de référence production-ready des APIs SPIFFE. Il se compose de :

Composant	Rôle
SPIRE Server	Autorité centrale, signe les SVIDs, vérifie les attestations
SPIRE Agent	Tourne sur chaque nœud, atteste les workloads, distribue les SVIDs
Workload API	API Unix socket pour récupérer les SVIDs depuis les workloads

Glissez pour voir

SPIRE est un composant critique

SPIRE Server devient un composant central du plan de contrôle d’identité. Une panne impacte l’émission et le renouvellement des SVIDs. Il doit être opéré avec les mêmes exigences de haute disponibilité et d’observabilité qu’un service central d’infrastructure (réplication, monitoring, alerting).

Cloud Workload Identity

Les cloud providers proposent leurs propres solutions de fédération d’identité entre Kubernetes et leurs APIs. Ces solutions reposent toutes sur le même principe : le fournisseur OIDC du cluster fédère l’identité vers le système IAM du cloud.

GKE Workload Identity Federation

Un pod GKE peut utiliser un service account GCP sans clé JSON :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  annotations:
    iam.gke.io/gcp-service-account: my-app@project.iam.gserviceaccount.com

Pré-requis côté cluster

L’annotation seule ne suffit pas. Il faut activer Workload Identity Federation for GKE sur le cluster ou les node pools concernés. Google le recommande comme l’approche standard pour l’accès aux services Google Cloud depuis GKE.

AWS IAM Roles for Service Accounts (IRSA)

Un pod EKS peut assumer un rôle IAM :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/my-app-role

Pré-requis côté cluster

L’annotation seule ne suffit pas. IRSA suppose un provider OIDC configuré pour le cluster EKS et une relation de confiance entre le rôle IAM et le ServiceAccount Kubernetes (condition StringEquals sur le subject OIDC).

Azure Workload Identity

Un pod AKS peut utiliser une identité managée Microsoft Entra :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  annotations:
    azure.workload.identity/client-id: <client-id>

Pré-requis côté cluster

L’annotation seule ne suffit pas. Il faut activer l’OIDC issuer du cluster AKS et Microsoft Entra Workload ID, puis configurer une federated identity credential pour lier le ServiceAccount à l’identité managée.

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

Avoir une identité (SVID, JWT cloud) ne sert à rien si le workload ne sait pas l’utiliser. L’identité doit être consommée par une couche d’intégration.

Point d’intégration	Comment ça fonctionne
Proxy Envoy / sidecar	Le proxy gère mTLS et présente le certificat automatiquement
Service mesh (Istio, Linkerd, Cilium)	Injection transparente de l’identité via sidecar ou eBPF
SDK cloud (AWS SDK, google-cloud-go)	Le SDK détecte les credentials projetés et les utilise
Vault Agent / CSI driver	Échange l’identité SPIFFE contre un secret dynamique
Bibliothèque applicative	L’application charge explicitement le certificat ou le JWT

Glissez pour voir

Commencer par le proxy

Si vos applications ne savent pas gérer mTLS, commencez par un proxy sidecar (Envoy) ou un service mesh. L’identité est gérée transparentement, sans modification du code applicatif.

On ne supprime pas toute confiance initiale

L’identité machine supprime le secret applicatif partagé longue durée entre services. C’est un progrès majeur. Mais une chaîne de confiance initiale reste nécessaire :

Élément de confiance	Rôle
Ancre de confiance (CA root)	Signe les certificats SPIFFE
Trust bundle	Distribué à tous les workloads pour vérifier les SVIDs
OIDC issuer	Le cluster publie une URL vérifiable par le cloud
Configuration de fédération	Lie le ServiceAccount K8s au rôle/identité cloud
Plugin d’attestation	Vérifie l’identité du nœud au démarrage

Glissez pour voir

Ces éléments doivent être protégés, audités et maintenus. La rotation du trust bundle, la configuration de l’OIDC issuer et les plugins d’attestation sont des surfaces d’attaque à surveiller.

En résumé

On ne supprime pas toute confiance. On remplace un secret applicatif partagé et longue durée par une infrastructure de confiance cryptographique plus robuste.

Cas d’usage

Service à service (mTLS)

Deux microservices communiquent de façon sécurisée grâce aux certificats SPIFFE. Chaque service vérifie l’identité de l’autre. Pas de secret partagé entre les deux services.

En pratique, le mTLS nécessite un point d’intégration : un proxy sidecar (Envoy, géré par un service mesh), ou une bibliothèque capable de charger les X.509-SVIDs depuis la Workload API SPIFFE.

Pod vers base de données

Au lieu d’un mot de passe DB statique :

1. Le pod a une identité SPIFFE
2. Il présente cette identité à Vault
3. Vault vérifie l’identité et génère des credentials DB dynamiques
4. Le pod se connecte à la DB avec ces credentials temporaires

C’est un usage hybride : l’identité machine (SPIFFE) est utilisée pour obtenir un secret dynamique (Vault), qui sert de credential vers un système qui ne comprend pas les certificats SPIFFE.

CI/CD vers cloud

Au lieu d’access keys stockées dans le dépôt :

1. Le workflow GitHub Actions reçoit un token OIDC
2. AWS/GCP vérifie le token auprès du fournisseur OIDC de GitHub
3. Le workflow reçoit des credentials temporaires
4. Aucun secret stocké dans le dépôt

# GitHub Actions avec OIDC vers AWS
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789:role/github-actions
          aws-region: eu-west-1

Proxy / sidecar mTLS

Dans un service mesh (Istio, Linkerd, Cilium) :

• Chaque pod a un sidecar (ou agent eBPF) avec une identité
• Le trafic inter-pod est chiffré automatiquement via mTLS
• L’autorisation est basée sur l’identité, pas sur des secrets
• L’application n’a aucune modification à faire

Identité, secret dynamique ou secret statique ?

Ce guide vient après la comparaison statiques vs dynamiques. Pour choisir la bonne approche, utilisez ce tableau :

Besoin	Approche recommandée	Pourquoi
Pod K8s vers API cloud (S3, GCS)	Workload identity native (IRSA, GKE WIF, AKS WI)	Pas de secret, fédération OIDC directe
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)	La DB ne comprend pas les certificats SPIFFE
API tierce avec clé fixe	Secret statique sous coffre-fort	L’API impose une clé, pas d’alternative
Accès SSH court	Certificat signé (Vault SSH)	Pas de clé SSH permanente
CI/CD vers cloud	OIDC federation (GitHub → AWS/GCP)	Pas d’access key stockée
Application legacy (pas de mTLS)	Secret dynamique ou statique sous coffre	L’app ne sait pas consommer des certificats

Glissez pour voir

Règle de décision

Identité machine quand le système cible sait vérifier un certificat ou un JWT. Secret dynamique quand le système cible attend un mot de passe ou une clé mais supporte la rotation. Secret statique sous coffre quand aucune alternative n’est possible.

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.

Situation	Pourquoi reporter	Commencer par
Application legacy non modifiable	Ne sait pas recharger des certificats	Secret dynamique ou statique sous coffre
API externe à clé fixe	L’API impose son modèle	Stocker la clé dans un coffre-fort
Équipe sans culture PKI/OIDC	Courbe d’apprentissage trop raide	Coffre-fort + rotation automatique
Les secrets sont encore dans le code	Priorité : sortir les secrets	Détection + coffre-fort
Infrastructure non Kubernetes	SPIFFE nécessite un runtime compatible	Vault avec auth method adaptée

Glissez pour voir

Éviter l'effet « solution idéale mais non déployable »

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.

Pré-requis techniques

Avant de déployer une solution d’identité machine, vérifiez que votre infrastructure est prête.

Pour SPIFFE/SPIRE

Pré-requis	Détail
PKI ou trust anchor	CA racine pour signer les SVIDs
SPIRE Server en haute disponibilité	Réplication, datastore partagé (PostgreSQL, MySQL)
SPIRE Agent sur chaque nœud	DaemonSet Kubernetes ou agent système
Plugin d’attestation	Adapté à l’environnement (K8s, AWS, GCP, bare metal)
Observabilité	Métriques et logs pour détecter les échecs d’attestation
Trust bundle distribution	Mécanisme pour distribuer et renouveler le bundle
Synchronisation de l’heure	NTP configuré : les certificats sont sensibles au clock drift

Glissez pour voir

Pour la fédération cloud

Pré-requis	Détail
OIDC issuer activé sur le cluster	Configuration spécifique par cloud (EKS, GKE, AKS)
Rôle IAM / identité managée	Créé avec les permissions minimales
Federated identity credential	Lien ServiceAccount K8s ↔ rôle cloud
SDK cloud compatible	L’application utilise un SDK qui détecte les credentials projetés

Glissez pour voir

Pièges courants

Piège	Conséquence	Comment l’éviter
Croire que l’identité remplace l’autorisation	Workloads authentifiés mais trop autorisés	Configurer des policies d’autorisation granulaires
Penser qu’une annotation K8s suffit	L’annotation sans configuration cluster = aucun effet	Vérifier les pré-requis cluster (OIDC issuer, WIF)
Supposer que toutes les apps gèrent mTLS	L’app crashe ou ignore le certificat	Utiliser un proxy sidecar ou un service mesh
Ignorer le renouvellement	Le certificat expire, l’app plante	Monitorer les TTL, tester les renouvellements
Multiplier les identités sans gouvernance	Explosion des SPIFFE IDs, policies ingérables	Convention de nommage + policy-as-code
Ne pas monitorer SPIRE Server	Panne silencieuse = plus de SVIDs émis	Alerting sur les métriques SPIRE

Glissez pour voir

Limites et défis

Limite	Effet réel	Mitigation
Intégration applicative	L’application ne sait pas exploiter un certificat ou un JWT SPIFFE	Passer par un proxy sidecar, un service mesh ou un SDK
Plan de contrôle critique	Panne SPIRE = émission et renouvellement impactés	Haute disponibilité, observabilité, cache local
Débogage plus difficile	Échec authentification/autorisation/transport difficile à isoler	Logs structurés sur chaque couche, métriques par service
Compatibilité partielle	Certains systèmes ne savent ni mTLS ni OIDC	Garder un secret dynamique ou statique sous coffre
Gouvernance d’identité	Explosion des identités et des politiques sans convention	Convention de nommage SPIFFE ID, policy-as-code
Distribution du trust bundle	Les workloads doivent recevoir le bundle pour vérifier les SVIDs	Bundle Federation SPIFFE, rotation planifiée
Clock drift	Les certificats sont sensibles aux écarts d’horloge	NTP configuré et surveillé sur tous les nœuds
Latence de renouvellement	Un SVID expiré avant renouvellement bloque le workload	TTL avec marge, cache local, alerte sur les échecs
Cas hybrides	Tout le SI ne parle pas SPIFFE/OIDC	Approche progressive, secret dynamique pour le legacy

Glissez pour voir

Migration progressive

1. Inventoriez les flux M2M

   Listez toutes les communications service-to-service qui utilisent des secrets partagés. Identifiez celles qui sont les plus sensibles.

2. Priorisez par criticité et faisabilité

   Commencez par les flux sensibles (paiement, données utilisateur) et compatibles (services déjà dans K8s, capacité mTLS via mesh).

3. Déployez l’infrastructure d’identité

   SPIRE pour le M2M interne, workload identity native pour les accès cloud. Les deux peuvent coexister.

4. Migrez service par service

   Remplacez les secrets partagés par mTLS avec identité ou par OIDC federation. Validez chaque migration indépendamment.

5. Gardez le secret dynamique pour le legacy

   Les systèmes qui ne supportent pas mTLS/OIDC restent sur Vault avec des credentials dynamiques.

6. Supprimez les anciens secrets

   Une fois la migration validée et observée en production, supprimez les secrets devenus inutiles.

Tableau de décision

Situation	Approche recommandée
Communication interne K8s	SPIFFE/SPIRE ou service mesh
Pod vers cloud (AWS/GCP/Azure)	Workload identity native (IRSA, GKE WIF, AKS WI)
CI/CD vers cloud	OIDC federation
Service vers DB classique	Secret dynamique (Vault)
API tierce avec clé fixe	Secret statique sous coffre-fort
Legacy sans mTLS ni OIDC	Secret dynamique (Vault)
Accès SSH court	Certificat signé (Vault SSH)

Glissez pour voir

À retenir

1. L’identité machine n’est pas un mot de passe — c’est une attestation cryptographique vérifiable
2. Deux familles — identité interne M2M (SPIFFE/SPIRE) et fédération cloud (IRSA, GKE WIF, AKS WI) répondent à des besoins différents
3. L’identité ne remplace pas l’autorisation — prouver son identité et avoir le droit d’agir sont deux choses distinctes
4. L’identité nécessite un point d’intégration — proxy, mesh, SDK ou bibliothèque applicative
5. On remplace le secret applicatif partagé, pas toute confiance — une chaîne de confiance (CA, trust bundle, OIDC issuer) reste nécessaire
6. SPIFFE est un standard majeur pour le M2M cloud-native, pas le seul modèle d’identité machine
7. L’identité machine n’est pas toujours la priorité — sortir les secrets du code et utiliser un coffre-fort viennent en premier

Prochaines étapes

HashiCorp Vault Intégration SPIFFE et secrets dynamiques

Gestion des secrets dans Kubernetes Workload identity et External Secrets

Détection de secrets Empêcher les secrets de fuiter dans le code

Secrets en CI/CD OIDC et bonnes pratiques pipelines

Hub : Gestion des secrets Retour à la vue d'ensemble

Ressources

• SPIFFE — Standard d’identité de workload (CNCF)
• SPIRE — Implémentation de référence
• SPIRE Concepts — Attestation, SVIDs, trust bundles
• GKE Workload Identity Federation — Documentation Google Cloud
• EKS IRSA — Documentation AWS
• AKS Workload Identity — Documentation Microsoft
• Using Envoy with X.509-SVIDs — Intégration proxy Envoy

×

📖 Voir la documentation →