Was sind SPIFFE und SPIRE?

URL kopieren

SPIFFE und SPIRE sind 2 Open Source-Projekte für das Identitätsmanagement in dynamischen und vielfältigen Computing-Umgebungen.

SPIFFE (ausgesprochen „Spiffy“) steht für „Secure Production Identity Framework for Everyone“. Das Framework legt eine Struktur für Identitäten fest und bietet die Möglichkeit, IDs kryptografisch zu verifizieren und für vertrauenswürdig zu befinden.

SPIRE ist die Abkürzung für SPIFFE Runtime Environment. SPIRE ist die Referenzimplementierung für SPIFFE.

Gemeinsam definieren SPIFFE und SPIRE einen Weg zum Durchsetzen einer Zero Trust-Architektur in komplexen Hybrid Cloud-Umgebungen. Das SPIFFE/SPIRE-Framework löst viele Sicherheitsprobleme, darunter:

Sowohl SPIFFE als auch SPIRE sind Projekte der CNCF (Cloud Native Computing Foundation). Red Hat bietet mit dem Zero Trust Workload Identity Manager von Red Hat® eine unternehmensgerechte SPIFFE/SPIRE-Implementierung als Red Hat OpenShift® Operator in der Technologievorschau.

SPIFFE-Unterstützer sehen hierin manchmal eine Lösung für das „Bottom Turtle-Problem.“ Die Autoren des SPIFFE-Projekts nutzten die Schildkröten-Metapher sogar als Buchtitel über diese Technologie. 

Was also ist das Bottom Turtle-Problem?

In einer alten Geschichte besteht eine Figur darauf, dass die Welt auf dem Rücken einer riesigen Schildkröte ruht. Auf die Frage, worauf die Schildkröte steht, antwortet die Figur, sie stehe auf dem Rücken einer weiteren, noch größeren Schildkröte. Und worauf steht diese Schildkröte? „Es sind Schildkröten bis ganz unten!“

Die Computersicherheit hat ein ähnliches Bottom Turtle-Problem. Secrets wie Passwörter und API-Schlüssel (Application Programming Interface) sorgen dafür, dass unterschiedliche Plattformen und Services sich gegenseitig vertrauen können. Zum Schutz dieser Secrets sind zusätzliche Sicherheitsmaßnahmen erforderlich, wie private Verschlüsselungscodes und ein Secrets Repository zum Speichern der Codes. Wie schützen Sie das Secrets Repository? Mit noch mehr Secrets. Bald sind es Secrets bis ganz unten.

Der SPIFFE-Standard und die SPIRE-Implementierung zielen darauf ab, die „Bottom Turtle“ zu etablieren, die eine Basis des Vertrauens für alle Interaktionen in einem System darstellt.

SPIFFE und SPIRE dienen der Verbesserung der IT-Sicherheit. Zusammen bilden sie ein Framework, das sicherstellt, dass Zugriff nur für Interaktionen mit verifizierten Identitäten gewährt wird. Als Analogie können Sie sich SPIFFE und SPIRE als Multi-Faktor-Authentifizierung (MFA) für Workloads vorstellen.

SPIFFE: Das Framework

SPIFFE legt Spezifikationen für die Ausgabe und Verwaltung kryptografischer Identitäten für Services in verschiedenen Umgebungen fest. Der Kern dieses Standards ist das SPIFFE Verifiable Identity Document (SVID), das Daten mit kurzer Gültigkeitsdauer enthält und als Identität einer Workload dient.

In einer Zero Trust-Architektur, in der standardmäßig keiner Komponente vertraut wird, ermöglicht SPIFFE die Workload-Authentifizierung, ohne auf Secrets zurückgreifen zu müssen. Wenn eine Workload mit einem anderen Service interagieren muss, kann sie ihre SVID nutzen, was normalerweise in Form eines X.509-Zertifikats oder eines JSON Web Token (JWT) erfolgt.

Andere Workloads können das SVID dann lokal verifizieren und ermöglichen so eine vertrauenswürdige Peer to Peer-Authentifizierung, ohne dass für jede Transaktion eine zentrale Instanz benötigt wird. Dieser optimierte Prozess vereinfacht und schützt die Service-Kommunikation, indem er die Vertrauenswürdigkeit durch eine verifizierbare, standardisierte Identität aufrechterhält.

SPIRE: Die Runtime-Umgebung

SPIRE beschreibt eine Möglichkeit zur Implementierung des SPIFFE-Standards. Damit wird ein Prozess zum Einrichten von APIs definiert, die Vertrauen zwischen Workloads (Anwendungen oder Agenten, die eine Anfrage stellen) und Knoten (Server oder Maschinen) schaffen.

SPIRE berücksichtigt die Attestierung sowohl für den Workload als auch für den Knoten. Das bedeutet, dass sowohl die Anwendung als auch die Ressource den angegebenen Anforderungen entspricht, bevor ein Signaturzertifikat ausgestellt wird.

Ein SPIRE-Server fungiert als Signierstelle für Identitäten in seiner SPIFFE-Domain. Außerdem verfolgt er die Workload-Identitäten in einer Registry. 

Zusätzlich zum SPIRE-Server werden SPIRE-Agenten auf den verschiedenen Knoten eingesetzt, auf denen die Workloads ausgeführt werden. Diese Agenten speichern einen Cache mit SVIDs und bestätigen die Identität von Workloads. Die SVID-Verifizierung kann lokal mithilfe der Selbstprüfung auf Kernel-Ebene erfolgen. Mit anderen Worten: Der Workload muss keinen externen Service aufrufen, um zu überprüfen, ob eine Aktion autorisiert ist.

SPIRE unterstützt Federation, durch die verschiedene Systeme Trust Bundles austauschen, die die öffentlichen Schlüssel und Zertifizierungen enthalten, die zu ihrer Validierung erforderlich sind. 

SPIFFE und SPIRE unterstützen die Authentifizierung in verteilten Multi Cloud-Umgebungen. Beispiele für gängige Use Cases:

Authentifizierung in Hybrid Cloud-Umgebungen

In Hybrid Cloud- und Multi Cloud-Umgebungen können Anwendungen mehrere Cloud-Anbieter und Administrationsgrenzen umfassen. Dies führt zu mehr Komplexität beim Versuch, eine vertrauenswürdige Kommunikation über diese Domains hinweg zu implementieren. 

Mit SPIFFE Federation können Ihre an verschiedenen Orten laufenden SPIRE-Server öffentliche Schlüssel und Zertifikate über sogenannte Trust Bundles austauschen, ein Format für eine Sammlung öffentlicher Schlüssel, die von einer bestimmten SPIFFE-Ausgabestelle verwendet werden. Auf diese Weise können Anwendungen auch über verschiedene Cloud-Anbieter oder administrative Grenzen hinweg Vertrauen schaffen, und das ohne Private Keys oder komplexe Netzwerkkonfigurationen.

Identitätsmanagement in Kubernetes und KubeVirt

Kubernetes-Umgebungen umfassen in der Regel viele kleinere Workloads, die in isolierten Containern ausgeführt werden und zusammen funktionieren müssen. SPIFFE und SPIRE können die Sicherheit in Kubernetes-Umgebungen verbessern, indem sie die Authentifizierung für containerisierte Anwendungen unabhängig von ihrer Ausführung im Netzwerk ermöglichen. Diese erweiterte Sicherheit funktioniert auch für virtuelle Maschinen, die auf Lösungen ausgeführt werden, die auf KubeVirt basieren, wie etwa Red Hat OpenShift Virtualization. Dies erleichtert eine granulare Zugangskontrolle, ein Grundprinzip der Zero Trust-Architektur.

Workflows für KI-Agenten

KI-Agenten, die Befehle entgegennehmen und dann mit einem anderen System interagieren, um ein Ziel zu erreichen, werden immer häufiger eingesetzt. Doch ihr Einsatz ist nicht so einfach, wenn es um vertrauliche Daten geht. Um einem KI-Agenten Zugriff zu gewähren, sind robuste, überprüfbare Identitäten für Maschinen-Workloads erforderlich, was bei Hybrid Cloud-Plattformen noch komplizierter wird. SPIFFE und SPIRE können einen Teil der Lösung mit verifizierbaren, kurzfristigen Zugangsdaten bereitstellen, die KI-Services einen kontrollierten Zugriff auf sensible Daten ermöglichen.

Vertrauen im Service Mesh

Ein Service Mesh ist eine Schicht, die insbesondere in containerisierten Anwendungen die Kommunikation zwischen Services handhabt. Eine SPIFFE- und SPIRE-Implementierung kann integriertes Sicherheitsmanagement zu Service Meshes hinzufügen, sodass diese sich auf kryptografisch überprüfbare Identitäten stützen können. Diese Vertrauensebene vereinfacht die Interoperabilität zwischen Systemen. Sie unterstützt außerdem die Durchsetzung von Richtlinien innerhalb und außerhalb des Service Mesh.

Sicherheit bei Edge Computing

Da SPIFFE und SPIRE die Identitätskontrollebene auf lokale Umgebungen ausweiten, eignen sie sich für Edge Computing. Mit kryptografisch verifizierbaren SVIDs können Sie eine wirksame Authentifizierung in Ihrem gesamten Netzwerk implementieren, selbst für weit entfernt ausgeführte Edge Services.

Die Ausführung moderner Anwendungen in der Cloud erfordert einen gewissen Grad an Automatisierung. Eine beliebte Wahl ist Kubernetes, eine Open Source-Plattform für das Bereitstellen, Verwalten und Skalieren von Anwendungen in Containern. Kubernetes ist die Basis von Red Hat OpenShift.

Mit SPIFFE und SPIRE als Identitätskontrollebene – der bereits erwähnten „Bottom Turtle“ – können Sie in Kubernetes mit verifizierbaren Identitäten arbeiten. Im Folgenden finden Sie 3 wichtige Informationen zu SPIFFE und SPIRE in Kubernetes:

  1. SPIRE ist das Framework für die Implementierung von SPIFFE. Sie müssen die SPIRE-Komponenten in Ihrem Kubernetes-Cluster bereitstellen. Dazu gehören der SPIRE-Server, der Identitäten und Signaturen verwaltet, und die SPIRE-Agenten, von denen einer auf jedem Kubernetes-Knoten ausgeführt werden muss. Diese Komponenten bilden Ihre grundlegende Identitätsinfrastruktur und bereiten Ihren Cluster für die kryptografische Überprüfung von Identitäten vor. Red Hat Zero Trust Workload Identity Manager kann dies in Red Hat OpenShift-Umgebungen erleichtern.
  2. SPIRE-Agenten führen sowohl die Attestierung von Knoten als auch von Workloads durch. Agenten können die Eigenschaften einer Anwendung (wie Kubernetes Namespace, Service Account oder Container Image) und somit die Legitimität dieser Anwendung überprüfen.
  3. Nach der Attestierung greifen die Anwendungen auf die vom SPIFFE-Agenten bereitgestellte, lokale SPIFFE-Workload-API zu, um ihre eindeutigen, kurzlebigen SVIDs abzurufen. Diese SVIDs helfen beim Aufbau von mTLS-Verbindungen (Mutual Transport Layer Security) und stellen so eine zuverlässige Kommunikation zwischen Services sicher.

Lernpfad: SPIFFE/Spire auf Red Hat OpenShift

Die Lösungen von Red Hat sind für umfassende Sicherheit ausgelegt. Sie können Ihnen beim Aufbau einer Zero Trust-Basis helfen, die Datensouveränität gewährleistet und gleichzeitig das Deployment und Management cloudnativer und KI-gesteuerter Workloads unterstützt. Die Fachleute von Red Hat können Sie bei der Zero Trust-Einführung in Multi Cloud-Umgebungen unterstützen. 

Der Zero Trust Workload Identity Manager von Red Hat ist ein Operator von Red Hat OpenShift, der die Installation und das Lifecycle-Management von SPIFFE und SPIRE vereinfacht. Die Lösung lässt sich auf bestehenden Clustern installieren, ist für Red Hat OpenShift validiert und wird durch eine umfassende Dokumentation für Installation und Fehlerbehebung unterstützt.

Red Hat OpenShift testen

Testen Sie Red Hat OpenShift: vollständig gemanagt in Ihrer Cloud, selbst gemanagt in der Cloud, auf Ihrem Computer, in Ihrem Rechenzentrum oder sofort in einer Entwicklungs-Sandbox.

Weiterlesen

Was ist Post-Quanten-Kryptografie?

Erfahren Sie mehr über den Ansatz von Red Hat zur Post-Quanten-Kryptografie, die Verschlüsselungsalgorithmen bezeichnet, die gegen Angriffe durch Quantencomputer resistent sind.

Warum Red Hat für DevSecOps?

DevSecOps ist ein komplexes Unterfangen. Mit den Sicherheitsfunktionen von Red Hat können Entwicklungs- und Sicherheitsteams DevSecOps früh in den Lifecycle implementieren.

Was ist Confidential Computing?

Beim Confidential Computing wird hardwarebasiertes Computing eingesetzt, um Daten zu schützen, wenn sie nicht im Ruhezustand sind oder übertragen werden – also während der tatsächlichen Nutzung.

Ressourcen zu Sicherheit

Verwandte Artikel