tostphoto - stock.adobe.com
Kubernetes: Schutz von Maschinenidentitäten
Plattformen wie Kubernetes verlassen sich auf Maschinenidentitäten, um zu unterscheiden, was erlaubt ist oder nicht. Entsprechend wichtig ist die Verwaltung von X.509-Zertifikaten.
Identität ist der neue Perimeter und ein notwendiges Element in jeder Multi-Cloud-Strategie. Cloud-Dienste, Container, Service Meshes und Container-Orchestrierungsplattformen wie Kubernetes verlassen sich alle auf Maschinenidentitäten wie X.509 TLS-Zertifikate für eine sichere Machine-to-Machine-Kommunikation. Zu verstehen, was gut oder schlecht, privat oder öffentlich, erlaubt oder nicht ist, hängt von den Maschinenidentitäten ab.
Kubernetes hat sich zu einer etablierten Open-Source-Plattform entwickelt, mit der Entwickler ihre Container automatisiert verwalten können. Sie teilen den einzelnen Containern und den darin laufenden Anwendungen die jeweils benötigen Ressourcen zu, um eine schnelle Portabilität und größere Flexibilität bei der Anwendungsentwicklung zu erreichen. Durch die Flexbilität und einfache Skalierbarkeit wird sich Kubernetes zu dem wichtigsten Betriebssystem für die nächsten zehn bis 15 Jahre entwickeln und damit Linux ablösen. Um den oben beschriebenen Weg erfolgreich beschreiten zu können, ist es wichtig, dass wie bei jeder Softwareentwicklung maschinelle Identitäten wie digitale Zertifikate und kryptographische Schlüssel die Bedeutung erhalten, die sie verdienen. Für die Containerplattform sind diese kleinen Bausteine nämlich elementar.
In Kubernetes werden Maschinenidentitäten wie X.509-Zertifikate für die folgenden Aktivitäten genutzt:
- Client-Zertifikate für das Kubelet zur Authentifizierung am API-Server
- Serverzertifikat für den API-Server-Endpunkt
- Client-Zertifikate für Administratoren des Clusters zur Authentifizierung am API-Server
- Client-Zertifikate für den API-Server zur Kommunikation mit den Kubelets
- Client-Zertifikat für den API-Server zur Kommunikation mit etcd
- Client-Zertifikat/Kubeconfig für den Controller-Manager zur Kommunikation mit dem API-Server
- Client-Zertifikat/Kubeconfig für den Scheduler, um mit dem API-Server zu kommunizieren.
- Client- und Serverzertifikate für den Front-Proxy
Warum ist die automatisierte Verwaltung von Maschinenidentitäten so wichtig?
Maschinenidentitäten wie X.509-Zertifikate haben sich für Sicherheitsteams immer als problematisch erwiesen. Zum einen ist Cybersicherheit keine Kernkompetenz von Anwendungs- und Operation-Teams. Zum anderen kämpfen Sicherheitsteams allzu oft damit, Maschinenidentitäten mit einem ineffizienten Sammelsurium von Tabellenkalkulationen und Schnittstellen interner PKIs (Public-Key-Infrastruktur) und Zertifizierungsstellen (CAs) zu schützen, die keine Transparenz in ihrer IT-Umgebung bieten. Dies hat zu Vorfällen geführt, bei denen sich unbekannte Maschinenidentitäten zu kostspieligen zertifikatsbezogenen Ausfällen verwandelten. Beispiele für solche Vorfälle finden sich bei LinkedIn, O2, Softbank, Microsoft Azure und vielen anderen. Darüber hinaus werden massive Datenschutzverletzungen wie die von Equifax im Jahr 2017 oft durch nicht kartierte, auslaufende Zertifikate verschlimmert.
Die Umstellung auf Container, Microservices und Infrastruktur als Code stellt auch neue Herausforderungen an die Maschinenidentität. Die Dynamik der Infrastruktur erschwert die Aufgabe, die Kommunikation zwischen physischen und virtuellen Maschinen eindeutig zu identifizieren, zu autorisieren und zu sichern. Die schnelle Bereitstellung, Änderung und Widerrufung ihrer Identitäten erhöht exponentiell die Herausforderung, die Kommunikation zwischen Cloud-Arbeitslasten sicher zu halten. Da Maschinen heute zur Steuerung fast aller Aspekte unserer globalen digitalen Wirtschaft eingesetzt werden, ist die Notwendigkeit, die Integrität der Kommunikation zwischen Maschinen zu erstellen, zu installieren, schnell zu bewerten und sicherzustellen, von entscheidender Bedeutung und muss sofort skalierbar sein. Die meisten Unternehmen verfügen einfach nicht über die Technologie oder Automatisierung, um die große Anzahl von Maschinenidentitäten, die Unternehmen heute benötigen, genau zu überwachen und zu schützen.
Entwickler zerstören und initiieren Maschinenidentitäten in Minuten. Die Geschwindigkeit und das Änderungsvolumen machen es den manuellen Prozessen zur Ausstellung von Zertifikaten unmöglich, Schritt zu halten. Ohne eine standardisierte API- und CA-Infrastruktur, die über Entwicklungs-, Test-, Staging- und Produktionsumgebungen hinweg funktioniert, entscheiden sich Entwickler oft dafür, Skripte für jede Umgebung und jeden Anwendungsfall selbst zu erstellen und zu pflegen. Dieser Ansatz ist zeitaufwendig und führt oft zu Szenarien, in denen Personen, die keine PKI-Experten sind, die Möglichkeit haben, Zertifikatstypen, Schlüssellänge und Schlüsselspeicher sowie Verschlüsselungsalgorithmen auszuwählen. Sie können sogar Zertifikate von nicht autorisierten CAs verwenden, die häufig in die Produktionsumgebung gelangen. Ohne einfachen Zugang zu einer zugelassenen Quelle für Zertifikate setzen Entwickler versehentlich Compliance und Sicherheit aufs Spiel.
Ein besonderes Problem stellen deshalb unbefugte CAs da. Unbefugte Zertifizierungsstellen sind CAs, die nicht unternehmensweit zur Verwendung freigegeben sind. Rogue-Zertifikate von nicht autorisierten CAs erhöhen das Sicherheits- und Verfügbarkeitsrisiko und können auch die Benutzerfreundlichkeit von Anwendungen beeinträchtigen, wenn sie nicht von Grund auf vertrauenswürdig sind.
Schwachstellen nehmen zu
Zudem werden selbstverständlich auch immer wieder in den Plattformen gefunden. Bei einer Schwachstelle im Copy-Befehl hätte ein Angreifer unter der Mithilfe eines Implementierungsfehlers und unachtsamen Nutzers die volle Root-Kontrolle über das Host-System und alle anderen in Kubernetes betriebenen Container übernehmen können. Weitere Schwachstellen wurden außerdem in den Kubelet-Versionen 1.13.6 und 1.14.2 gefunden. Externe Akteure hätten hier User Interface Designs (UID) in Container-Images aushebeln können. Bei der ersten Ausführung auf einem Node werden zwar die festgelegten UIDs genutzt, beim zweiten Mal jedoch hätte es zu einer ungewollten Rechteerweiterung kommen können. Die Empfehlung zur Behebung dieser Schwachstelle liest sich dann wie blanker Hohn, nämlich eine der Vorgängerversionen von Kubelet 1.13.6 oder 1.14.2 zu nutzen.
Doch nicht nur Schwachstellen gefährden Kubernetes und deren verwaltete Docker-Landschaften, sondern auch reale Angriffsszenarien. Ein Beispiel dafür sind kompromittierte Container, die Malware herunterladen oder Systeme nach Schwachstellen und sensiblen Daten zu suchen. Oder wenn Angreifer über Schwachstellen unautorisierten Zugriff auf andere Container oder Systeme zu erlangen versuchen. Weitere Möglichkeiten wären die Manipulation einzelner Container, so dass immer mehr Ressourcen verbraucht werden, bis die in den Container laufenden Anwendungen abstürzen.
Lösungsansatz automatisierte Prozesse
Es gibt moderne Technologien, die sicherstellen können, dass nur autorisierter Code ausgeführt wird und erkennen, ob Code geändert wurde. Der erste Schritt zum Aufbau einer automatisierten Lösung für den Schutz der Maschinenidentität erfordert daher eine Standardisierung der Maschinenidentitätsprozesse. Um das Konzept von Rugged DevOps umzusetzen, müssen Workflows so gestaltet werden, dass sie den Anforderungen an Maschinenidentitäten gerecht werden. Indem die Bereitstellung von Zertifikaten als ein wesentlicher Schritt in der Konfiguration einer modernen Infrastruktur betrachtet wird, können Unternehmen die Machine-to-Machine-Kommunikation (M2M) über alle Arten von Infrastrukturen hinweg problemlos verschlüsseln.
Mit einem solchen Zertifikatsdienst können Firmen beginnen, die im gesamten Unternehmen verwendeten Zertifikate zu standardisieren und zu kontrollieren sowie in der Folge die sichere Softwarebereitstellung zu beschleunigen. Ein wesentlicher Vorteil der Standardisierung des Prozesses der Zertifikatsausstellung in einer Weise, die den Anforderungen von Informationssicherheit, späteren Betrieb und Softwareentwicklung entspricht, besteht darin, dass die Ausstellung zentral gesteuert und verwaltet werden kann. Unternehmen können dann die Bereitstellung sicherer und vertrauenswürdiger Zertifikate beschleunigen. Darüber hinaus muss die Zertifikatsausstellung in DevOps-Toolchains integriert werden. Die festgelegten Richtlinien zur Maschinenidentität müssen in allen DevOps-Umgebungen durchgesetzt werden. Die Verwendung von vertrauenswürdigen Zertifikaten unterstützt außerdem bei der Einhaltung von Compliance und hilft bei externen Auditierungen.
Sicherheitsteams wiederum müssen wissen, was sie als vertrauensvoll einstufen können und was nicht, um Maschinenidentitäten in dynamischen Umgebungen effektiv zu schützen. Infolgedessen muss die intelligente Durchsetzung von Richtlinien automatisiert und in die Tools der Anwendungsentwicklungsteams eingebettet werden. Durch die Verlagerung von Maschinenidentitätsprozessen in die Vorproduktionsphase und die direkte Einbindung in automatisierte DevOps-Workflows können Sicherheitsteams die Kontrolle über X.509-Zertifikate in vollautomatischen Umgebungen wiedererlangen.
Eine kleine Auswahl von Tools
Ein Tool zum Verwalten von Maschinenidentitäten ist der Cert-Manager von Jetstack. Das Programm ist ein cert-manager, der als Kubernetes Add-on zur Automatisierung der Verwaltung und Ausgabe von TLS-Zertifikaten aus verschiedenen Quellen genutzt wird. Sie stellt sicher, dass die Zertifikate gültig und regelmäßig auf dem neuesten Stand sind und versucht, die Zertifikate zu einem angemessenen Zeitpunkt vor Ablauf zu verlängern.
Ein weiteres Tool ist SPIFFE (Secure Production Identity Framework For Everyone). Es bietet eine sichere Identität in Form eines speziell entwickelten X.509-Zertifikats für jeden Workload in einer modernen Produktionsumgebung. Es erübrigt die Authentifizierung auf Anwendungsebene und die Konfiguration komplexer ACLs (Zugriffskontrolllisten) auf Netzwerkebene.
Ausblick: Service Mesh Security
Eine Möglichkeit für die Absicherung von Service Mesh ist istio. Istio befasst sich mit den Herausforderungen, denen sich Entwickler und Betreiber gegenübersehen, wenn monolithische Anwendungen auf eine verteilte Mikroservice-Architektur umgestellt werden. Der Begriff Service Mesh wird verwendet, um das Netzwerk von Microservices zu beschreiben, aus denen sich solche Anwendungen zusammensetzen, und die Wechselwirkungen zwischen ihnen.
„Durch die Automatisierung des Schutzes der Maschinenidentität für DevOps, können Unternehmen sicherstellen, dass den eigenen internen Richtlinien entsprochen wird.“
Kevin Bocek, Venafi
Da ein Servicenetz immer größer und komplexer wird, kann es schwieriger werden, es zu verstehen und zu verwalten. Zu den Anforderungen gehören Erkennung, Lastausgleich, Fehlerbehebung, Metriken und Überwachung. Ein Service Mesh hat auch oft komplexere betriebliche Anforderungen, wie A/B-Tests, Canary Rollouts, Ratenbegrenzung, Zugriffskontrolle und End-to-End-Authentifizierung. Es bietet Verhaltensanalysen und operative Kontrolle über das gesamte Servicenetz und bietet eine Komplettlösung, um die vielfältigen Anforderungen von Mikroservice-Anwendungen zu erfüllen.
Fazit
Zertifikatsbedingte Ausfälle, können vermieden werden, indem Zertifikate vor Ablauf automatisch verlängert oder ausgetauscht werden. CAs oder Cloud-Anbieter können ohne aufwendige Änderungen am Anwendungscode vollzogen werden. Ein automatisierter Zertifizierungsdienst, der in bestehende DevOps-Tools wie Kubernetes, Docker, Chef, HashiCorp Terraform und anderen integriert ist, bietet DevOps-Abteilungen eine automatisierte Zertifikatsausstellung und -bereitstellung innerhalb ihrer bestehenden Tools. Ein weiterer Vorteil der Arbeit mit einem automatisierten Zertifikatsdienst besteht darin, dass DevOps-Abteilungen den gleichen Dienst verwenden, der Zertifikate für den Rest des Unternehmens bereitstellt, so dass sie automatisch Zertifikate erhalten. Der zentrale Zertifikatsdienst sollte daher eine einfache Integration und den Zugriff von DevOps-Frameworks und anderen Programmierwerkzeugen unterstützen.
Durch die Automatisierung des Schutzes der Maschinenidentität für DevOps, können Unternehmen sicherstellen, dass den eigenen internen Richtlinien entsprochen wird. Auf diese Weise nutzen sie die Best Practices von traditionellen PKI- und Produktionsexperten, erhalten aber Zertifikate in der Geschwindigkeit der DevOps-Workflows. Die Vorteile der Automatisierung zur Verkürzung der Bereitstellungszeit für Zertifikate können tiefgreifend sein. Für einen großen Einzelhändler konnte die Automatisierung die Bereitstellungszeit für Zertifikate von fünf Tagen auf nur wenige Minuten reduzieren. Diese Art der Automatisierung beseitigt den Anreiz für DevOps-Abteilungen, kreative Wege zu finden, um die Ausstellung von Zertifikaten zu umgehen, ohne die Zeitpläne oder Workflows von DevOps zu beeinflussen. Letztlich sorgt dieser Ansatz für mehr Transparenz und dadurch auch mehr IT-Sicherheit für das Unternehmen, aber auch alle Kunden, die später die bereitgestellten Services nutzen wollen.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
