Sicherung von Maschinenidentitäten in Kubernetes in einer Zero-Trust-Welt

Maschinenidentitäten in Kubernetes sind Zertifikate, Service-Account-Token und kryptografische Schlüssel, die nicht-menschliche Komponenten wie Pods, Nodes, Services und Controller identifizieren. Ihre Sicherung im Zero-Trust-Modell bedeutet, dass jede Workload bei jeder Anfrage ihre Identität nachweist, anstatt aufgrund ihres Netzwerkstandorts als vertrauenswürdig eingestuft zu werden.

Um Maschinenidentitäten in Kubernetes unter Zero Trust zu sichern , wird jeder Workload ein kurzlebiges, verifizierbares Attribut ausgestellt, jede Verbindung mit Mutual TLS authentifiziert, das Least-Privilege-RBAC-Prinzip durchgesetzt und die Zertifikatsausstellung und -rotation automatisiert. Kubernetes unterstützt dies nativ durch gebundene Service-Account-Token, und Tools wie cert-manager und SPIFFE erweitern es auf Workload-Zertifikate.

Wichtige Erkenntnisse

• Laut der Studie „CyberArk 2025 Identity Security Landscape“ übertreffen Maschinenidentitäten mittlerweile die menschlichen Identitäten im Verhältnis 82 zu 1, und Kubernetes-Cluster gehören zu den am schnellsten wachsenden Akteuren.
• Zero Trust, formalisiert in NIST-SP 800-207 (August 2020) ersetzt das Vertrauen in den Netzwerkstandort durch eine Authentifizierung und Autorisierung jeder einzelnen Arbeitslast pro Anfrage.
• Seit Kubernetes 1.24 erstellt die Steuerungsebene keine langlebigen, auf Secrets basierenden Service-Account-Tokens mehr automatisch; gebundene, zeitlich begrenzte Tokens (stabil in 1.22) sind der Standard.
• cert-manager (CNCF-Abschluss, November 2024) und SPIFFE/SPIRE (CNCF-Abschluss, September 2022) automatisieren die Ausstellung von Zertifikaten und Workload-Identitäten innerhalb von Kubernetes.
• Die vom CA/Browser Forum geplante schrittweise Reduzierung der Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 47 Tage bis März 2029 macht die automatisierte Zertifikatsverwaltung für alles, was ein Cluster öffentlich zugänglich macht, zwingend erforderlich.

Was sind Maschinenidentitäten in Kubernetes?

Maschinenidentitäten in Kubernetes sind die Anmeldeinformationen, die nicht-menschliche Komponenten authentifizieren: X.509-Zertifikate, Service-Account-Token und kryptografische Schlüssel.

Knoten authentifizieren sich am API-Server mit Kubelet-Clientzertifikaten. Pods authentifizieren sich mit Service-Account-Tokens, die in ihr Dateisystem geschrieben werden. Dienste legen TLS-Zertifikate vor, um ihre Identität nachzuweisen, und Frameworks wie SPIFFE weisen jeder Workload ein verifizierbares Identitätsdokument (SVID) zu. All dies sind digitale Zertifikate und Tokens, die dieselbe Funktion erfüllen wie ein Mitarbeiterausweis: Sie dienen dem Identitätsnachweis vor der Zugriffsgewährung.

Die Skalierung ist die größte Herausforderung. Pods können nur wenige Minuten bestehen, daher müssen Identitäten im gleichen Tempo ausgestellt, rotiert und ablaufen. Laut der CyberArk-Studie „Identity Security Landscape 2025“ liegt das Verhältnis von Maschinenidentitäten zu menschlichen Identitäten bei 82 zu 1, und containerisierte Workloads tragen maßgeblich zu diesem Wert bei. Die manuelle Zertifikatsverwaltung kann mit dieser Dynamik nicht mithalten.

Was Zero Trust für einen Kubernetes-Cluster bedeutet

Zero Trust ist ein Sicherheitsmodell, das in der NIST Special Publication 800-207 (August 2020) formalisiert wurde. Dabei wird keinem Benutzer oder keiner Arbeitslast standardmäßig vertraut, und jede Anfrage wird authentifiziert und autorisiert. Der Zero-Trust-Ansatz lässt sich oft mit „Vertrauen ist gut, Kontrolle ist besser“ zusammenfassen.

Ein standardmäßiges Kubernetes-Pod-Netzwerk ist flach: Sobald ein Angreifer einen Pod kompromittiert hat, kann er oft alle anderen Pods erreichen. Zero Trust schließt diese Sicherheitslücke, indem es die Identität und nicht die Netzwerkposition zur Grundlage des Zugriffs macht. Richtlinien werden granular pro Workload und Anfrage durchgesetzt, basierend auf der verifizierten Identität des Workloads, seinem Namespace, seiner Rolle und der Sensibilität der aufgerufenen Ressource. Das Prinzip der minimalen Berechtigungen begrenzt somit die Reichweite einer kompromittierten Identität.

In einem Zero-Trust-Cluster wird die Identität ausgestellt und verifiziert, sie wird niemals vorausgesetzt.

Wie Kubernetes Maschinenidentitäten ausgibt und verwaltet

Kubernetes stellt Maschinenidentitäten über Service-Account-Token und Zertifikatsignierungsanforderungen aus und erweitert diese mit Tools wie cert-manager, SPIFFE/SPIRE und Service Meshes.

Die größte Veränderung der letzten Jahre ist die Abkehr von langlebigen Tokens. Gebundene Service-Account-Tokens wurden in Kubernetes 1.22 stabilisiert: Sie sind zeitlich begrenzt, nutzergebunden und an einen bestimmten Pod gebunden; der Kubelet rotiert sie automatisch. Seit Kubernetes 1.24 erstellt die Steuerungsebene nicht mehr automatisch für jeden neuen Service Account ein unbefristetes, Secret-basiertes Token. Ein Cleaner, der nicht mehr benötigte Legacy-Tokens ungültig macht und entfernt, wurde in Kubernetes 1.30 stabilisiert.

Attribut	Legacy Secret-basierter Token	Token für gebundenes Dienstkonto
Lebenslang	Unbefristet; gültig bis zum manuellen Widerruf.	Zeitlich begrenzt (typischerweise 1 Stunde); wird vom Kubelet rotiert.
Publikum	Wird von allen Systemen akzeptiert, die dem Cluster-Signaturschlüssel vertrauen.	An ein bestimmtes Publikum gebunden; andernorts abgelehnt.
Buchbindung	Nur an das Servicekonto gebunden	An das Servicekonto und den Pod gebunden; läuft mit dem Pod ab
Auswirkungen des Diebstahls	Persistenter API-Zugriff bis zum Widerruf	Der Zugriff erlischt mit der Lebensdauer des Tokens.
Standardstatus	Wird seit Kubernetes 1.24 nicht mehr automatisch erstellt.	Standardprojektion seit Version 1.22 (stabil)

Zusätzlich zu den integrierten Mechanismen automatisiert cert-manager die Ausstellung und Erneuerung von X.509-Zertifikaten innerhalb des Clusters und wurde im November 2024 als CNCF-Projekt offiziell anerkannt. SPIFFE und SPIRE, die im September 2022 offiziell anerkannt wurden, verleihen jeder Workload eine plattformunabhängige Identität, die cluster- und cloudübergreifend funktioniert. Service-Meshes wie Istio und Linkerd nutzen diese kurzlebigen Zertifikate, um Mutual TLS (mTLS) zwischen Diensten zu erzwingen, sodass jede Verbindung authentifiziert und verschlüsselt wird. Eine Zertifizierungsstelle (CA) bildet die Grundlage all dessen: Jedes Zertifikat ist auf eine CA zurückzuführen, der der Cluster vertraut.

Warum Maschinenidentitätssicherheit wichtig ist

Eine einzige kompromittierte Maschinenidentität ermöglicht es einem Angreifer, sich als vertrauenswürdige Arbeitslast auszugeben, den Datenverkehr abzufangen und sich lateral im Cluster zu bewegen.

Angreifer zielen auf Maschinenidentitäten ab, da diese dauerhaften Zugriff ermöglichen: Ein gestohlenes Token oder ein gestohlener Schlüssel erlaubt Man-in-the-Middle-Angriffe, API-Missbrauch und die Nachahmung legitimer Dienste. Der NSA- und CISA-Leitfaden zur Kubernetes-Härtung (Version 1.2, August 2022) stellt Identitätskontrollen in den Mittelpunkt seiner Empfehlungen: starke Authentifizierung, rollenbasierte Zugriffskontrolle (RBAC) nach dem Prinzip der minimalen Berechtigungen und regelmäßige Audits. Containerplattformen erben dieselben Risiken, die bei der Absicherung von Containern beschrieben werden, wobei die Identität die verbindende Schicht darstellt.

Die Regulierung weist in dieselbe Richtung. HIPAA, PCI DSS und DSGVO fordern allesamt kontrollierten Zugriff auf sensible Daten, Verschlüsselung während der Übertragung und Speicherung sowie nachvollziehbare Protokolle darüber, wer auf welche Daten zugegriffen hat. Maschinelles Identitätsmanagement unterstützt jede dieser Anforderungen: Zertifikate und Schlüssel gewährleisten verschlüsselte und authentifizierte Verbindungen; die zentrale Ausstellung und der Widerruf von Zertifikaten halten die Zugangsdaten aktuell; und Protokolle auf Identitätsebene ermöglichen Prüfern die nachvollziehbare Dokumentation der Interaktionen mit dem System.

Die Rolle von HSMs und TPMs

Hardware-Sicherheitsmodule (HSMs) und Trusted Platform Modules (TPMs) schützen die privaten Schlüssel, die die Maschinenidentität in manipulationssicherer Hardware verankern.

Die wertvollsten Schlüssel in einem Cluster sind die Zertifizierungsstellenschlüssel, die jedes Workload-Zertifikat signieren. Durch die Speicherung dieser Schlüssel in einem FIPS 140-3-validierten HSM, lokal oder über einen Cloud-Dienst wie AWS CloudHSM, Azure Key Vault Managed HSM oder Google Cloud HSM, wird verhindert, dass eine Softwarekompromittierung zu einer Kompromittierung der Zertifizierungsstelle führt. TPMs arbeiten auf Knotenebene: Der Chip bestätigt, dass ein Rechner vor dem Beitritt zum Cluster nicht manipuliert gestartet wurde. Zusammen bilden sie eine hardwarebasierte Vertrauensbasis für die Identitätskette. HSM-as-a-Service bietet dieselbe Sicherheit, ohne dass Ihr Team die Hardware besitzen muss.

Was als Nächstes kommt: Kürzere Zertifikate und Post-Quantum-Signaturen

Programme zur maschinellen Identitätsprüfung stehen vor zwei längst überfälligen Meilensteinen: der Reduzierung der Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 47 Tage und der Umstellung auf Post-Quanten-Algorithmen.

Das CA/Browser Forum hat eine stufenweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate beschlossen: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Jeder öffentlich erreichbare Endpunkt eines Clusters, wie beispielsweise ein Ingress-Controller, wird in der letzten Phase seine Zertifikate etwa achtmal jährlich erneuern. Dieser Rhythmus schließt manuelle Prozesse aus.

Die Migration nach der Quantenbeschleunigung folgt demselben Prinzip der frühzeitigen Vorbereitung. Das NIST veröffentlichte am 13. August 2024 mit FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) seine ersten Standards für postquantensichere Signaturen. Signaturen schützen die Vertrauenskette hinter jeder Maschinenidentität, und die CNSA-2.0-Richtlinie der NSA sieht bereits ab 2027 die ausschließliche Verwendung quantenresistenter Signaturen für nationale Sicherheitssoftware und Firmware der USA vor.

Die Integration von Krypto-Agilität in die Zertifikatsinfrastruktur, um Algorithmen ohne Neuarchitektur austauschen zu können, ist der erste praktische Schritt. Die zunehmende Verbreitung von KI-Agenten mit jeweils eigenen Anmeldeinformationen wird die Anzahl der Maschinenidentitäten weiter erhöhen.

Bewährte Verfahren zur Sicherung von Maschinenidentitäten in Kubernetes

Fünf Vorgehensweisen decken den Großteil des Risikos der Maschinenidentität in einem Kubernetes-Cluster ab.

1. RBAC nach dem Prinzip der geringsten Berechtigungen durchsetzen: Weisen Sie jedem Benutzer- und Dienstkonto die minimal erforderlichen Berechtigungen zu und überprüfen Sie die Rollenbindungen regelmäßig, da sich Berechtigungen im Zuge der Weiterentwicklung von Clustern ändern können.
2. Verwenden Sie ein Dienstkonto pro Arbeitslast: Dedizierte Servicekonten halten die Berechtigungen eng, und durch das Setzen von automountServiceAccountToken auf false für Pods, die den API-Server nie aufrufen, wird eine unnötige Anmeldeinformation vollständig entfernt.
3. Zugangsdaten sollten nur kurz gültig sein: Setzen Sie auf gebundene Dienstkonto-Tokens anstatt auf manuell erstellte Secret-Tokens und automatisieren Sie die Zertifikatsausstellung und -erneuerung mit cert-manager, damit das Ablaufdatum nie von einer Kalendererinnerung abhängt.
4. Verschlüsseln Sie den Datenverkehr zwischen Diensten mit mTLS: Ein Service Mesh wie Istio oder Linkerd authentifiziert beide Enden jeder Verbindung und verschlüsselt den Datenverkehr zwischen ihnen, ohne dass Änderungen an der Anwendung erforderlich sind.
5. Überwachung und Prüfung der Identitätsnutzung: Kubernetes-Audit-Logs protokollieren, welche Identität welche Aktionen ausgeführt hat; sie warnen bei ungewöhnlichen Mustern, beispielsweise wenn ein Servicekonto APIs aufruft, die es noch nie verwendet hat. Der NSA/CISA Kubernetes Hardening Guide (v1.2) dient als Referenz.

Wie Verschlüsselungsberatung hilft

CertSecure Manager ist die Plattform für das Zertifikatslebenszyklusmanagement von Encryption Consulting. Sie automatisiert die Ausstellung, Verlängerung und den Widerruf von Maschinenidentitäten über lokale und Cloud-Zertifizierungsstellen hinweg – alles über ein zentrales Dashboard. Die Ausstellungsrichtlinien werden durch Genehmigungsworkflows, CSR-Beschränkungen und rollenbasierte Zugriffsrechte auf Zertifikatvorlagen durchgesetzt. Ablaufbenachrichtigungen werden über Teams, E-Mail und ServiceNow versendet. Diese Kombination verhindert, dass häufige Zertifikatswechsel in Kubernetes zu Ausfällen oder Beanstandungen bei Audits führen. Die Plattform basiert auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.

Häufig gestellte Fragen

Was ist eine Maschinenidentität in Kubernetes?

Eine Maschinenidentität in Kubernetes ist ein Attribut, das eine nicht-menschliche Komponente wie einen Pod, Knoten, Dienst oder Controller authentifiziert. Die gängigsten Formen sind X.509-Zertifikate, gebundene Dienstkontotoken und kryptografische Schlüssel. Jede Workload stellt ihre Identität bereit, damit der API-Server und andere Dienste überprüfen können, wer die Anfrage stellt, bevor sie Zugriff gewähren.

Wie lässt sich Zero Trust auf Kubernetes anwenden?

Zero Trust, definiert in NIST SP 800-207, beseitigt das Vertrauen basierend auf dem Netzwerkstandort. Angewendet auf Kubernetes bedeutet dies, dass jede Pod-zu-Pod-, Pod-zu-API-Server- und Cluster-zu-externe-Verbindung bei jeder Anfrage authentifiziert und autorisiert wird, üblicherweise mit gegenseitiger TLS-Authentifizierung und rollenbasierter Zugriffskontrolle (RBAC) nach dem Least-Privilege-Prinzip, anstatt einfach allem zu vertrauen, nur weil es sich innerhalb des Clusternetzwerks befindet.

Was hat die langlebigen Service-Account-Tokens in Kubernetes ersetzt?

Gebundene Service-Account-Tokens ersetzten sie. Gebundene Tokens wurden in Kubernetes 1.22 stabilisiert: Sie sind zeitlich begrenzt, zielgruppengebunden und an einen bestimmten Pod gebunden; der Kubelet rotiert sie automatisch. Seit Kubernetes 1.24 erstellt die Steuerungsebene keine langlebigen, auf Secrets basierenden Tokens mehr automatisch für neue Service-Accounts, und eine Bereinigungsfunktion für ungenutzte Legacy-Tokens wurde in Version 1.30 stabilisiert.

Benötige ich ein Service Mesh, um Maschinenidentitäten in Kubernetes zu sichern?

Nein, aber ein Service Mesh ermöglicht die praktische Nutzung von Mutual TLS in großem Umfang. Meshes wie Istio und Linkerd stellen kurzlebige Zertifikate für jede Workload aus und verschlüsseln den Datenverkehr zwischen Diensten, ohne dass Anwendungsänderungen erforderlich sind. Auch ohne Mesh können Sie cert-manager für die Zertifikatsautomatisierung, gebundene Service-Account-Token, RBAC und Netzwerkrichtlinien kombinieren, um die meisten Risiken im Zusammenhang mit Maschinenidentitäten abzudecken.

Wie wirken sich 47-Tage-TLS-Zertifikate auf Kubernetes-Cluster aus?

Das CA/Browser Forum reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate schrittweise: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Jedes Zertifikat, das ein Cluster öffentlich bereitstellt, wie z. B. Ingress-Endpunkte, muss automatisch ausgestellt und erneuert werden, da eine manuelle Rotation mit einem 47-Tage-Zyklus nicht Schritt halten kann.

Automatisieren Sie die Lebenszyklen der Maschinenidentitäten in Ihren Clustern

Erleben Sie CertSecure Manager live mit Ihren eigenen Zertifikaten oder sprechen Sie mit einem PKI-Berater über die Implementierung von Zero-Trust-Identitätskontrollen in Ihren Kubernetes-Clustern. ISO/IEC 27001:2022-zertifiziert.