Best Practices für Kubernetes-Sicherheit

Die Implementierung von Best Practices für die Kubernetes-Sicherheit umfasst die Behebung bekannter Sicherheitsschwachstellen während der Build-Phase, die Neukonfiguration von Fehlkonfigurationen während der Build-/Deployment-Phase, die Reaktion auf Bedrohungen zur Runtime und die Sicherung der gesamten Kubernetes-Infrastruktur. 

Dies entspricht den Antworten zu den wichtigsten Sicherheitsbedenken, die im Rahmen der neuesten Version des Berichts „State of Kubernetes Security Report“ gesammelt wurden. Dieser ergab, dass mehr als 50 % der Befragten aufgrund der hohen Anpassungsfähigkeit von Kubernetes und der Komplexität der Container-Sicherheit über Fehlkonfigurationen und Schwachstellen besorgt sind. Unternehmen müssen der Sicherheit von Kubernetes während des gesamten Entwicklungs-Lifecycles Priorität einräumen, um Sicherheitsherausforderungen zu bewältigen und Verlangsamungen bei der Anwendungsbereitstellung zu vermeiden.

Container sind überall

Kubernetes ist eine quelloffene Container-Orchestrierungsplattform, mit der Hunderte (manchmal Tausende) von Linux®-Containern verwaltet werden können, die in Kubernetes-Clustern zusammengefasst sind. Kubernetes stützt sich stark auf APIs (Application Programming Interfaces), 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.

Uneingeschränkte Container-Kommunikation

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 Container-Umgebung ä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.

So kann Red Hat für eine sichere Container-Kommunikation sorgen

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, die unbekannte Sicherheitslücken enthalten könnten, oder entfernen Sie den Paketmanager später.

• Verwenden Sie vertrauenswürdige Quellen. Wählen Sie nur Basis-Images, die aus einer vertrauenswürdigen Quelle stammen und in einer anerkannten Registry gehostet werden.

• 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 Fehlerbehebungsworkflows, 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, Angriffe einzudämmen und die Auswirkungen von Fehlern oder destruktiven Aktivitäten durch autorisierte Benutzer zu begrenzen.

• Verwenden Sie Netzwerkrichtlinien. Kubernetes lässt standardmäßig zu, dass Pods untereinander in Kontakt treten, aber die Richtlinien zur Netzwerksegmentierung und die Plugins, die den ein- und ausgehenden Datenverkehr der Anwendung kontrollieren, können 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 der 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.

Sicherheitsvorfälle treten seltener auf, wenn Best Practices für die Sicherheit von Kubernetes während der Build- und Deployment-Phase angewendet werden. Das Erkennen und Reagieren auf Runtime-Bedrohungen erfordert jedoch eine kontinuierliche Überwachung der Prozessaktivitäten 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 Zulassungslisten. Benennen Sie Prozesse, die während der normalen Runtime der Anwendung ausgeführt werden, um eine Zulassungsliste 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 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.

Kubernetes-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-Distributionen aktualisieren, werden Sicherheits-Patches angewendet und neue Sicherheitstools installiert.

• Sichern Sie den Kubernetes-API-Server. Der Kubernetes-API-Server ist das Gateway zur Kubernetes-Control Plane. Deaktivieren Sie den nicht authentifizierten/anonymen Zugriff, und verwenden Sie die TLS-Verschlüsselung für Verbindungen zwischen Kubelets und dem API-Server. Die Audit-Protokollierung sollte ebenfalls aktiviert werden, um einen Einblick in atypische API-Aufrufe zu erhalten.

• Sichern Sie etcd. etcd ist ein Schlüssel-Wert-Speicher, der von Kubernetes für den Datenzugriff verwendet wird. Sichern Sie das Kubelet, um die Angriffsfläche zu minimieren. 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-Nutzende und nicht der Cloud-Anbieter für die Sicherung der Kubernetes-Workload verantwortlich, einschließlich:

• Container Images: Quellen, Inhalte und Schwachstellen

• Deployments: Netzwerkservices, Storage und Berechtigungen

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

• Anwendung: Kubernetes-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 und Sicherheitsrisiken.

• Integrieren Sie Best Practices für die Sicherheit frühzeitig in den Container-Lifecycle. Kubernetes-Sicherheit sollte es Entwicklungs- und DevOps-Teams ermöglichen, produktionsbereite Anwendungen sicher zu erstellen und bereitzustellen.

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

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