Was ist Workload Identity? SPIFFE erklärt

Workload-Identität bezeichnet die Praxis, jeder Software-Workload – beispielsweise einem Container, Microservice, einer virtuellen Maschine oder einem automatisierten Prozess – eine eigene, verifizierbare kryptografische Identität zuzuweisen, damit sie sich ohne statische Geheimnisse gegenüber anderen Systemen authentifizieren kann. SPIFFE (Secure Production Identity Framework For Everyone) ist der offene Standard, der die Benennung, Ausstellung und Verifizierung dieser Identitäten definiert.

Die Workload-Identität weist jedem Software-Workload, wie beispielsweise einem Container, Microservice oder einer virtuellen Maschine, eine kurzlebige kryptografische Berechtigung zu. Diese basiert auf verifizierten Eigenschaften des Workloads und nicht auf einem gespeicherten Geheimnis. SPIFFE, ein CNCF-Standard, definiert das Identitätsformat und die Berechtigungstypen. SPIRE ist die Laufzeitumgebung, die diese Berechtigungsnachweise im Produktivbetrieb ausgibt und rotiert.

Wichtige Erkenntnisse

• Eine Workload-Identität authentifiziert einen Software-Workload (Container, Dienst, VM oder Prozess) mit einer verifizierten, kurzlebigen Anmeldeinformation anstelle eines API-Schlüssels oder eines gemeinsamen Geheimnisses.
• SPIFFE definiert den Standard: eine SPIFFE-ID in der Form spiffe://trust-domain/path, die als X.509-Zertifikat oder JWT namens SVID (SPIFFE Verifiable Identity Document) bereitgestellt wird.
• SPIRE, die SPIFFE-Laufzeitumgebung, vergibt SVIDs durch Knoten- und Workload-Attestierung ohne Bootstrap-Geheimnis. Beide Projekte haben im September 2022 das CNCF-Zertifikat erhalten.
• SPIRE stellt X.509 SVIDs mit einer standardmäßigen Gültigkeitsdauer von einer Stunde aus und rotiert diese automatisch, sodass gestohlene Workload-Anmeldeinformationen innerhalb einer Stunde ablaufen, anstatt monatelang gültig zu bleiben.
• NIST SP 800-207A SPIFFE wird als Anwendungsidentitätsinfrastruktur für Zero Trust in Cloud-nativen Multi-Cloud-Umgebungen bezeichnet.

Warum Workloads eine eigene Identität benötigen

In den meisten Produktionsumgebungen gibt es mittlerweile mehr Maschinen als menschliche Benutzer, und jeder Serviceaufruf zwischen diesen Maschinen erfordert eine Vertrauensentscheidung. Ein Zahlungsdienst muss sicherstellen, dass die soeben empfangene Anfrage tatsächlich vom Checkout-Service stammt und nicht von einem kompromittierten System im selben Netzwerk.

Herkömmliche Lösungsansätze für dieses Problem basieren auf Informationen, die im Workload gespeichert sind: ein API-Schlüssel in einer Umgebungsvariablen, ein Passwort in einer Konfigurationsdatei, ein Zertifikat mit dreijähriger Gültigkeit, das zwischen Hosts kopiert wurde. Statische Zugangsdaten gelangen in Quellcode-Repositories und Protokolle, bleiben lange erhalten, nachdem der Workload, der sie verwendet hat, nicht mehr existiert, und werden selten aktualisiert, da dies zu Problemen führen kann. Auch der Netzwerkstandort ist als Vertrauensindikator nicht besser geeignet, da Container Netzwerke gemeinsam nutzen, IP-Adressen innerhalb von Sekunden wiederverwendet werden und sich ein einzelner kompromittierter Host innerhalb des Netzwerkperimeters befindet.

Die Workload-Identität ersetzt das Wissen eines Dienstes (ein Geheimnis) durch seine tatsächliche Identität (eine verifizierte Identität). Die Anmeldeinformationen werden aus überprüfbaren Fakten über den Workload und seine Plattform abgeleitet, sind für Minuten oder Stunden gültig und erneuern sich automatisch.

Was ist SPIFFE?

SPIFFE (Secure Production Identity Framework For Everyone) ist ein offener Standard, der die Benennung von Workload-Identitäten, das Aussehen der Anmeldeinformationen und deren Übermittlung an Workloads definiert. Das Projekt wird von der Cloud Native Computing Foundation (CNCF) gehostet und erreichte im September 2022 den Status „Graduated“, die gleiche Reifestufe wie Kubernetes. SPIFFE definiert vier Bausteine:

• SPIFFE-ID: Ein URI der Form spiffe://trust-domain/path, beispielsweise spiffe://prod.example.com/payments/api. Die Trust-Domain bildet die administrative Grenze; ​​der Pfad benennt die darin enthaltene Arbeitslast.
• SVID: Das SPIFFE Verifiable Identity Document (SVID) ist der Nachweis der SPIFFE-ID. Ein X.509-SVID bettet die SPIFFE-ID als URI in das Feld „Subject Alternative Name“ des Zertifikats ein und wird direkt in Mutual TLS integriert. Ein JWT-SVID besitzt dieselbe Identität wie ein signiertes Token für HTTP- und API-Kontexte.
• Workload-API: Eine lokale API, die über einen Unix-Domain-Socket bereitgestellt wird, ermöglicht es einer Workload, ihre SVID und das Trust-Bundle zur Peer-Verifizierung abzurufen. Für den Aufruf der API sind keinerlei Anmeldeinformationen erforderlich; die Plattform authentifiziert den Aufrufer.
• FöderationZwei unabhängige Vertrauensdomänen können Vertrauenspakete austauschen und die Arbeitslasten der jeweils anderen verifizieren, ohne eine gemeinsame Stammzertifizierungsstelle zu benötigen. Dies ermöglicht eine Cloud- und organisationsübergreifende Authentifizierung.

SPIFFE selbst liefert keine Software aus. Es handelt sich um die Spezifikation. Die Referenzimplementierung, die in der Produktion eingesetzt wird, ist SPIRE.

Wie SPIRE Workload-Identitäten ausgibt

SPIRE, die SPIFFE-Laufzeitumgebung, vergibt Identitäten über eine Kette von Attestierungen anstelle eines verteilten Geheimnisses. Ein SPIRE-Server fungiert als Vertrauensanker für die Domäne, und auf jedem Knoten läuft ein SPIRE-Agent. Die Vergabe erfolgt in vier Schritten:

1. Knotenattestierung: Der Agent weist mithilfe von Plattformnachweisen, wie beispielsweise einem AWS-Instanzidentitätsdokument, einer von Azure verwalteten Identität oder einem Kubernetes-Dienstkontotoken, nach, auf welchem ​​Knoten er ausgeführt wird.
2. Arbeitslastbestätigung: Wenn ein Prozess die Workload-API aufruft, untersucht der Agent ihn über die Plattform: seinen Kubernetes-Namespace und sein Servicekonto, seine Unix-Benutzer-ID oder sein Container-Image.
3. SVID-Ausstellung: Der Server gleicht diese bestätigten Eigenschaften mit den Registrierungseinträgen ab und signiert eine SVID für die übereinstimmende SPIFFE-ID.
4. Automatische Drehung: Die standardmäßige Lebensdauer einer X.509-SVID in SPIRE beträgt eine Stunde, und der Agent erneuert jede SVID vor deren Ablauf. Workloads verarbeiten keine Erneuerungsereignisse.

Da die Identität durch Attestierung abgeleitet wird, gibt es kein Bootstrap-Geheimnis, das verteilt, sicher verwahrt oder weitergegeben werden müsste. Die CNCF-Abschlussankündigung nennt Bloomberg, ByteDance, Pinterest, Twilio, Uber, Netflix und GitHub als produktive Anwender, und Service-Meshes wie Istio verwenden das SPIFFE-Identitätsformat für ihre Workload-Zertifikate. Details zur Bereitstellungsarchitektur und Konfiguration finden Sie in der detaillierten Analyse von SPIFFE und SPIRE von Encryption Consulting.

Workload-Identität vs. Statische Geheimnisse

Der praktische Unterschied zwischen der Workload-Identität nach SPIFFE-Art und statischen Maschinenanmeldeinformationen zeigt sich in Lebensdauer, Rotation und Wirkungsradius.

Attribut	Statische Geheimnisse (API-Schlüssel, langlebige Zertifikate)	SPIFFE-Workload-Identität
Grundlage des Vertrauens	Was die Arbeitsbelastung beinhaltet	Wie hoch die Arbeitsbelastung ist, wird durch eine Bestätigung verifiziert.
Typische Lebensdauer	Monate bis Jahre	Standardmäßig eine Stunde in SPIRE, konfigurierbar auf Minuten.
Rotation	Handbuch, wird oft übersprungen	Automatisch, vor jedem Ablauf
Bootstrap	Das Geheimnis muss zuerst verteilt werden	Kein Bootstrap-Geheimnis; nur Plattformbestätigung
Tragbarkeit	An eine Plattform oder einen Tresor gebunden	Dieselbe spiffe://-Identität über Clouds, Cluster und VMs hinweg
Explosionsradius bei Diebstahl	Gültig, bis es jemand entdeckt und widerruft.	Begrenzt durch die verbleibenden Minuten der Gültigkeitsdauer der Anmeldeinformationen

Wo Workload-Identität in Zero Trust ihren Platz hat

Zero Trust verwendet Identität anstelle des Netzwerkstandorts als primäre Zugriffskontrolle. Die Identität der Workloads ermöglicht die Übertragung dieses Prinzips im maschinellen Datenverkehr. NIST SP 800-207 (August 2020) definiert die Zero-Trust-Architektur. Die zugehörige Cloud-Version, NIST SP 800-207A (September 2023), nennt SPIFFE explizit als Infrastruktur für Anwendungsidentität zur Zugriffskontrolle in Multi-Cloud-Umgebungen, neben API-Gateways und Sidecar-Proxys. Die NIST SP 800-204- Serie stellt denselben Zusammenhang für Service-Mesh-Bereitstellungen her, bei denen die Identität durch gegenseitiges TLS zwischen Workloads übertragen wird.

Die Standardisierung schreitet weiter voran. Die IETF-Arbeitsgruppe WIMSE (Workload Identity in Multi System Environments) definiert, wie Workload-Identitäten und -Token über Vertrauensdomänen hinweg interoperabel sind, und dieselbe Identitätsinfrastruktur wird zur Antwort auf eine neuere Frage: Wie lassen sich KI-Agenten und andere nicht-menschliche Identitäten authentifizieren, die autonom systemübergreifend agieren?

Workload-Identität benötigt weiterhin eine Enterprise-PKI.

SPIFFE ersetzt PKI nicht; es ist PKI, angewendet auf Workloads in Maschinengeschwindigkeit. Jede Vertrauensdomäne wird durch Signaturschlüssel geschützt, die als Zertifizierungsstelle fungieren. Jemand muss festlegen, wo sich die Wurzel dieser Vertrauensdomäne befindet, ihre Schlüssel schützen, ihre Rotation planen und entscheiden, ob SVIDs zu einer eigenständigen Wurzel oder zu einer übergeordneten Unternehmenszertifizierungsstelle über die UpstreamAuthority-Integration von SPIRE verkettet werden.

Das sind klassische Fragen der PKI-Governance, die mit zunehmender Anzahl von SPIFFE-Implementierungen komplexer werden: Plattformteams richten Vertrauensdomänen pro Cluster ein, täglich werden Tausende von Zertifikaten ausgestellt, und nichts davon erscheint in einem für TLS-Endpunkte erstellten Zertifikatsinventar. Eine Organisation, die ihre Workload-Zertifikate nicht einsehen kann, kann sie auch nicht auditieren, und eine auf einem Laptop generierte Vertrauensdomänen-Root ist dennoch eine Root-Domain. Die Verankerung von Vertrauensdomänen in einer verwalteten CA-Hierarchie und die Erweiterung der Zertifikatssichtbarkeit auf kurzlebige Workload-Anmeldeinformationen verwandeln ein vielversprechendes Framework in ein auditierbares Identitätsprogramm. Fundierte Kenntnisse der Grundlagen der Public-Key-Infrastruktur sind hierbei hilfreich, da jedes SPIFFE-Konzept einem zugrunde liegenden PKI-Konzept entspricht.

Wie Verschlüsselungsberatung hilft

PKI-as-a-Service bietet Ihnen eine verwaltete, HSM-gestützte Zertifizierungsstellenhierarchie, die als vorgelagerter Vertrauensanker für SPIFFE-Vertrauensdomänen dient. So werden die Anmeldeinformationen Ihrer Workloads an eine von Ihrem Unternehmen kontrollierte Stammzertifizierungsstelle gebunden, wobei Schlüsselzeremonien und -rotationen planmäßig durchgeführt werden. CertSecure Manager verwaltet Maschinen- und Workload-Zertifikate in einem zentralen Inventar, überwacht deren Ablauf und automatisiert den Lebenszyklus über Clouds und Cluster hinweg. Die Lösung basiert auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.

Häufig gestellte Fragen

Was versteht man unter Workload-Identität in einfachen Worten?

Die Workload-Identität ist wie ein Pass für Software. Anstatt dass sich eine Person anmeldet, erhält ein Container, ein Microservice oder eine virtuelle Maschine eine eigene, kurzlebige kryptografische Berechtigung, die ihre Identität beweist. Andere Dienste überprüfen diese Berechtigung vor dem Datenaustausch, ähnlich wie ein Grenzbeamter einen Pass kontrolliert. Dadurch müssen weder Passwörter noch API-Schlüssel gespeichert oder weitergegeben werden.

Worin besteht der Unterschied zwischen SPIFFE und SPIRE?

SPIFFE ist die Spezifikation, SPIRE die zugehörige Software. SPIFFE definiert das Identitätsformat (spiffe://trust-domain/path), die SVID-Anmeldeinformationstypen und die Workload-API. SPIRE, die SPIFFE-Laufzeitumgebung, zertifiziert Knoten und Workloads, vergibt SVIDs und rotiert diese automatisch. Beide Projekte wurden im September 2022 von der Cloud Native Computing Foundation zertifiziert.

Wie sieht eine SPIFFE-ID aus?

Eine SPIFFE-ID ist ein URI im Format spiffe://trust-domain/path, beispielsweise spiffe://prod.example.com/payments/api. Die Trust-Domain benennt die ausstellende Zertifizierungsstelle, und der Pfad identifiziert die spezifische Workload innerhalb dieser Domain. Dieselbe SPIFFE-ID bleibt gültig, unabhängig davon, ob die Workload in Kubernetes, auf einer virtuellen Maschine oder bei verschiedenen Cloud-Anbietern ausgeführt wird. Dadurch ist die Identität portabel.

Ersetzt SPIFFE eine PKI oder eine Zertifizierungsstelle?

Nein. SPIFFE wendet Public-Key-Infrastruktur (PKI) auf Workloads an, anstatt sie zu ersetzen. Jede SPIFFE-Vertrauensdomäne wird durch Signaturschlüssel geschützt, die als Zertifizierungsstelle fungieren, und SPIRE kann eine Verbindung zu einer übergeordneten Unternehmenszertifizierungsstelle herstellen. Organisationen benötigen weiterhin kontrollierte Schlüsselzeremonien, geschützte Stammzertifikate und Zertifikatstransparenz. Daher laufen Workload-Identitätsprogramme üblicherweise parallel zu einer verwalteten PKI.

Wie lange ist ein SPIFFE-Zertifikat (SVID) gültig?

SPIRE vergibt X.509-SVIDs mit einer Standardgültigkeitsdauer von einer Stunde. Der SPIRE-Agent erneuert diese automatisch vor Ablauf der Gültigkeitsdauer. Die Gültigkeitsdauer ist minutengenau konfigurierbar. Dank der automatischen Rotation werden Workloads nie manuell erneuert, und gestohlene Anmeldeinformationen verlieren innerhalb der verbleibenden Minuten ihrer Gültigkeitsdauer ihre Funktion, anstatt monatelang gültig zu bleiben.

Wie unterstützt die Identität von Arbeitslasten Zero Trust?

Zero Trust beseitigt implizites Vertrauen basierend auf dem Netzwerkstandort und verifiziert jede Anfrage anhand einer Identität. NIST SP 800-207 definiert diese Architektur, und NIST SP 800-207A nennt SPIFFE als Identitätsinfrastruktur für Cloud-native Multi-Cloud-Umgebungen. Die Workload-Identität liefert die verifizierbaren Dienstidentitäten, auf denen Zero-Trust-Richtlinien-Engines und Mutual TLS basieren, und erweitert das Modell somit über menschliche Benutzer hinaus auf alle Maschinen.

Die Identität der Anker-Workloads in der PKI, die Sie verwalten

Nutzen Sie PKI-as-a-Service, um Ihr Identitätsprogramm für Workloads in einer verwalteten, HSM-gestützten Zertifizierungsstellenhierarchie zu verankern, oder sprechen Sie mit einem Berater von Encryption Consulting über die Erweiterung der Zertifikatserkennung und Lebenszyklusautomatisierung auf Ihre Cluster mit CertSecure Manager. ISO 27001:2022-zertifiziert und SOC 2-konform.