Wie können wir unsere Kubernetes-Cluster vor dem Einsatz bösartiger Container oder der Fehlkonfiguration bestehender Container schützen?
Bevor wir in die Tiefe gehen, um eine einigermaßen sichere Kubernetes-Umgebung aufzubauen, sollten wir besprechen, wie die Infrastruktur unserer Organisation bereitgestellt wird. Natürlich gibt es viele Möglichkeiten, dies zu tun, und die, die ich hier vorschlage, ist nur ein Vorschlag, der funktionieren könnte.
Initialisierung einessicheren Kubernetes-Clusters
Zunächst müssen wir Kubernetes-Cluster entweder in einer selbst gehosteten Lösung oder bei einem anderen verwalteten Cloud-Anbieter - Azure, GCP, AWS, Linode usw. - einrichten und betreiben. Die selbst gehosteten Lösungen (wie Openstack) bieten uns in der Tat mehr Kontrolle und Optionen, aber wir müssen uns größtenteils um die Sicherung unserer Kontrollebene kümmern. Dazu gibt es zahlreiche hochwertige Tutorials und Blogbeiträge, auf die ich hier nicht eingehen werde.
Diese Basisinfrastruktur (Cluster, Netzwerkinfrastruktur, Lastverteiler usw.) kann mit einer IaaC-Lösung (Infrastructure as a Code) wie Terraform oder Pulumi und auch gehostet und über Pipelines von CI-DevOps-Plattformen wie GitHub, GitLab oder Azurblau DevOps[11].
Sowohl Terraform als auch Pulumi verfügen über eine ausführliche Dokumentation zur Bereitstellung von Kubernetes-Clustern mit den entsprechenden Best Practices.
In diesem Cluster sollte eine Continuous Deployment (CD)-Lösung wie ArgoCD oder FluxCD verfügbar und konfiguriert sein, um ein bestimmtes (vorzugsweise geschlossenes) Repository in dem von uns gewählten Code-Repository (GitHub, GitLab, Azure DevOps usw.) zu überwachen, in dem die YAML-Dateien mit den Konfigurationen für unsere Geschäftsanwendungen gespeichert werden sollen. Der Zugriff auf dieses Repository muss sehr streng geregelt sein und sollte nur von Senior DevOps Engineers und ausgewählten erfahrenen Entwicklern erfolgen. Diese YAMLs sollten alles enthalten, was für die Bereitstellung der Geschäftsanwendungen erforderlich ist - Bereitstellungen/Statefulsets, Netzwerkdienste, horizontale Autoscaler, Ressourcenreservierungen, Integration mit geheimen Speichern usw. Auch wenn es sich um ein geschlossenes Repository handelt, gelten alle standardmäßigen Best Practices - es sollten keine sensiblen Informationen gespeichert werden - Passwörter, API-Schlüssel, private ssh-Schlüssel usw.
Dieses Repository sollte mit allen anderen Repositories, in denen unsere Geschäftsanwendungen gespeichert sind, integriert werden. Wenn diese aktualisiert werden und einen Container mit einem neueren Tag erstellen, wird eine Aktion ausgelöst, um das alte Tag durch das neue zu ersetzen, damit unsere CD-Lösung es aufnehmen kann.
Aufbau von sicheren Containern für Geschäftsanwendungen
Stellen wir uns vor, unser Unternehmen verfügt über ein Team von qualifizierten Entwicklern, die mit der Erstellung der containerisierten Anwendungen für das von uns unterstützte Unternehmen beauftragt sind.
Sie können Code-Scan-Anwendungen wie Snyk verwenden oder auch nicht, um ihren Code sicher zu halten, sollten aber die Best Practices für sicheren Code in der Sprache ihrer Wahl befolgen.
Nachdem sie ihren Code in die entsprechende Git-Lösung gepusht haben, kann die CI-Implementierung (Github-Action oder Gitlab-Pipelines (und Runner), Azure DevOps) mit der Durchführung von Routine-Unit-Tests beginnen, die in der Regel von den Entwicklern selbst definiert werden.
Diese Tools laufen in der CI-Pipeline und können den gesamten Bauprozess des Containers überwachen.
- Cosign kann das Image (genauer gesagt seinen Hash) mit einem eindeutigen Angebot des privaten Schlüssels des Entwicklers signieren, so dass wir sicher sein können, dass dieser Container von dem besagten Entwickler stammt, bevor er in unsere Container-Registry (Docker Hub, ACR usw.) eingestellt wird. Dies wäre nützlich, wenn die Registry kompromittiert wird und andere Rogue-Images gepusht werden, die den legitimen Container ersetzen;
- Trivy kann auch in einer CI-Pipeline als Teil des Build-Jobs ausgeführt werden und Scans durchführen, während der Container erstellt wird. Es verwendet eine vorkompilierte Datenbank, gegen die der Container gescannt wird. Es kann auch die Pipeline unterbrechen, wenn genügend Sicherheitslücken gefunden werden, und ein Fehlerprotokoll erstellen, das untersucht werden kann. Trivy kann auch verwendet werden, um Terraform .tf-Dateien auf Fehlkonfigurationen zu überprüfen.
Wenn beide Aufgaben abgeschlossen sind, haben wir einen neu erstellten, gescannten und signierten Container, der keine bekannten Sicherheitslücken enthält. Bitte denken Sie daran, dass die meisten Schwachstellen aus dem zugrunde liegenden Basis-Image stammen. Es ist eine gute Idee, Multiplayer-Builds zu verwenden, damit unser laufender Container die wenigsten Tools zur Verfügung hat, falls er kompromittiert wird. Offensichtliche No-No's sind curl, git, wget, make, Paketmanager, etc. Gute Ideen sind Scratch und Alpen-Linux. Auch ein regelmäßiger manueller Rebuild des Containers ist erwünscht. Das Basis-Image kann veraltet sein und bisher unbekannte Schwachstellen offenlegen.
Sobald der Container gebaut und in unserer Registry mit einem neuen Tag versehen ist, aktualisieren die Pipelines/Aktionen das neue Tag im DevOps-Repository (das von unserer CD-Lösung - ArgoCD oder FluxCD - überwacht wird), ziehen es in den Kubernetes-Cluster und stellen es bereit.
Es gibt mehrere Maßnahmen, die wir hier ergreifen sollten:
- Um die mit cosign erstellte Signatur zu überprüfen, können wir ein Tool wie Connaisseur verwenden, um zu verifizieren, dass das gezogene Image dasjenige ist, das der Entwickler in seiner Pipeline erstellt hat (so können wir verhindern, dass bösartige Images gezogen werden, wenn unser Container-Repository kompromittiert ist). Es benötigt den öffentlichen Schlüssel, der dem privaten Schlüssel entspricht, der zum Signieren des Containers verwendet wurde, und kann die Bereitstellung unterbrechen.
- Wir können überprüfen, ob der Sicherheitskontext, die Ressourcenanforderungen und andere Richtlinien, die das Bild orchestrieren, dem Industriestandard entsprechen. Hier können wir auch Trivy der im Cluster als Operator laufen kann und sowohl Sicherheitslücken als auch Fehlkonfigurationen aufspürt und Berichte als CRs oder Datree das eine großartige Web-UI mit einer großen Anzahl von integrierten und anpassbaren Richtlinien bietet. Leider gibt es nur eine Testversion für 14 Tage. Beide unterstützen auch Arbeitsmappen, die die Bereitstellung beenden können, wenn eine kritische Fehlkonfiguration oder Sicherheitslücke gefunden wird.
Bislang haben wir Container gebaut, gescannt und mit aktiviertem sicherem Kontext, Ressourcenbeschränkungen usw. bereitgestellt. Wir sollten das Verhalten dieser Container überwachen, die Anfragen, die sie an den Linux-Kernel der zugrunde liegenden Kubernetes-Knoten stellen. Diese Art der Überwachung muss sehr gut auf die Umgebung zugeschnitten sein, da viele Aufrufe zwar harmlos sein können, aber dennoch markiert werden, sodass ein Überblick über alle Komponenten in der Umgebung erforderlich ist.
Zwei bekannte Tools, die für diese Aufgabe geeignet sind, sind Falco von SysDig und NeuVector jetzt im Besitz von SUSE. Beide können im Cluster eingesetzt werden und bieten auch Webhooks zum Beenden von Containern mit Fehlverhalten (z. B. wenn ein Terminal in einer Produktionsumgebung geöffnet wird). Sie können auch in Benachrichtigungslösungen wie Slack, Teams, Rocketchat usw. integriert werden.
Diese Tools können so konfiguriert werden, dass sie eine große Anzahl von Systemaufrufen von und zu unseren laufenden Pods (Containern) überwachen, und wir können eine strenge Kontrolle über sie ausüben.
Schlussfolgerung
Schließlich sind alle hier aufgeführten Tools nur automatisierte Werkzeuge, die Telemetriedaten an den Sicherheitsbeauftragten liefern. Es liegt an uns, die richtigen Regeln und Richtlinien zu entwickeln, damit unsere Cluster sicherer und widerstandsfähiger werden können.
