Identité de Workload
Qu'est-ce que Identité de Workload ?
Identité de WorkloadIdentité cryptographique attribuée à un service, un conteneur ou une fonction pour s'authentifier auprès d'autres systèmes sans secrets partagés longue durée.
L'identité de workload consiste à donner à chaque charge en exécution — pod Kubernetes, fonction serverless, VM, job batch — ses propres identifiants attestés et courts, plutôt que de partager des clés statiques. Les implémentations cloud-native incluent GKE Workload Identity (service account Kubernetes mappé à un service account Google), AWS IAM Roles for Service Accounts (IRSA) via fédération OIDC, Azure Workload Identity, ainsi que les identités SPIFFE/SPIRE. Les workloads obtiennent des jetons ou SVID X.509 via un endpoint local de confiance (IMDS, kubelet, agent) et les utilisent pour appeler des API cloud, bases de données ou autres services. Ce modèle est la base du zero trust et limite le rayon d'impact en cas de fuite.
● Exemples
- 01
GKE Workload Identity permet à un pod d'appeler Cloud Storage avec son service account Google mappé.
- 02
AWS IRSA : un pod EKS endosse un rôle IAM via un jeton OIDC projeté.
● Questions fréquentes
Qu'est-ce que Identité de Workload ?
Identité cryptographique attribuée à un service, un conteneur ou une fonction pour s'authentifier auprès d'autres systèmes sans secrets partagés longue durée. Cette notion relève de la catégorie Sécurité du cloud en cybersécurité.
Que signifie Identité de Workload ?
Identité cryptographique attribuée à un service, un conteneur ou une fonction pour s'authentifier auprès d'autres systèmes sans secrets partagés longue durée.
Comment fonctionne Identité de Workload ?
L'identité de workload consiste à donner à chaque charge en exécution — pod Kubernetes, fonction serverless, VM, job batch — ses propres identifiants attestés et courts, plutôt que de partager des clés statiques. Les implémentations cloud-native incluent GKE Workload Identity (service account Kubernetes mappé à un service account Google), AWS IAM Roles for Service Accounts (IRSA) via fédération OIDC, Azure Workload Identity, ainsi que les identités SPIFFE/SPIRE. Les workloads obtiennent des jetons ou SVID X.509 via un endpoint local de confiance (IMDS, kubelet, agent) et les utilisent pour appeler des API cloud, bases de données ou autres services. Ce modèle est la base du zero trust et limite le rayon d'impact en cas de fuite.
Comment se défendre contre Identité de Workload ?
Les défenses contre Identité de Workload combinent habituellement des contrôles techniques et des pratiques opérationnelles, comme détaillé dans la définition ci-dessus.
Quels sont les autres noms de Identité de Workload ?
Noms alternatifs courants : Identité de service, Identité de pod.
● Termes liés
- cloud-security№ 1078
SPIFFE
Standard ouvert pour attribuer des identités cryptographiques portables aux workloads via des SPIFFE IDs sous forme d'URI et des SVID X.509 ou JWT à courte durée de vie.
- cloud-security№ 1079
Runtime SPIRE
Implémentation open source de référence de SPIFFE : un système serveur-agent qui atteste les workloads et émet des SVID X.509 ou JWT à courte durée de vie.
- cloud-security№ 1014
Sécurité du Service Mesh
Ensemble de contrôles d'identité, de chiffrement et d'autorisation qu'un service mesh fournit pour sécuriser le trafic service-à-service en environnement cloud-native.
- cloud-security№ 559
Sécurité Istio
Ensemble des fonctionnalités de sécurité d'Istio : identité de workload via SPIFFE, mTLS automatique et AuthorizationPolicy/RequestAuthentication pour un contrôle d'accès fin.
- network-security№ 1262
Réseau Zero Trust
Architecture qui ne fait jamais confiance par défaut aux utilisateurs, terminaux ou services et impose une vérification continue, basée sur l'identité, de chaque connexion.
- identity-access№ 1011
Compte de service
Identité non humaine utilisée par une application, un script ou un service pour s'authentifier auprès d'autres systèmes, généralement sans connexion interactive.