Kubernetes-Security, Teil 1: Von Linux geerbte Konzepte

Kubernetes ist das De-facto-Orchestrierungssystem für Containertechniken. Zeit, einen vernachlässigten Aspekt zu beleuchten: Wie steht es um die Sicherheit?

Lesezeit: 25 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 2 Beiträge
Kubernetes-Security, Teil 1: Von Linux geerbte Konzepte

(Bild: Illus_man/Shutterstock.com)

Von
  • Thomas Fricke
Inhaltsverzeichnis

Die Verbreitung von Kubernetes hat in den letzten Jahren sprunghaft zugenommen. Aus dem Umfeld sicherheitskritischer Anwendungen erreichten den Autor zuletzt zunehmend Anfragen nach der Bewertung existierender Cluster. Wenn nicht mehr nur Pokémon, sondern auch Anwendungen, die unter die Kritis-Verordnung fallen, unter Kubernetes laufen sollen, ist es an der Zeit, das Thema Sicherheit für Container und Kubernetes genauer zu beleuchten. Zugleich gibt es Nachholbedarf im Bereich der Sicherheitsstandards. Das Thema ist komplex, die existierenden Bausteine werden ihm bisher nicht gerecht. Der bis zum 20. Mai zum Kommentar offene Draft zeigt zahlreiche Änderungen zu der ursprünglichen Fassung aus dem Jahr 2018 und geht in die richtige Richtung. Es fehlen aber immer noch Bausteine zur Automatisierung, Audits wie Einbettung in Deployment Pipelines und das Scannen von Containern. Das amerikanische National Institute of Standards (NIST) hat eine Publikation veröffentlicht, die die Orchestrierung von Containern durch Kubernetes untersucht.

Kubernetes-Security - die Serie

In der Sicherheitsarchitektur von Kubernetes sind zahlreiche Elemente miteinander verwoben, die die Beiträge dieser Artikelstrecke jeweils vorstellen:

Sicherheitsanalysen gehen von den drei Schutzzielen Diskretion, Integrität und Verfügbarkeit aus, die im Original "Confidentiality, Integrity and Availibility" (CIA) lauten. Im Zeitalter von Automatisierung, agilen Methoden und DevOps reicht es jedoch nicht, nur die Ziele zu betrachten. Der Automatisierungsgrad und die Auditierbarkeit der Systeme sind in Betracht zu ziehen. Während DevOps seinen zehnten Geburtstag feiert und sogar ein schlecht umgesetzter DevOps-Ansatz besser zur Prozessoptimierung geeignet zu sein scheint als das klassische V-Modell und Wasserfall, ist es an der Zeit, auch die Schattenseiten des Ansatzes zu beleuchten. In der Praxis werden Produktionspasswörter weiterhin oft im Klartext im Entwickler-Repository gespeichert, Datenbankpasswörter häufig nicht geändert – Beispiele schlecht gelebter Sicherheit gibt es zuhauf.

Kubernetes bietet viele Möglichkeiten, die Sicherheit zu verbessern. Dabei ist nicht alles Gold, was auf Konferenzen wie der KubeCon glänzt. Auf der einen Seite bringt Kubernetes genau die Komplexität, nach der neue, zunehmend größere Anwendungen verlangen. Andererseits ist die Komplexität nicht leicht zu beherrschen. Es ist an der Zeit, das Thema zu ordnen und Kubernetes in DevSecOps, oder besser SecDevOps, mit Sicherheit an erster Stelle einzuordnen. Eine Übersicht über DevSecOps ist nicht einfach. Der neuseeländische IT-Berater und Management-Trainer Rob England hat in seinem Blog ITSkeptic.org Definitionen von DevOps zusammengetragen. Die aktuellste Fassung dürfte seine Definition aus dem Mai 2017 sein:

"DevOps ist agile IT-Bereitstellung. Es ist ein ganzheitliches System, das den gesamten Wertefluss vom Geschäftsbedarf bis zur Live-Software umfasst. DevOps ist eine Kultur, keine Methode, auch kein Framework, Wissensfundus oder (noch gruseliger) etwa ein Verkaufswerkzeug. DevOps ist das Konzept der Zusammenführung von Entwicklung und Wartung auf der Ebene von Kultur, System, Praxis und Werkzeugen, um Kunden durch Qualitätsverbesserung schneller und häufiger brauchbare Ergebnisse auszuliefern. Kultur ist Verhalten, Teamwork, Verantwortlichkeit und Verantwortung, Vertrauen und Handlungsspielraum. Die Praxis sind Politik, Rollen und Transparenz bei den Zuständigkeiten (z.B. nach der RACI-Matrix), Prozesse und Verfahrensweisen, Metriken und Berichte, Leistungskennzahlen (Key Performance Indicators - KPI) und Verbesserungen. Werkzeuge sind die gemeinsamen Fähigkeiten, das Herstellen von Werkzeugen miteinander und füreinander sowie gemeinsame Technologieplattformen."

Analog zu dieser DevOps-Definition könnte eine grobe Landkarte folgendermaßen aussehen:

Übersicht der Bereiche und Etappen des Entwickelns: DevOps, DevSecOps, Kubernetes und Clouds im Vergleich (Abb. 1)

Von der Entwicklung bis zum Auditieren eines Produktionssystems ist die Sicherheit schrittweise zu erhöhen, alle Schritte sollten sich automatisieren lassen. Dazu gehören in eine vollständige Continuous-Integration- und Continuous-Deployment-Pipeline das automatisierte Bauen im Container ohne Docker, wie mit Buildah oder Source to Image, automatisiertes Testen, automatisiertes Penetration Testing, beispielsweise mit OWASP ZAP, genauso wie der automatische Export der Kubernetes-Audit-Logs in eine Datenbank.

Kubernetes liefert einen wesentlichen Beitrag zu DevSecOps durch das Ermöglichen von GitOps oder Configuration as Code. Jeder Schritt lässt sich in einem Repository nachvollziehen. Selbst die Audit Logs werden automatisch generiert und können durch Anomaly Detection mit oder ohne Machine Learning in die Automatisierung einbezogen werden.