Wie authentifiziert Workload Identity Dienste innerhalb eines heimischen KI-Stacks?

Die Workload-Identität authentifiziert heimische KI-Dienste, indem sie kurzlebige kryptografische Zugangsdaten an einen attestierten Prozess statt an eine Netzwerkadresse oder ein gespeichertes Passwort bindet.

Eine lokale RAG-API, ein Modellserver, eine Vektordatenbank und ein Gateway für Agenten-Tools können sich ein Heimnetzwerk teilen, während sie über sehr unterschiedliche Berechtigungen verfügen. Die Workload-Identität ermöglicht es jedem Prozess, vor dem Erhalt von Daten oder Zugangsdaten nachzuweisen, welcher freigegebene Dienst er ist. Der Verifizierer prüft Laufzeitnachweise, stellt eine benannte Identität aus und überlässt die Ressourcenautorisierung einer separaten Richtlinienentscheidung.

Attestierung verbindet einen laufenden Prozess mit einer deklarierten Identität

Ein Identitätsagent beobachtet verifizierbare Laufzeiteigenschaften wie Dienstkonto, ausführbare Datei, Container-Image, Namespace, Host oder signierte Workload-Metadaten. Die Registrierungsrichtlinie ordnet eine akzeptierte Kombination einem stabilen Dienstnamen zu, anstatt einem selbst deklarierten Label zu vertrauen.

Eine praktische Demonstration der Attestierung von Workloads zur Laufzeit zeigt, wie SPIFFE und SPIRE Workloads attestieren, bevor sie Identitäten innerhalb eines Homelabs ausstellen. Das Bootstrap-Vertrauen liegt im Knoten und im Registrierungsprozess, nicht in einem Geheimnis, das in jeden Container kopiert wird.

Dadurch ändert sich die erste Authentifizierungsfrage von „Welche IP-Adresse hat sich verbunden?“ zu „Welcher freigegebene Workload hat den Besitz dieser Identität nachgewiesen?“ Dynamische Adressen und Neustarts von Containern erfordern keine neuen statischen Zugangsdaten mehr. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Die Identitätsinstanz stellt kurzlebige überprüfbare Zugangsdaten aus

Nach der Attestierung stellt eine Instanz ein X.509- oder JWT-Zugangsdokument aus, das die Workload-Kennung und eine begrenzte Gültigkeitsdauer enthält. Der lokale Agent stellt es über eine geschützte Workload-Schnittstelle bereit und rotiert es vor Ablauf. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf aufbaut.

Eine Übersicht über kurzlebige Workload-Zugangsdaten erklärt, dass SPIFFE-Identitäten kurzlebig und kryptografisch überprüfbar sind, wodurch die Abhängigkeit von fest codierten Dienstgeheimnissen sinkt. Der empfangende Dienst validiert Aussteller, Zielgruppe, Zeitangaben und den Nachweis des Schlüsselbesitzes. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Kurze Gültigkeitsdauern begrenzen die Gefährdung, nachdem ein Dienst entfernt oder kompromittiert wurde. Die Rotation muss automatisch erfolgen, da abgelaufene Zertifikate die Verbindung standardmäßig ablehnen sollten, statt Betreiber dazu zu verleiten, langlebige Schlüssel wiederherzustellen. Die praktische Konsequenz zeigt sich, wenn mehrere Quellen um begrenzten Kontext konkurrieren.

Authentifizierung liefert die Identität, aber Richtlinien gewähren den Zugriff

Eine gültige Workload-Identität weist nach, welcher Dienst den Aufruf tätigt. Sie beweist jedoch nicht, dass der Modellserver jede Sammlung lesen darf oder dass ein Agent im Auftrag eines bestimmten Benutzers handelt. Die Autorisierung bewertet Identität zusammen mit Ressource, Vorgang, Benutzerdelegation und aktueller Richtlinie.

Eine Analyse von Workload- und Agentenidentität unterscheidet zwischen Workload-Identität, gegenseitiger Authentifizierung und dem Benutzer- oder Agentenkontext, der oberhalb der Verbindung übertragen wird. Diese Trennung verhindert, dass ein vertrauenswürdiges Dienstzertifikat zu einer universellen Berechtigung wird. Diese Abhängigkeit sollte in der finalen Schnittstelle ausdrücklich erhalten bleiben.

Die Fehlergrenze liegt bei einer kompromittierten Identitätsinstanz, einem kompromittierten Knotenattestierer oder einer kompromittierten Registrierungsregel. Der kryptografische Nachweis setzt die Identität, für die er ausgestellt wurde, zuverlässig durch, selbst wenn die Ausstellungsrichtlinie einen angreifergesteuerten Prozess dem falschen Dienst zugeordnet hat.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verfolge einen Dienstaufruf von der Attestierung bis zur Autorisierung

Wähle eine Anfrage vom RAG-System zum Vektorspeicher und erfasse Workload-Selektor, registrierte Identität, Aussteller, Gültigkeitsdauer des Zertifikats oder Tokens, Speicherort des Schlüssels, Peer-Validierung, angeforderte Ressource, delegierten Benutzer, Richtlinienentscheidung, Rotation, Widerruf und Audit-Kennung. Das Ergebnis muss daher mit den ursprünglichen Nachweisen abgeglichen werden.

Vergleiche die Kontrolle mit den KI-Identitätskontrollen. Teste einen legitimen Neustart, kopierte Zugangsdaten, einen nicht registrierten Container, eine falsche Zielgruppe, eine abgelaufene Identität, ein geändertes Dienstkonto und eine gültige Identität, die eine nicht erlaubte Sammlung anfordert. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Bestehe den Test nur, wenn sich authentische Workloads automatisch wieder verbinden und jede Identitätsvortäuschung oder unzulässige Ausweitung an einer benannten Grenze scheitert. Schütze die Identitätsinstanz separat und halte die Ressourcenautorisierung enger als die Dienstauthentifizierung. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf aufbaut.