Sichere Maschinenidentitäten mit SPIFFE und SPIRE
Sag mir, wer du bist
Veröffentlicht in Ausgabe 04/2026 - SCHWERPUNKT
In der Praxis zeigt sich die Dynamik moderner Plattformen vor allem im Umgang mit Identitäten. Klassische Mechanismen wie API-Keys, statische Zertifikate oder manuell gepflegte IAM-Rollen setzen auf langlebige Zugangsdaten und feste Zuordnungen. Diese werden in Konfigurationsdateien, Environment-Variablen oder CI/CD-Pipelines hinterlegt und dadurch zwangsläufig vervielfältigt und dauerhaft verfügbar gehalten. Auch der Einsatz moderner Secrets-Manager ändert am Grundprinzip wenig: Die Geheimnisse bleiben statisch und müssen weiterhin verteilt, rotiert und abgesichert werden.
Diese Problematik betrifft nicht nur Applikations-Workloads, sondern auch Infrastruktur- und Managementprozesse wie Orchestrierungs-APIs, Telemetrie-Dienste oder Service-Meshes. Überall dort, wo Prozesse miteinander kommunizieren, muss vorab ein legitimes Vertrauensverhältnis festgestellt werden. Gängige Ansätze stoßen hierbei an ihre Grenzen:
- IP-basierte Vertrauensmodelle sind in dynamischen Cloudumgebungen unzuverlässig und schwer wartbar.
In der Praxis zeigt sich die Dynamik moderner Plattformen vor allem im Umgang mit Identitäten. Klassische Mechanismen wie API-Keys, statische Zertifikate oder manuell gepflegte IAM-Rollen setzen auf langlebige Zugangsdaten und feste Zuordnungen. Diese werden in Konfigurationsdateien, Environment-Variablen oder CI/CD-Pipelines hinterlegt und dadurch zwangsläufig vervielfältigt und dauerhaft verfügbar gehalten. Auch der Einsatz moderner Secrets-Manager ändert am Grundprinzip wenig: Die Geheimnisse bleiben statisch und müssen weiterhin verteilt, rotiert und abgesichert werden.
Diese Problematik betrifft nicht nur Applikations-Workloads, sondern auch Infrastruktur- und Managementprozesse wie Orchestrierungs-APIs, Telemetrie-Dienste oder Service-Meshes. Überall dort, wo Prozesse miteinander kommunizieren, muss vorab ein legitimes Vertrauensverhältnis festgestellt werden. Gängige Ansätze stoßen hierbei an ihre Grenzen:
- IP-basierte Vertrauensmodelle sind in dynamischen Cloudumgebungen unzuverlässig und schwer wartbar.
- Statische Passwörter und API-Keys sind kaum auditierbar.
- OAuth2/OpenID-Tokens hängen weiterhin von initialen Secrets ab und sind für Infrastruktur-Use-Cases oft unpraktisch.
- PKI-basierte Zertifikate bieten zwar eine hohe Sicherheit, sind ohne durchgängige Automatisierung jedoch aufwendig und für kurzlebige Prozesse ineffizient.
Allen Verfahren gemeinsam ist das Bootstrap-Problem: Ein Dienst benötigt initiale Secrets, um sich gegenüber einem anderen System auszuweisen. Genau diese bilden jedoch einen permanenten Angriffspunkt. Hinzu kommen komplexe Rotationsprozesse, schwer nachvollziehbare Berechtigungsstrukturen und eine eingeschränkte Auditierbarkeit. Im Tagesbetrieb äußert sich dies in erhöhtem Pflegeaufwand, Unsicherheit bei Änderungen und einer wachsenden Angriffsfläche.
SPIFFE-Grundlagen: SVIDs und Trusted Domains
SPIFFE (Secure Production Identity Framework for Everyone) adressiert diese strukturellen Defizite mit einem herstellerneutralen Identitätsmodell für Work-loads. Jeder Workload erhält eine eindeutige, kryptografisch verifizierbare Identität, die automatisch ausgestellt und regelmäßig erneuert wird.
SPIFFE-Identitäten folgen einem URL-Namensschema und weisen dieses Format auf:
spiffe://<trust-domain>/<workload-id>
Eine SPIFFE-ID beschreibt, was ein Work-load ist, unabhängig davon, wo er läuft. Somit lassen sich etwa mit "spiffe://trust-domain/webshop/payment-backend" und "spiffe://trust-domain/ shop/payment-process" zwei Workloads eindeutig identifizieren. Die eigentlichen Identitätsnachweise erfolgen über kurzlebige SVIDs (SPIFFE Verifiable Identity Documents) in Form von X.509-Zertifikaten oder JWTs.
Um Identität und Infrastruktur konsequent voneinander zu entkoppeln, baut SPIFFE auf dem PKI-Modell auf und bindet eine Trust Domain mit einer selbst erstellten Root Certificate Authority (Root-CA), die als alleiniger Vertrauens-anker fungiert. Unterhalb der Root-CA werden dezentrale Intermediate-CAs betrieben, welche kurzlebige Identitätsnachweise für Workloads ausstellen. Diese Hierarchie erlaubt sichere Schlüsselrotation, reduziert den Schaden bei Kompromittierungen und vermeidet eine Kopplung der Infrastruktur. Ergänzt wird das Modell durch die Föderation mehrerer Trust Domains, bei der Root-CA-Zertifikate ausgetauscht werden.
SPIFFE definiert dafür praxisreife Mechanismen, die SPIRE implementiert. Dazu zählen eine automatisierte Ausstellung und Rotation kurzlebiger Zertifikate, signierte JWTs zur Integration in bestehende OAuth2- und API-Security-Konzepte sowie die Bereitstellung von Schlüsselmaterial für mTLS und Zero-Trust-Kommunikation über Infrastrukturgrenzen hinweg.
Wesentlich ist die klare Abgrenzung: SPIFFE löst ausschließlich das Identitäts- und Authentisierungsproblem. Die Autorisierung – also die Frage, was ein authentifizierter Workload darf – bleibt Aufgabe nachgelagerter Policy- und Zugriffskontrollmechanismen.
SPIRE als Vertrauensanker für Identitäten
Die Referenzimplementierung des SPIFFE-Standards ist SPIRE (SPIFFE Runtime Environment). Es stellt die Laufzeitkomponenten bereit, um SPIFFE-Identitäten automatisiert auszustellen, zu prüfen und regelmäßig zu erneuern. SPIRE ist modular aufgebaut und bringt bereits Plug-ins und Bibliotheken für gängige Plattformen, Orchestrierer und Programmiersprachen mit. Zusätzliche Integrationen werden durch Hersteller und die Community bereitgestellt.
Das Vertrauensmodell basiert auf zwei zentralen Komponenten (Bild): Der SPIRE-Server ist die zentrale Vertrauensinstanz einer Trust Domain. Er definiert die Regeln zur Identitätsvergabe, attestiert Agenten und stellt die kryptografischen Identitätsnachweise aus. Nur vom Server attestierte Agenten dürfen Identitäten für ihre Workloads anfordern und erhalten für diese signierte Zertifikate. Zudem verwaltet der Server die hierfür notwendigen Signaturschlüssel.
Der Server selbst kennt keine Workload-Prozesse, sondern verwaltet die Registration Entries. Sie wiederum definieren, welche Workloads unter welchen Bedingungen (Selektoren), welche SPIFFE-IDs erhalten. Um die Selektion der Workloads, Signaturanfragen für neue Identitäten und die Verteilung des Schlüsselmaterials kümmern sich die SPIRE Agenten.
Der SPIRE-Agent läuft Node-lokal – etwa auf einem Kubernetes Worker Node, Docker-Container oder einer VM – und fungiert als Broker, der zwischen Workload und Server vermittelt und lokale Kontextinformationen über Prozesse/Container erhebt, bevor Identitäten ausgestellt werden. Zwei Mechanismen des Agenten spielen dabei eine wesentliche Rolle:
- NodeAttestor Plug-ins ermitteln Informationen über die Laufzeitumgebung des Agenten. Außerdem wird deutlich, wie sich dieser mit SVID gegenüber dem Server authentisiert.
- WorkloadAttestor Plug-ins führen eine Identitätsprüfung des anfragenden Prozesses beziehungsweise Containers durch, um sicherzustellen, dass dieser zum registrierten Workload gehört.
Die Attestoren unterstützen alle gängigen Plattformen wie AWS, Kubernetes, GCP und sogar TPM für hardwaregestützte Attestierung.
SPIRE in der Praxis
Um mit SPIRE praktisch loszulegen, müssen Sie mindestens einen Server mit einem Agenten konfigurieren. Listing 1 zeigt ein minimales Setup für einen SPIRE-Server, der seine Metadaten in einer SQLite–DB und die Zertifikate in einer JSON-Datei verwaltet. Über den NodeAttestor werden neue Agenten mittels Join-Token akzeptiert. In der Praxis sollte dieses Setup hochverfügbar ausgelegt sein, da bei einem Wegfall sonst keine neuen Identitätsnachweise ausgestellt werden können. Den Server starten und initialisieren Sie mit dem Kommando:
./spire-server run -config server.conf
Listing 1: SPIRE-Server konfigurieren
server {
bind_address = "127.0.0.1"
bind_port = "8081"
trust_domain = "example.org"
data_dir = "./data/server"
ca_ttl = "168h"
default_x509_svid_ttl = "48h"
}
plugins {
DataStore "sql" {
plugin_data {
database_type = "sqlite3"
connection_string = "./data/ server/datastore.sqlite3"
}
}
KeyManager "disk" {
plugin_data {
keys_path = "./data/server/keys.json"
}
}
NodeAttestor "join_token" {
plugin_data {}
}
}
Das Setup der Datenbank und PKI erfolgt hierbei vollautomatisch. Bevor erste Identitäten ausgestellt werden können, müssen Sie einen Agenten registrieren. Am einfachsten geht das über ein einmaliges Join-Token, das Sie mit der SPIFFE-ID des Agenten registrieren und ihm mitgeben:
./spire-server token generate -spiffeID spiffe://example.org/ my-agent
Auf diesen Befehl hin wird ein Token ausgegeben. Um einen Agenten mit dem Server zu verbinden, fügen Sie das Join-Token beim Start hinzu:
./spire-agent run -config agent.conf -joinToken <token>
Listing 2 zeigt die Konfiguration eines Agenten, der neben Unix-Prozessen auch Kubernetes-Workloads attestiert. Bei der Initialisierung erzeugt der Agent sein lokales Schlüsselmaterial und versucht, eine Vertrauensbeziehung zum Server aufzubauen. Stimmen die Kriterien der NodeAttestation mit denen des Servers überein, signiert der Server die SVID des Agenten und beide sind einsatzbereit.
Listing 2: SPIRE-Agent konfigurieren
agent {
data_dir = "./data/agent"
log_level = "DEBUG"
trust_domain = "example.org"
server_address = "spiffe.example.org"
server_port = 8081
}
plugins {
KeyManager "disk" {
plugin_data {
directory = "./data/agent"
}
}
NodeAttestor "join_token" {
plugin_data {}
}
WorkloadAttestor "unix" {
plugin_data {}
}
WorkloadAttestor "docker" {
plugin_data {}
}
}
Dabei gibt es viele Wege, die Vertrauenswürdigkeit von Agenten zu attestieren: Für lokale Setups bieten sich SSH-Zertifikaten ebenso wie TPMs an. Seine Stärken spielt SPIRE jedoch in Cloudinfrastrukturen der großen Hyperscaler aus. Mit dessen NodeAttestoren lässt es sich nahtlos in das Sicherheits-Framework von AWS, GCP und Azure & Co. integrieren, um die Authentizität der Agenten und ihrer Workloads zu attestieren.
Identitäten erstellen und nutzen
Sobald Server und Agent einsatzbereit sind, können Sie erste Workload-Identitäten auf dem Server registrieren. Listing 3 zeigt, wie Sie eine neue SPIFFE-ID zentral definieren. Als Selektor dient beispielsweise ein Docker-Label. Der Server übermittelt die Selektoren als Identifikationskriterien an den Agenten.
Listing 3: Workload-Identität registrieren
spire-server entry create
-parentID spiffe://example.org/my-agent
-spiffeID spiffe://example.org/docker/my-workjob
-selector docker:label:payment-application:billing-job
Wird eine neue Identität durch einen Workload am Agenten angefordert, stellt dieser über die jeweilige Attestation zunächst die Integrität des Workload sicher. Passen die Kriterien, erzeugt der Agent das Schlüsselmaterial lokal und fordert vom Server ein Zertifikat für die neue SVID an. Die SVID – in Form eines X.509-Zertifikat oder JWT – wird dem Workload-Prozess zusammen mit dem Schlüsselmaterial und dem CA-Zertifikat zur Verfügung gestellt.
Ein zentrales Sicherheitsprinzip dabei ist, dass Secrets den Prozesskontext nicht verlassen. Workloads kommunizieren daher ausschließlich über eine lokale, geschützte Schnittstelle mit dem Agenten, meist über Unix Domain Socket oder plattformspezifische Integrationen.
Private Schlüssel und Zertifikate müssen Sie so nicht in Dateien oder Umgebungsvariablen ablegen, sondern Sie werden vom Agenten verwaltet, automatisch rotiert und nur zur Laufzeit bereitgestellt.
Vertrauen ohne Vorwissen
Im operativen Ablauf weist SPIFFE mehrere Vorzüge auf, wie einen klar strukturierten und weitgehend automatisierten Prozess. Jedoch liegen auch der schrittweisen Integrationsfähigkeit Vorteile zugrunde. In Kubernetes-Umgebungen lässt sich SPIFFE nahtlos mit Service Meshes wie Istio oder Linkerd kombinieren. Diese nutzen SPIFFE-IDs nativ, um mTLS zwischen Services umzusetzen – ohne separates Zertifikatsmanagement. Auch Policy-Systeme für feingranularen Zugriffsschutz, wie der Open Policy Agent, können Sie mit SPIFFE umgehen und SVIDs für Zugriffsentscheidung verwenden.
In Hybrid- und Multicloud-Szenarien schafft SPIFFE eine einheitliche Identitätsebene über Infrastrukturgrenzen hinweg. Workloads behalten ihre Identität unabhängig davon, ob sie in einer Private Cloud, bei einem Hyperscaler oder on-premises laufen. Damit entfällt die Notwendigkeit, Service Secrets verwalten und verteilen zu müssen.
Bei der Einbindung von Legacy-Systemen und klassischen Servern sollten Sie den Use Case genau prüfen: SVIDs sind bewusst kurzlebig und auf Stunden bis wenige Tage begrenzt; das Schlüsselmaterial und die Zertifikate werden automatisch rotiert. Das schließt den Einsatz für langlaufende Server-Prozesse mit umfangreichen Zertifikatsdaten aus, wie etwa Mailserver, ist aber ideal für kurze Workloads wie KI-Agenten.
Fazit
SPIFFE und SPIRE etablieren eine standardisierte Identitätsebene für Workloads, die ohne statische Secrets auskommt und Identität konsequent von Infrastruktur trennt. Kurzlebige, automatisch rotierte Identitätsnachweise ermöglichen sichere Service-zu-Service-Kommunikation über Plattform- und Cloud-Grenzen hinweg. Damit lassen sich Maschinenidentitäten kontrolliert vereinheitlichen, ohne bestehende Umgebungen abrupt umzustellen.
(ln)
Roland Baum ist Geschäftsführer von umbrella.associates.
Checkliste: SPIFFE/SPIRE schrittweise einführen
Das Ziel ist es, klassische Identity-Mechanismen kontrolliert abzulösen und Maschinenidentitäten zu standardisieren – ohne Big-Bang-Migration. Diese Punkte helfen IT-Verantwortlichen dabei:
Transparenz schaffen
- Kommunikationsbeziehungen zwischen Services dokumentieren.
- Einsatzorte von API-Keys, Zertifikaten und Tokens erfassen.
- Statisch verteilte oder hart kodierte Secrets sind identifiziert.
- Workloads erfassen, deren Identität heute aus Infrastrukturannahmen abgeleitet wird.
Identitätsrahmen definieren
- SPIFFE Trust Domain festlegen.
- Zielplattformen für den Einstieg definieren.
- Attestierungsmechanismen je Umgebung auswählen.
- SPIRE-Server und erste Agents installieren.
Erste produktive Nutzung starten
- SPIFFE-IDs werden automatisiert ausgestellt.
- mTLS für erste interne Service-zu-Service-Verbindungen aktivieren.
- Zertifikate ohne manuelle Eingriffe erneuern.
- Sicherheitsrichtlinien basieren auf Identitäten statt auf IP-Adressen.
Statische Secrets gezielt abbauen
- API-Keys und feste Tokens werden schrittweise ersetzt.
- Statische Zertifikate verlieren ihre operative Rolle.
- Rollen- und Berechtigungsmodelle sind vereinfacht.
- Änderungen an Deployments erfordern keine manuellen Security-Anpassungen.
Betrieb, Skalierung und Auditierbarkeit sicherstellen
- Neue Workloads erhalten automatisch eine Identität.
- Kommunikationsbeziehungen stets nachvollziehbar dokumentieren.
- Audit-Anforderungen lassen sich ohne Zusatzaufwand erfüllen.
- Sicherheitsvorfälle können schneller eingegrenzt werden.