Workload-Identität
Was ist Workload-Identität?
Workload-IdentitätKryptografische Identität für einen Service, Container oder eine Funktion, mit der dieser sich gegenüber anderen Systemen ohne langlebige geteilte Secrets authentifiziert.
Workload-Identität bedeutet, dass jede laufende Workload — Kubernetes-Pod, serverlose Funktion, VM, Batchjob — eigene, kurzlebige, attestierte Anmeldedaten erhält, statt geteilte statische Schlüssel zu nutzen. Cloud-native Umsetzungen umfassen GKE Workload Identity (Kubernetes-ServiceAccount auf Google-ServiceAccount gemappt), AWS IAM Roles for Service Accounts (IRSA) via OIDC-Federation, Azure Workload Identity und SPIFFE/SPIRE-Identitäten. Workloads holen Tokens oder X.509-SVIDs über einen lokalen vertrauenswürdigen Endpunkt (IMDS, kubelet, Agent) und nutzen sie für Cloud-APIs, Datenbanken oder andere Dienste. Das Modell ist Grundlage für Zero Trust und begrenzt den Schaden bei Credential-Leaks.
● Beispiele
- 01
GKE Workload Identity: Pod ruft Cloud Storage mit der gemappten Google-ServiceAccount auf.
- 02
AWS IRSA: EKS-Pod übernimmt eine IAM-Rolle über ein projiziertes OIDC-Token.
● Häufige Fragen
Was ist Workload-Identität?
Kryptografische Identität für einen Service, Container oder eine Funktion, mit der dieser sich gegenüber anderen Systemen ohne langlebige geteilte Secrets authentifiziert. Es gehört zur Kategorie Cloud-Sicherheit der Cybersicherheit.
Was bedeutet Workload-Identität?
Kryptografische Identität für einen Service, Container oder eine Funktion, mit der dieser sich gegenüber anderen Systemen ohne langlebige geteilte Secrets authentifiziert.
Wie funktioniert Workload-Identität?
Workload-Identität bedeutet, dass jede laufende Workload — Kubernetes-Pod, serverlose Funktion, VM, Batchjob — eigene, kurzlebige, attestierte Anmeldedaten erhält, statt geteilte statische Schlüssel zu nutzen. Cloud-native Umsetzungen umfassen GKE Workload Identity (Kubernetes-ServiceAccount auf Google-ServiceAccount gemappt), AWS IAM Roles for Service Accounts (IRSA) via OIDC-Federation, Azure Workload Identity und SPIFFE/SPIRE-Identitäten. Workloads holen Tokens oder X.509-SVIDs über einen lokalen vertrauenswürdigen Endpunkt (IMDS, kubelet, Agent) und nutzen sie für Cloud-APIs, Datenbanken oder andere Dienste. Das Modell ist Grundlage für Zero Trust und begrenzt den Schaden bei Credential-Leaks.
Wie schützt man sich gegen Workload-Identität?
Schutzmaßnahmen gegen Workload-Identität kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Workload-Identität?
Übliche alternative Bezeichnungen: Service-Identität, Pod-Identität.
● Verwandte Begriffe
- cloud-security№ 1078
SPIFFE
Offener Standard zur Vergabe kryptografischer, portabler Identitäten an Workloads über URI-basierte SPIFFE-IDs und kurzlebige X.509- oder JWT-SVIDs.
- cloud-security№ 1079
SPIRE-Runtime
Open-Source-Referenzimplementierung von SPIFFE: ein Server-Agent-System, das Workloads attestiert und kurzlebige X.509- oder JWT-SVIDs ausstellt.
- cloud-security№ 1014
Service-Mesh-Sicherheit
Sammlung von Identitäts-, Verschlüsselungs- und Autorisierungskontrollen, die ein Service Mesh bereitstellt, um Service-zu-Service-Traffic in Cloud-Native-Umgebungen abzusichern.
- cloud-security№ 559
Istio-Sicherheit
Sicherheits-Feature-Set des Istio-Service-Mesh: Workload-Identität via SPIFFE, automatisches mTLS und AuthorizationPolicy/RequestAuthentication für feingranulare Zugriffskontrolle.
- network-security№ 1262
Zero Trust Network
Eine Netzwerkarchitektur, die Nutzer, Geräte oder Dienste niemals automatisch vertraut und jede Verbindung kontinuierlich identitätsbasiert prüft.
- identity-access№ 1011
Dienstkonto
Eine nichtmenschliche Identität, die eine Anwendung, ein Skript oder ein Dienst zur Authentifizierung gegenüber anderen Systemen nutzt, üblicherweise ohne interaktive Anmeldung.