Kubernetes-Sicherheit in der Praxis

Kubernetes-Sicherheit erfordert die Behebung bekannter Sicherheitsschwachstellen während der Build-Phase, die Neukonfiguration von Fehlkonfigurationen während der Build-/Bereitstellungsphase und das Reagieren auf Bedrohungen zur Runtine. Dies entspricht den Antworten, die im Rahmen der neuesten Version des Berichts „State of Kubernetes and Container Security" gesammelt wurden. Es wurde übereinstimmend festgestellt, dass 24 % der schwerwiegenden Containersicherheitsprobleme behebbare Schwachstellen waren. Fast 70 % waren Fehlkonfigurationen, und 27 % waren Runtime-Vorfälle.

Container sind überall

Kubernetes ist eine Open Source Container-Orchestrierungsplattform, die verwendet wird, um Hunderte (manchmal Tausende) von Linux®-Containern zu verwalten, die in Clustern zusammengefasst sind. Kubernetes stützt sich stark auf APIs (Application Programming Interface), mit denen containerisierte Microservices verbunden werden. Diese verteilte Arbeitsweise macht es schwierig, schnell zu untersuchen, welche Container möglicherweise Schwachstellen aufweisen, falsch konfiguriert sind oder die größten Risiken für Ihr Unternehmen darstellen.

Die Lösung besteht darin, eine umfassende Ansicht der Container-Deployments zu entwickeln, die kritische Events auf Systemebene in jedem Container erfasst.

Fehlverwendung von Images und Registries

Container-Images (auch als Basis-Images bezeichnet) sind unveränderliche Vorlagen, die zum Erstellen neuer Container verwendet werden. Neu kopierte Container-Images können für unterschiedliche Zwecke bearbeitet werden.

Die Lösung besteht darin, Richtlinien einzurichten, die bestimmen, wie Images erstellt und in Image-Registries gespeichert werden. Basis-Images müssen regelmäßig getestet, genehmigt und gescannt werden. Zum Starten von Containern in einer Kubernetes-Umgebung dürfen nur Images aus zulässigen Image-Registries verwendet werden.

Ungehemmte Containerkommunikation

Container und Pods müssen innerhalb von Deployments miteinander sowie mit anderen internen und externen Endpunkten kommunizieren, um ordnungsgemäß zu funktionieren. Wenn ein Container gehackt wird, bestimmt das Ausmaß der Kommunikation dieses Containers mit anderen Containern und Pods die Bewegungsfreiheit des Hackers innerhalb der Umgebung. Angesichts der Komplexität der manuellen Konfiguration der entsprechenden Richtlinien kann die Implementierung der Netzwerksegmentierung in einer weitläufigen Containerumgebung äußerst schwierig sein.

Die Lösung besteht darin, den Datenverkehr zwischen Namespaces, Deployments und Pods zu verfolgen, und zu bestimmen, wie viel von diesem Verkehr tatsächlich erlaubt ist.

Standardrichtlinien für das Container-Netzwerk

Standardmäßig wenden Kubernetes-Deployments keine Netzwerkrichtlinie auf einen Pod – die kleinste Einheit einer Kubernetes-Anwendung – an. Diese Netzwerkrichtlinien habe eine ähnliche Funktion wie Firewall-Regeln. Sie steuern, wie Pods miteinander kommunizieren. Ohne Netzwerkrichtlinien kann jeder Pod mit jedem anderen Kontakt aufnehmen. 

Die Lösung besteht darin, Netzwerkrichtlinien zu definieren, welche die Pod-Kommunikation nur auf definierte Assets beschränken, und Secrets in schreibgeschützten Volumes innerhalb von Containern bereitzustellen, anstatt sie als Umgebungsvariablen zu übergeben.

Compliance bei Containern und Kubernetes

Cloudnative Umgebungen, die von Kubernetes unterstützt werden, sollten (wie alle anderen IT-Umgebungen) Best Practices für Sicherheit, Branchenstandards, Benchmarks und interne Unternehmensrichtlinien einhalten – und die entsprechende Compliance nachweisen. Dies erfordert manchmal die Anpassung von Compliance-Strategien, damit Kubernetes-Umgebungen Sicherheitskontrollen erfüllen, die ursprünglich für herkömmliche Anwendungsarchitekturen geschrieben wurden.

Die Lösung besteht darin, die Einhaltung der Compliance zu überwachen und Audits zu automatisieren.

Runtime

Kubernetes ist eine unveränderliche Infrastruktur. Das Patchen ist während der Container-Runtime nicht möglich – laufende Container müssen zerstört und neu erstellt werden. Gehackte Container können bösartige Prozesse wie Krypto-Mining und Port-Scanning ausführen.

Die Lösung besteht darin, jeden gehackten oder laufenden Container zu zerstören, ein fehlerfreies Container-Image neu zu erstellen, und es dann neu zu starten.

Kubernetes-Sicherheit beginnt in der Build-Phase mit der Erstellung starker Basis-Images und der Einführung von Scans auf Schwachstellen.

• Verwenden Sie minimale Basis-Images. Vermeiden Sie die Verwendung von Images mit Paketmanagern oder Shells des Betriebssystems (OS), die unbekannte Sicherheitslücken enthalten könnten, oder entfernen Sie den Paketmanager später.

• Fügen Sie keine nicht benötigten Komponenten hinzu. Als Faustregel gilt, dass gängige Tools, wenn sie in Images enthalten sind, zu Sicherheitsrisiken werden können.

• Verwenden Sie ausschließlich aktualisierte Images. Bringen Sie die Versionen von Komponenten auf den neuesten Stand.

• Verwenden Sie einen Image-Scanner. Identifizieren Sie Schwachstellen in Images – aufgeschlüsselt nach Schichten.

• Integrieren Sie Sicherheit in CI/CD-Pipelines. Automatisieren Sie einen reproduzierbaren Sicherheitsaspekt, der bei Continuous Integration-Builds fehlschlägt, und generieren Sie Warnungen für schwerwiegende, behebbare Schwachstellen.

• Kennzeichnen Sie dauerhafte Schwachstellen. Listen Sie bekannte Schwachstellen, die nicht behoben werden können, nicht kritisch sind oder nicht sofort behoben werden müssen, in einer Zulassungsliste auf. 

• Implementieren Sie Defense-in-Depth. Standardisieren Sie Richtlinienüberprüfungen und Behebungsworkflows, um anfällige Images zu erkennen und zu aktualisieren.

Konfigurieren Sie die Sicherheit der Kubernetes-Infrastruktur vor dem Deployment von Workloads. Das beginnt damit, dass Sie so viel wie möglich über den Deployment-Prozess wissen: was bereitgestellt wird (Image, Komponenten, Pods), wo es bereitgestellt wird (Cluster, Namespaces und Knoten), wie es bereitgestellt wird (Berechtigungen, Kommunikationsrichtlinien, Sicherheitsmaßnahmen), worauf zugegriffen werden kann (Secrets, Volumes). Machen Sie sich mit den Compliance-Standards vertraut.

• Verwenden Sie Namespaces. Das Aufteilen von Workloads in Namespaces kann dazu beitragen, Attacken einzudämmen und die Auswirkungen von Fehlern oder destruktiven Aktivitäten durch autorisierte Benutzer zu begrenzen.

• Verwenden Sie Netzwerkrichtlinien. Standardmäßig erlaubt Kubernets jedem Pod, jeden anderen Pod zu kontaktieren. Mit Richtlinien zur Netzwerksegmentierung können Sie diesen Standard überschreiben.

• Beschränken Sie Zugriffsberechtigungen auf Secrets. Stellen Sie nur Secrets bereit, die von Deployments unbedingt benötigt werden.

• Überprüfen Sie Container-Berechtigungen. Geben Sie nur die Funktionen, Rollen und Berechtigungen an, die es dem Container ermöglichen, seine Funktion auszuführen. 

• Überprüfen Sie die Provenienz von Images. Verwenden Sie Images von bekannten Registries.

• Scannen Sie Deployments. Erzwingen Sie Richtlinien, die auf den Ergebnissen des Scans beruhen. 

• Verwenden Sie Labels und Annotations. Kennzeichnen oder beschriften Sie Deployments mit den Kontaktinformationen des Teams, das für eine containerisierte Anwendung verantwortlich ist, um die Triage zu optimieren.

• Aktivieren Sie Role-based Access Control (RBAC). RBAC steuert die Autorisierung von Benutzern und Service-Accounts für den Zugriff auf den Kubernetes-API-Server eines Clusters.

Proaktive Sicherheitsansätze in der Build- und Deployment-Phase können die Wahrscheinlichkeit von Sicherheitsvorfällen während der Runtime verringern, aber das Erkennen und Reagieren auf Runtime-Bedrohungen erfordert eine kontinuierliche Überwachung der Prozessaktivität und der Netzwerkkommunikation.

• Verwenden Sie kontextbezogene Informationen. Verwenden Sie die Build- und Deployment-Time-Informationen in Kubernetes, um beobachtete und erwartete Aktivitäten während der Runtime auszuwerten, um verdächtige Aktivitäten zu erkennen.

• Scannen Sie laufende Deployments. Überwachen Sie laufende Deployments auf dieselben kürzlich entdeckten Schwachstellen, die in Container-Images entdeckt wurden.

• Verwenden Sie integrierte Sicherheitskontrollen. Konfigurieren Sie den Sicherheitskontext für Pods, um ihre Funktionen einzuschränken.

• Überwachen Sie den Datenverkehr im Netzwerk. Beobachten und vergleichen Sie den Live-Netzwerkverkehr mit den Kubernetes-Netzwerkrichtlinien, um unerwartete Kommunikation zu erkennen.

• Verwenden Sie Genehmigungslisten. Benennen Sie Prozesse, die während der normalen Runtime der Anwendung ausgeführt werden, um eine Genehmigungsliste zu erstellen.

• Vergleichen Sie die Runtime-Aktivität in ähnlichen Pods des Deployments. Replikate mit signifikanten Abweichungen müssen untersucht werden.

• Skalieren Sie verdächtige Pods auf null. Verwenden Sie die Kubernetes-native Sicherheitskontrollen, um Sicherheitsverletzungen einzudämmen, indem Sie Kubernetes automatisch anweisen, verdächtige Pods auf Null zu skalieren oder Instanzen zu zerstören und neu zu starten.

Sicherheit umfasst mehr als Images und Workloads. Sicherheit umfasst die gesamte Kubernetes-Infrastruktur: Cluster, Nodes, die Container-Engine und sogar Clouds.

• Führen Sie Kubernetes-Updates durch. Wenn Sie Ihre Kubernetes-Distribution aktualisieren, werden Sicherheitspatches angewendet und neue Sicherheitstools installiert.

• Konfigurieren Sie den Kubernetes-API-Server. Deaktivieren Sie den nicht authentifizierten/anonymen Zugriff, und verwenden Sie die TLS-Verschlüsselung für Verbindungen zwischen Kubelets und dem API-Server.

• Secure etcd. etcd ist ein Schlüsselwertspeicher, der von Kubernetes für den Datenzugriff verwendet wird. Sichern Sie das Kubelet Deaktivieren Sie den anonymen Zugriff auf das Kubelet, indem Sie das Kubelet mit dem Flag --anonymous-auth=false starten, und verwenden Sie den NodeRestriction-Zugangscontroller, um die Zugriffsmöglichkeiten des Kubelets einzuschränken.

Cloud-Sicherheit

Unabhängig davon, welche Art von Cloud (Public Cloud, Private Cloud, Hybrid Cloud oder Multi-Cloud) die Container hostet oder Kubernetes ausführt, ist immer der Cloud-Nutzer und nicht der Cloud-Provider für die Sicherung der Kubernetes-Workload verantwortlich, einschließlich:

• Container-Images: Quellen, Inhalte und Schwachstellen

• Deployments: Netzwerk-Services, Storage und Berechtigungen

• Konfigurationsmanagement: Rollen, Gruppen, Rollenbindungen, Service-Accounts

• Anwendung: Secrets-Management, Labels und Annotations

• Netzwerksegmentierung: Netzwerkrichtlinien im Kubernetes-Cluster

• Runtime: Bedrohungserkennung und Incident Response

Die Verwendung von Containern und Kubernetes ändert nichts an der Zielstellung ihrer Sicherheit: die Verringerung von Schwachstellen

• Sorgen Sie frühzeitig im Container-Lifecycle für die Sicherheit. Die Sicherheit sollte es Entwicklern und DevOps-Teams ermöglichen, produktionsreife Anwendungen sicher zu erstellen und bereitzustellen.

• Verwenden Sie Kubernetes-native Sicherheitskontrollen. Native Kontrollen verhindern, dass Sicherheitskontrollen mit dem Orchestrator in Konflikt kommen. 

• Überlassen Sie es Kubernetes, die Schadensbegrenzung zu priorisieren.