Die Container-Orchestrierungsplattform Kubernetes ist in vielen Unternehmen der Standard, um Anwendungen flexibel und skalierbar bereitzustellen. Damit steigen jedoch auch die Anforderungen an Sicherheit und Zugriffskontrolle. Kubernetes verlangt idealerweise einen Zero-Trust-Ansatz, bei dem sich alle Nutzer – ob Mensch oder Maschine – bei jedem Zugriff eindeutig authentifizieren müssen. Dazu gehören auch interne Prozesse wie Skripte oder systemeigene Dienste, die zwischen Anwendungen kommunizieren.

Für solche technischen Nutzer stellt Kubernetes sogenannte Servicekonten bereit (Service Accounts oder Dienstkonten). Diese erlauben es automatisierten Prozessen, sich gegenüber dem Kubernetes-API-Server auszuweisen – beispielsweise, um Logs abzurufen oder Konfigurationsdaten aus einer ConfigMap zu lesen.

Die Trennung zwischen Benutzerkonten für menschliche Anwender und Servicekonten für technische Prozesse ist ein grundlegendes Prinzip in Kubernetes. Sie stärkt die Sicherheitsarchitektur und verbessert zugleich die Auditierbarkeit. Jedes Servicekonto ist dabei an einen bestimmten Namespace gebunden – einen logischen Namensraum, der der Trennung und Organisation von Ressourcen dient und isolierte Umgebungen für Pods, Services und Servicekonten schafft.

Die Berechtigung eines Servicekontos gilt ausschließlich innerhalb dieses Namensraums. Dadurch kann ein kompromittiertes Servicekonto nicht auf Ressourcen in anderen Namespaces zugreifen. Diese Isolation stellt ein zentrales Sicherheitsmerkmal dar und schließt Seiteneffekte von Angriffen auf andere Kubernetes-Komponenten weitgehend aus. Jeder Namespace enthält zudem ein automatisch erzeugtes Standard-Servicekonto, das wiederum Automatisierungstools verwenden können.

Servicekonten greifen meist über API-Zugriffe auf Ressourcen zu. Dazu authentifizieren sie sich beim Kubernetes-API-Server mithilfe eines JSON Web Token (JWT). Dieser enthält Informationen über die Identität des Servicekontos, den Ziel-API-Server, die Gültigkeitsdauer und die Objektbindungen des zugehörigen Pods. Der Token wird zusammen mit dem API-Aufruf gesendet. Der API-Server prüft den Token und autorisiert die Anfrage anhand der zugewiesenen Rechte.

In der Praxis kommen häufig die Standard-Servicekonten der Namespaces zum Einsatz. Sie verfügen über minimal notwendige Rechte und tragen so zu einem sicheren Betrieb bei. Kritisch wird es jedoch, wenn manuell erzeugte Konten mit zu weitreichenden Rechten oder langfristig gültigen Tokens Verwendung finden. In solchen Fällen können Servicekonten zu Einfallstoren für Angreifer werden.

Ein Cyberangriff unter Ausnutzung eines Servicekontos kann beispielsweise damit beginnen, dass sich ein Angreifer Zugriff auf einen Pod verschafft. Anschließend nutzt er die dem Servicekonto zugewiesenen Rechte, um weitere Ressourcen im Kubernetes-Cluster zu erkunden oder zu manipulieren. Eine typische Taktik besteht darin, über den API-Server gezielt Anfragen an ConfigMaps oder Secrets zu senden – etwa mit HTTP-GET- oder HTTP-LIST-Methoden, um vertrauliche Daten abzufragen. Verfügt das Servicekonto nicht über die erforderlichen Rechte, antwortet der Server mit dem Status "403 Forbidden".

Dieses Verhalten entspricht zwar dem HTTP-Standard, sollte jedoch in einer korrekt konfigurierten Umgebung nicht auftreten. Üblicherweise besitzen Servicekonten nur die minimal erforderlichen Rechte – der Zugriff auf sensible Ressourcen wie ConfigMaps und Secrets ist explizit gesteuert und bleibt spezialisierten Konten vorbehalten. Eine auffällige Häufung entsprechender Fehlermeldungen weist daher oft auf einen aktiven Angriff hin. Zusätzliche Hinweise liefern ein plötzlicher Anstieg von Zugriffsversuchen oder unüblichen Zugriffsmustern.

Systemadministratoren erkennen solche Aktivitäten in den Logs, in denen alle API-Zugriffe protokolliert sind. Tools wie Dynatrace – eine KI-gestützte Observability-Plattform – ermöglichen eine strukturierte Auswertung dieser Logs. Administratoren definieren dort gezielt Filter, etwa "Zugriffe auf ConfigMaps oder Secrets, die mit 403 beantwortet wurden". Die Plattform identifiziert verdächtige Muster automatisiert und priorisiert sie nach Relevanz. Zudem reichert sie die Informationen kontextuell an – beispielsweise mit dem Namen des Servicekontos, des zugehörigen Pods, IP-Adressen oder dem Inhalt des User-Agent-Felds. Ein nicht dokumentierter oder auffälliger User-Agent deutet häufig auf einen Angriff hin. In einigen Fällen finden sich in diesem Feld sogar Hinweise auf eingesetzte Exploit-Tools.

Die Monitoringplattform kann den Vorfall anschließend tiefer analysieren und zusätzliche Metadaten zum betroffenen Pod, Cluster oder zum verantwortlichen Workload-Eigentümer erfassen. Bei vorhandenen Schwachstellen oder Complianceverstößen wird ein Sicherheitsvorfall ausgelöst. Administratoren erhalten binnen kürzester Zeit eine konsolidierte Sicht auf das Sicherheitsprofil eines Pods. Umfangreiche Kontextdaten erleichtern die Identifikation betroffener Anwendungen und ermöglichen gezielte Gegenmaßnahmen – insbesondere bei Konfigurations- oder Complianceproblemen wie überprivilegierten Konten. In Kombination mit eigenständig agierender KI, die automatisierte Vorschläge zur Fehlerbehebung liefert, entfällt der manuelle Aufwand zur Priorisierung und Recherche. Stattdessen erhalten Verantwortliche direkt umsetzbare Empfehlungen, und zwar unmittelbar am Ort des Geschehens.

Um Attacken über Servicekonten zu verhindern, ist eine kontinuierliche Überprüfung der Berechtigungen unerlässlich. Administratoren müssen veraltete oder überprivilegierte Rollen aufspüren und das Berechtigungsmodell regelmäßig kontrollieren, um die Angriffsfläche so klein wie möglich zu halten.

Ein weiterer potenzieller Angriffspunkt in Kubernetes sind die JSON Web Tokens (JWT), mit denen sich Servicekonten gegenüber dem API-Server authentifizieren. Kubernetes erzeugt diese Tokens über den TokenRequest-Mechanismus und verwaltet sie automatisch über die Kubelet-Komponente. Jeder Authentifizierungsnachweis ist einem konkreten Pod zugeordnet und an dessen Lebensdauer gekoppelt – ein wichtiges Sicherheitsmerkmal, das die Nutzbarkeit gestohlener Tokens zeitlich begrenzt.

Die früher verbreitete Praxis, langlebige oder statische ("unsterbliche") Tokens zu verwenden, gilt heute als unsicher. Seit Kubernetes-Version 1.24 lässt sich die Erstellung solcher Tokens standardmäßig nicht mehr durchführen. Stattdessen kommen kurzlebige Tokens zum Einsatz, die eng mit dem Lebenszyklus des zugehörigen Kubernetes-Objekts verknüpft sind.

Ein Token enthält Metadaten wie den Namen und die User-ID des referenzierten Objekts sowie weitere Informationen zur Validierung und Identifikation. Der API-Server überprüft bei der Authentifizierung neben der Gültigkeit auch, ob das referenzierte Objekt weiterhin existiert und dieselbe UID besitzt. Entfällt eine dieser Voraussetzungen, verliert der Token automatisch seine Gültigkeit. Dies geschieht auch dann, wenn er noch nicht abgelaufen ist.

Trotz dieser Schutzmechanismen können Angreifer kurzlebige Tokens missbrauchen. Ein typisches Szenario beginnt mit der Kompromittierung eines Pods, etwa durch Schwachstellen in der Anwendung oder eine fehlerhafte Konfiguration. Hat der Angreifer Zugriff auf den Container, kann er das im Dateisystem gespeicherte Token auslesen und sich damit gegenüber dem Kubernetes-API-Server authentifizieren. Anschließend führt er API-Anfragen im Namen des kompromittierten Servicekontos aus. Verfügt dieses Konto über weitreichende Rechte, lassen sich zum Beispiel Secrets auslesen oder manipulierte Pods starten.

Besonders gefährlich wird es, wenn überprivilegierte Servicekonten nicht überwacht werden. Ohne Monitoring bleiben Angriffe oft unentdeckt. Selbst bei minimalen Berechtigungen können Angreifer systematisch Informationen sammeln, die sie in späteren Phasen ausnutzen. Denkbar ist auch der Missbrauch gestohlener Tokens auf einem entfernten Rechner. Das gelingt allerdings nur, wenn keine IP-Adressbindung oder andere Zugriffsbeschränkungen konfiguriert sind.

Die wirksamste Absicherung besteht daher in der konsequenten Begrenzung von Rechten, kombiniert mit Laufzeitmonitoring und einer kontinuierlichen Prüfung aller API-Zugriffe. Nur so lassen sich Servicekonten effektiv vor unbefugter Nutzung schützen.

Die Praxis zeigt: Verdächtige Servicekonten weisen oft mehrere Merkmale auf – etwa unerwartete API-Zugriffe mit dem Status "403 Forbidden", ungewöhnliche User Agents oder privilegierte Aktionen in untypischen Kontexten. Logs, die automatisch mit Metadaten, Schwachstellen- und Complianceinformationen angereichert werden, helfen Administratoren, diese Indikatoren systematisch einzuordnen und gezielte Gegenmaßnahmen einzuleiten.

Der wirksamste Schutz besteht in restriktiver Rechtevergabe und kurzlebigen, objektgebundenen Tokens. Zusätzlich sind regelmäßige Prüfungen und aktives Monitoring von API-Zugriffen essenziell. Sicherheitsrelevante Erkenntnisse sollten in zentrale SIEM-Systeme einfließen und durch moderne CADR-Plattformen ergänzt werden, um Auffälligkeiten zu korrelieren und gezielt zu adressieren.