Workload Identity

devsecops

Définition

Workload Identity est un concept générique de sécurité cloud désignant le mécanisme permettant à des workloads (applications, services, conteneurs, fonctions) de s'authentifier auprès d'autres services cloud ou APIs en utilisant une identité éphémère et vérifiable, plutôt que des credentials statiques (clés API, mots de passe). Chaque fournisseur cloud propose sa propre implémentation : IRSA sur AWS EKS, Workload Identity Federation sur GCP, Managed Identities sur Azure, et des solutions open source comme SPIFFE/SPIRE pour les environnements multi-cloud. Le problème central auquel Workload Identity répond est la gestion des "machine secrets" : dans les architectures de microservices, chaque service doit souvent s'authentifier auprès de dizaines d'autres services et APIs. Gérer ces secrets de service à service (service-to-service authentication) via des credentials statiques génère une explosion du nombre de secrets à gérer, à sécuriser et à faire tourner, augmentant la surface d'attaque et la complexité opérationnelle. GCP Workload Identity Federation permet à des workloads s'exécutant en dehors de GCP (AWS, Azure, GitHub Actions, ou on-premises) de s'authentifier auprès des APIs Google Cloud en échangeant leur token d'identité natif (token OIDC ou AWS credentials) contre des tokens Google Cloud temporaires. Cette fédération élimine le besoin de distribuer des clés de service account GCP dans des environnements tiers. Azure Managed Identities assignent automatiquement une identité Azure AD aux ressources Azure (VMs, AKS pods, App Service, Functions) qui peut être utilisée pour s'authentifier auprès des services Azure (Key Vault, Storage, SQL) sans aucun secret à gérer. La rotation des tokens est entièrement gérée par Azure. SPIFFE (Secure Production Identity Framework For Everyone) est un standard open source définissant une interface commune pour l'émission d'identités de workloads sous forme de SVIDs (SPIFFE Verifiable Identity Documents), implémenté par SPIRE (SPIFFE Runtime Environment) pour les environnements multi-cloud et hybrides. Istio et d'autres service meshes utilisent SPIFFE comme fondation pour l'authentification mTLS entre microservices.

Implémentations par fournisseur cloud

Chaque cloud propose son implémentation : AWS EKS avec IRSA et Pod Identity (tokens STS via OIDC), GCP avec Workload Identity pour GKE (Service Account Kubernetes mappé sur un Service Account GCP) et Workload Identity Federation pour les identités cross-cloud, Azure avec Managed Identities (System-assigned ou User-assigned) pour les ressources Azure, et GitHub Actions avec OIDC pour accéder aux ressources cloud sans secrets stockés dans les dépôts.

SPIFFE/SPIRE pour les environnements multi-cloud

SPIFFE définit un standard d'identité de workload (SVID au format X.509 ou JWT) indépendant du fournisseur cloud. SPIRE (le runtime SPIFFE) émet et gère ces identités en vérifiant l'identité des workloads via les mécanismes natifs de la plateforme (nœuds Kubernetes, comptes AWS, etc.). Cette couche d'abstraction permet une authentification cohérente dans les environnements hybrides et multi-cloud, utilisée par des service meshes comme Istio et Consul Connect.

GitHub Actions et Workload Identity

GitHub Actions supporte l'authentification via OIDC pour AWS, GCP, Azure et HashiCorp Vault, éliminant le stockage de credentials cloud dans les Secrets GitHub. Le job GitHub Actions reçoit un token OIDC signé par GitHub qu'il échange contre des credentials cloud temporaires. Cette approche est plus sécurisée car les permissions sont limitées au job en cours, les credentials expirent automatiquement, et aucun secret à longue durée de vie n'est stocké dans le dépôt.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis