SPIFFE und SPIRE erklärt: Workload-Identifizierung im großen Maßstab

Moderne Anwendungen laufen nicht mehr auf wenigen statischen Servern. Sie sind in Kubernetes-Clustern , Containern, Service-Meshes, Cloud-Plattformen und hybriden Umgebungen verfügbar, in denen Workloads ständig erstellt, verschoben, skaliert und gelöscht werden. Unter diesen Bedingungen sind traditionelle Identitätsmerkmale wie IP-Adressen, Hostnamen, gemeinsame Geheimnisse und langlebige Anmeldeinformationen schwer zu verwalten und wenig vertrauenswürdig.

Das Secure Production Identity Framework for Everyone (SPIFFE) bietet eine standardisierte Methode zur Zuweisung kryptografisch verifizierbarer Identitäten zu Workloads, während die SPIFFE Runtime Environment (SPIRE) dieses Framework in der Produktion implementiert. Beide haben den CNCF-Reifegrad erreicht , was durch die öffentliche CNCF-Ankündigung vom 20. September 2022 unterstrichen wird und ihre Reife und Verbreitung widerspiegelt. Gemeinsam ermöglichen sie sichere Dienst-zu-Dienst-Authentifizierung, Mutual TLS (mTLS) und Zero-Trust-Modelle ohne manuell verwaltete Anmeldeinformationen.

Mit der zunehmenden Einführung cloudnativer Architekturen in Unternehmen gewinnt die Identität von Workloads ebenso an Bedeutung wie die Benutzeridentität. Für Plattformingenieure, Sicherheitsarchitekten und PKI-Teams wird es daher immer wichtiger zu verstehen, wie SPIFFE und SPIRE funktionieren und welchen Stellenwert sie innerhalb von PKI- und Zero-Trust-Initiativen im Unternehmen einnehmen.

Warum die Workload-Identität wichtig ist

Traditionell stand bei der Identitätsverwaltung der Benutzer im Mittelpunkt. Mitarbeiter authentifizieren sich mit Passwörtern, Multi-Faktor-Authentifizierung, Smartcards oder Zertifikaten, um auf Systeme und Anwendungen zuzugreifen. Moderne Umgebungen umfassen jedoch weitaus mehr Maschinen, Dienste, Container, APIs und automatisierte Prozesse als menschliche Benutzer.

Jeder API-Aufruf, jede Serviceanfrage, jede Workload-Bereitstellung und jede Container-Interaktion erfordert Vertrauen. Eine Anwendung benötigt eine zuverlässige Methode, um die Legitimität einer anderen Workload zu überprüfen, bevor sensible Informationen ausgetauscht werden. Traditionell setzten Unternehmen auf gemeinsam genutzte API-Schlüssel, statische Geheimnisse , langlebige Zertifikate, hostnamenbasiertes Vertrauen und Netzwerkperimeterkontrollen.

Diese Vorgehensweisen führen zu Betriebs- und Sicherheitsproblemen. Geheimnisse lassen sich nur schwer rotieren, Hostnamen ändern sich in dynamischen Umgebungen häufig, und statische Anmeldeinformationen bleiben oft lange aktiv, obwohl sie eigentlich deaktiviert werden sollten. Ein durchgesickerter API-Schlüssel kann monatelang Zugriff gewähren, bevor es jemand bemerkt.

Zero Trust , wie in NIST SP 800-207 definiert , ist ein Sicherheitsmodell, das keinen Netzwerkstandort als implizit vertrauenswürdig einstuft und die kontinuierliche Überprüfung von Identität und Autorisierungskontext erfordert, bevor Zugriff auf Ressourcen gewährt wird. Workloads benötigen daher starke Identitäten, die unabhängig von der sie hostenden Infrastruktur authentifiziert und autorisiert werden können. SPIFFE wurde genau für dieses Problem entwickelt.

Was ist SPIFFE?

SPIFFE ist eine Open-Source-Spezifikation, die die Identität von Workloads plattform- und umgebungsübergreifend standardisiert. Anstatt einen Workload über Hostnamen, IP-Adresse oder eine Cloud-spezifische Kennung zu identifizieren, weist SPIFFE jedem Workload eine eindeutige SPIFFE-ID in Form eines URI zu.

Eine SPIFFE-ID hat die Form spiffe://trust-domain/workload-path, beispielsweise spiffe://company.internal/payment-api. Sie identifiziert eine Workload innerhalb einer definierten Trust-Domain eindeutig. Der entscheidende Vorteil ist die Portabilität, da dieselbe Identität unabhängig davon gilt, ob die Workload in Kubernetes , einer virtuellen Maschine, einem lokalen Rechenzentrum oder einer Public Cloud ausgeführt wird.

SPIFFE selbst stellt keine Zertifikate aus und verwaltet keine Workloads. Es definiert das Identitätsformat, die Struktur von Vertrauensdomänen und Vertrauensbündeln, die SVID-Dokumentformate sowie die Workload-API, über die Identitäten bereitgestellt werden. Kurz gesagt: SPIFFE ist der Standard, nicht das laufende System. Die Infrastruktur, die diesen Standard umsetzt, ist SPIRE.

Was ist SPIRE?

SPIRE ist die am weitesten verbreitete Referenzimplementierung der SPIFFE-Spezifikationen, obwohl auch andere Tools wie Istio und Consul Teile der SPIFFE-Spezifikation implementieren. Während SPIFFE die Regeln definiert, stellt SPIRE die Infrastruktur zu deren Durchsetzung bereit. Vereinfacht gesagt: Wenn SPIFFE die Spezifikation für das Aussehen eines Reisepasses ist, ist SPIRE die Instanz, die Identitäten prüft und die Pässe ausstellt. Es fungiert als Kontrollebene für die Workload-Identität, die Workload-Identitäten durch Attestierung verifiziert, Workload-Anmeldeinformationen ausstellt, Vertrauenspakete bereitstellt, Identitäten automatisch rotiert und die Föderation zwischen Vertrauensdomänen ermöglicht.

Eine typische SPIRE-Implementierung umfasst eine kleine Anzahl von Komponenten, von denen jede eine bestimmte Rolle hat, wie in der folgenden Tabelle zusammengefasst:

Komponente	Zweck
SPIRE-Server	Zentrale Identitätsbehörde, die SPIFFE-verifizierbare Ausweisdokumente (SVIDs) unterzeichnet und ausstellt
SPIRE-Agent	Wird auf jedem Knoten ausgeführt, testet Workloads und stellt die Workload-API bereit.
Workload-API	Eine lokale gRPC-Schnittstelle, die über einen Unix-Domain-Socket bereitgestellt wird, ermöglicht es Workloads, ihre SVIDs zur Laufzeit abzurufen. Der Agent ermittelt die Identität des Aufrufers mithilfe von Mechanismen auf Betriebssystemebene, und Workloads müssen keine Authentifizierungsdaten vorlegen.
Registrierungseinträge	Definieren Sie, welche Workloads welchen Identitäten zugeordnet werden dürfen.
Vertrauenspakete	Definieren Sie die vertrauenswürdigen Aussteller und Vertrauensdomänen, die zur Überprüfung von SVIDs verwendet werden.

Standardmäßig fungiert der SPIRE-Server als eigene Zertifizierungsstelle, kann aber an eine übergeordnete Zertifizierungsstelle angebunden werden, sodass die Zertifikatsausstellung in eine bestehende PKI-Hierarchie integriert wird. Das Ergebnis ist ein System, in dem Workloads automatisch kurzlebige Identitäten erhalten , ohne dass Zertifikate manuell bereitgestellt oder Geheimnisse verteilt werden müssen, sofern Registrierungseinträge definiert wurden.

SVIDs: Der Kern der SPIFFE-Identität

Die im Rahmen des SPIFFE-Frameworks ausgestellte Berechtigung ist das SPIFFE Verifiable Identity Document (SVID). Ein SVID ist der kryptografische Nachweis der Identität einer Workload und enthält eine einzelne, in einem verifizierbaren Dokument kodierte SPIFFE-ID. SPIFFE unterstützt zwei Formate.

SVID-Typ	Typische Verwendung
X.509-SVID	Gegenseitige TLS-Authentifizierung zwischen Diensten
JWT-SVID	Tokenbasierte Authentifizierung für APIs und HTTP-Dienste

Das X.509-SVID-Format ist am weitesten verbreitet, da es sich nahtlos in TLS- und Service-Mesh-Umgebungen integriert. In einem X.509-SVID wird die SPIFFE-ID im Feld „Subject Alternative Name“ (SAN) des Zertifikats als URI zusammen mit dem öffentlichen Schlüssel, der Gültigkeitsdauer und den Informationen zur Vertrauenskette übertragen. X.509-SVIDs werden im Allgemeinen für den Datenverkehr zwischen Diensten bevorzugt, während JWT-SVIDs für Fälle vorgesehen sind, in denen ein Bearer-Token unumgänglich ist, beispielsweise bei der Identitätsübertragung über einen L7-Proxy oder ein API-Gateway. Da ein JWT-SVID ein Bearer-Token ist, kann es von jedem, der es erhält, wiederholt verwendet werden. Ein X.509-SVID erfordert hingegen zusätzlich den Besitz des zugehörigen privaten Schlüssels.

Im Gegensatz zu herkömmlichen Zertifikaten, die monate- oder jahrelang gültig sein können, sind SVIDs bewusst kurzlebig, üblicherweise nur eine Stunde, und werden nach etwa der Hälfte ihrer Gültigkeitsdauer automatisch erneuert. Dies reduziert das Risiko kompromittierter Anmeldeinformationen und entspricht den Zero-Trust- Prinzipien. Die Vertrauenswürdigkeit dieser kurzlebigen Anmeldeinformationen hängt vom Attestierungsprozess ab, der regelt, wie SPIRE jede Arbeitslast vor der Ausstellung überprüft.

Wie funktioniert die SPIRE-Attestierung?

Die Attestierung ist das, was SPIRE vertrauenswürdig macht. Bevor SPIRE eine Identität ausstellt, muss es überprüfen, ob die anfordernde Arbeitslast legitim ist. Dies geschieht in zwei Schritten.

Bei der Knotenattestierung weist der Knoten, auf dem die Arbeitslast ausgeführt wird, seine Identität gegenüber dem SPIRE-Server nach. Je nach Umgebung können hierfür Kubernetes-Knoteninformationen, Metadaten der Cloud-Anbieterinstanz, ein Hardware-Root of Trust wie ein Trusted Platform Module (TPM) oder andere plattformspezifische Nachweise verwendet werden. Sobald der Knoten als vertrauenswürdig eingestuft wurde, stellt SPIRE eine sichere Verbindung zum darauf ausgeführten Agenten her.

Bei der Workload-Attestierung verifiziert SPIRE den Workload selbst. In Kubernetes können die verwendeten Selektoren Namespace, Service Account, Pod-Labels und Container-Metadaten umfassen. SPIRE wertet diese Attribute anhand seiner Registrierungseinträge aus, bevor eine Identität vergeben wird. Dieses Modell ist deutlich robuster als die Verwendung von IP-Adressen oder DNS-Namen, die sich in dynamischen Umgebungen häufig ändern, da die Identität auf der Art des Workloads und seinem Ausführungsort basiert und nicht auf einem darin enthaltenen Geheimnis.

Wie aktivieren SPIFFE und SPIRE mTLS?

Einer der größten Vorteile von SPIFFE und SPIRE ist die vereinfachte gegenseitige TLS- Verschlüsselung. Die Implementierung von mTLS erfordert traditionell die Ausstellung und Verteilung von Zertifikaten, die Verwaltung der Vertrauenskette, die Automatisierung der Erneuerung und die Planung des Widerrufs, und jeder dieser Schritte kann zu einem operativen Engpass werden.

Mit SPIFFE und SPIRE erhalten Workloads automatisch X.509-SVIDs und Trust Bundles über die Workload-API. Diese Identitäten werden direkt für mTLS verwendet. Der Ablauf ist einfach: Der Workload wird attestiert, SPIRE stellt eine X.509-SVID aus, das Trust Bundle wird zugestellt, die beiden Dienste authentifizieren sich gegenseitig über Mutual TLS, und SPIRE rotiert die Identität automatisch vor deren Ablauf.

Wenn ein Dienst seine X.509-SVID übermittelt, validiert der empfangende Dienst das Zertifikat anhand des Vertrauenspakets und prüft die SPIFFE-ID anhand seiner Autorisierungsrichtlinie. Dies reduziert die operative Komplexität und verbessert gleichzeitig die Sicherheit durch kurzlebige Anmeldeinformationen und deren automatische Rotation.

SPIFFE und SPIRE im Vergleich zur traditionellen Workload-Authentifizierung

Der Kontrast zu herkömmlichen Ansätzen erklärt, warum SPIFFE in vielen Cloud-nativen Ökosystemen zu einer grundlegenden Technologie geworden ist. Die folgende Tabelle vergleicht die beiden Ansätze anhand von sieben Schlüsselaspekten:

Gebiet	Traditioneller Ansatz	SPIFFE und SPIRE
Identitätsquelle	Hostnamen, Geheimnisse, API-Schlüssel	Kryptografisch verifizierte Workload-Identität
Lebenszyklus von Anmeldeinformationen	Manuelle Ausgabe und Rotation	Automatisierte Ausstellung und Verlängerung
Vertrauensmodell	Anwendungsspezifisch	Standardisiert über verschiedene Umgebungen hinweg
mTLS-Bereitstellung	Komplex und größtenteils manuell	Auf der Grundlage der Workload-Identität aufgebaut
Föderation	Benutzerdefinierte Integrationen	Native Trust-Domain-Föderation
Gültigkeitsdauer der Anmeldeinformationen	Oft langlebig	Absichtlich kurzlebig
Ausrichtung auf Zero Trust	Begrenzt	Starke Ausrichtung

Wo SPIFFE und SPIRE in moderne Architekturen passen

SPIFFE und SPIRE sind besonders wertvoll bei hochdynamischen Workloads. In Kubernetes-Plattformen wechseln containerisierte Workloads ihren Standort, skalieren automatisch und haben kurze Lebenszyklen. Daher ist eine stabile, infrastrukturunabhängige Identität ein klarer Vorteil. In Service-Mesh-Umgebungen können Mesh-Datenebenen SPIFFE-basierte Identitäten zur Workload-Authentifizierung und zur Durchsetzung von mTLS nutzen.

In Multi-Cloud-Architekturen profitieren Organisationen, die Workloads über mehrere Public Clouds und On-Premise-Umgebungen verteilen, von einem einheitlichen Identitätsframework anstelle unterschiedlicher Modelle pro Plattform. Für Zero-Trust- Initiativen, bei denen die NIST-Richtlinien eine starke Identitätsprüfung betonen, bietet SPIFFE eine praktische Identitätsschicht für die maschinelle Kommunikation. Durch Federation können sich Workloads in separaten Vertrauensdomänen gegenseitig authentifizieren, indem sie Vertrauenspakete austauschen – ohne benutzerdefinierte Identitätsübersetzung. Um diese Vorteile zu nutzen, müssen häufige Implementierungsfehler vermieden werden, die Teams bei der Einführung von SPIFFE und SPIRE begegnen.

Häufige Fehler, die Organisationen machen

Viele Teams betrachten SPIFFE und SPIRE lediglich als weitere Zertifikatsverwaltungsplattformen , was zu Fehlentscheidungen in der Architektur führt. Am häufigsten wird der Fokus ausschließlich auf die Zertifikatsausstellung gelegt, während die Attestierung vernachlässigt wird. Die Attestierung ist jedoch entscheidend für die Vertrauenswürdigkeit einer Workload-Identität, und ohne präzise definierte Attestierungsrichtlinien sinkt die Identitätssicherheit rapide.

Ein weiterer Fehler besteht darin, die Föderation als Nebensache zu behandeln. Die Föderation führt zu Vertrauensbeziehungen zwischen Domänen und muss daher gezielt durch Richtlinien und Lebenszyklusmanagement gesteuert werden. Teams unterschätzen zudem häufig die operative Abhängigkeit von SPIRE selbst. Wenn die SPIRE-Server, -Agenten oder die Workload-API nicht verfügbar sind, können Workloads ihre Identitäten möglicherweise nicht erhalten oder erneuern. Überwachung, Hochverfügbarkeitsplanung und Lebenszyklusmanagement sind daher unerlässlich für die zuverlässige Bereitstellung von Workload-Identitäten. Schließlich führt die Bereitstellung von SPIFFE neben einer bestehenden PKI ohne klare Definition von Vertrauensgrenzen zu sich überschneidenden Identitätsmodellen, die mit der Zeit schwer zu verwalten werden.

Best Practices für die Sicherheit

Organisationen, die SPIFFE und SPIRE implementieren, sollten einige wenige Praktiken in den Mittelpunkt stellen.

• Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, kurzlebige SVIDs und die Rotation zu automatisieren, da kurze Gültigkeitsdauern von Anmeldeinformationen das Risiko einer Identitätskompromittierung deutlich verringern.
• Schützen Sie die Signaturschlüssel von Vertrauensdomänen mit hardwaregestützten Kontrollmechanismen wie FIPS 140-3 Level 2 oder höher (validiert). Hardware-SicherheitsmoduleDenn die Sicherheit der gesamten Vertrauensdomäne hängt von diesen Schlüsseln ab.
• Die Richtlinien zur Bestätigung von Arbeitslasten sollten eng gefasst sein, sodass nur genehmigte Arbeitslasten eine Identität erhalten können.
• Um Ausfälle bei der Identitätsausstellung zu vermeiden, sollten SPIRE-Server und -Agenten hochverfügbar betrieben werden.
• Die Verwaltung von Föderationen und Vertrauensbündeln muss so gesteuert werden, dass externe Vertrauensbeziehungen kontrollierbar und überprüfbar bleiben.
• SPIFFE sollte eher mit umfassenderen PKI-, Zertifikatsverwaltungs- und Zero-Trust-Programmen verknüpft werden, als die Workload-Identität als separates Silo zu betreiben.

In Kombination angewendet, gewährleisten diese Praktiken eine robuste und kontrollierbare Workload-Identitätsbereitstellung auch bei wachsendem Umfang. Da SVIDs kurzlebig sind und automatisch rotiert werden, eignet sich eine SPIFFE- und SPIRE-Implementierung auch hervorragend für kryptografische Agilität : Mit der Einführung der Post-Quanten-Standards des NIST ( FIPS 203 , FIPS 204 und FIPS 205 , finalisiert im August 2024) lassen sich häufig rotierte Workload-Anmeldeinformationen wesentlich einfacher auf neue Algorithmen migrieren als langlebige Zertifikate.

Wie Verschlüsselungsberatung helfen kann

„Mit der Einführung von Kubernetes, Service-Mesh-Plattformen und Zero-Trust-Architekturen in Unternehmen wird die Identitätsverwaltung von Workloads oft zu einem der komplexesten Aspekte der Sicherheitstransformation. Viele Teams haben Schwierigkeiten, den passenden Platz für SPIFFE und SPIRE neben bestehender PKI, Zertifikatslebenszyklusmanagement und Cloud-nativen Kontrollen zu finden.“

Encryption Consulting unterstützt Unternehmen bei der Konzeption und Implementierung von Identitätsarchitekturen für Workloads, die sowohl den betrieblichen Anforderungen als auch den Sicherheitszielen entsprechen. Mit Enterprise PKI Services hilft EC bei der Entwicklung von Vertrauensdomänenarchitekturen, berät zur Integration von SPIFFE und SPIRE in bestehende PKI-Infrastrukturen, definiert Attestierungsrichtlinien und entwickelt skalierbare Frameworks für die Identitätsverwaltung. Dazu gehört auch die Beratung, ob SPIRE an eine übergeordnete Zertifizierungsstelle angebunden werden sollte.

Für Organisationen, die große Zertifikatsökosysteme verwalten, bietet CertSecure Manager eine zentrale Übersicht über Zertifikatsbestände, Lebenszyklusereignisse und die Einhaltung von Richtlinien im gesamten Unternehmen. Dies unterstützt Sicherheitsteams bei der Aufrechterhaltung der Governance, während Workload-Identitäten über Cluster und Clouds hinweg zunehmen. Die Encryption Advisory Services von EC helfen bei der Bewertung von Workload-Identitätsstrategien, der Reduzierung des Identitäts-Wildwuchses und der Erstellung einer Roadmap zur Angleichung von SPIFFE und SPIRE an umfassendere Zero-Trust- und Maschinenidentitätsprogramme. Ziel ist es nicht einfach, eine weitere Identitätsplattform einzuführen, sondern eine skalierbare, robuste Vertrauensarchitektur für moderne verteilte Systeme zu entwickeln.

Fazit

Mit zunehmender Dynamik verteilter Systeme stoßen traditionelle Ansätze zur Workload-Authentifizierung an ihre Grenzen. Statische Geheimnisse, hostbasiertes Vertrauen und manuell verwaltete Anmeldeinformationen können mit Cloud-nativen Architekturen, Kubernetes und den Anforderungen von Zero Trust nicht mehr Schritt halten.

SPIFFE und SPIRE bieten einen standardisierten Ansatz für die Workload-Identität, der sichere Service-zu-Service-Authentifizierung, automatische Rotation, mTLS und domänenübergreifendes Vertrauen unterstützt. Durch die Kombination starker Attestierung mit kurzlebigen kryptografischen Identitäten bieten sie eine praktische Grundlage für die Absicherung moderner Anwendungen im großen Maßstab.

Für Unternehmen, die Cloud-native Plattformen entwickeln, ist die Einführung von Workload-Identität nicht mehr nur eine Sicherheitsverbesserung. Sie wird zu einer grundlegenden Voraussetzung für den sicheren und effizienten Betrieb verteilter Systeme. Ein sinnvoller erster Schritt ist die Analyse, wo Workloads aktuell auf statische Geheimnisse oder hostbasiertes Vertrauen angewiesen sind. Anschließend sollten SPIFFE und SPIRE zunächst anhand einiger wichtiger Dienste getestet werden, bevor die Implementierung ausgeweitet wird. Um diese Schritte zu planen und mit Ihrer bestehenden PKI abzustimmen, wenden Sie sich an das Team von Encryption Consulting.

Erstellen Sie Workload-Identitäten auf einer Grundlage, die Sie selbst verwalten können. CertSecure Manager bietet Sicherheitsteams zentrale Transparenz und Kontrolle über den gesamten Lebenszyklus von Zertifikaten und Workload-Identitäten – auch bei der Skalierung über Cluster, Clouds und verteilte Anwendungen hinweg. Demo buchen