Wie sich Containerorchestrierung geschützt betreiben lässt

Vor allem in restriktiven Umgebungen bringt der Einsatz von Kubernetes einige Herausforderungen mit sich. Während sich der Artikel „Den Steuer­stand einrichten“ auf Seite 58 eher mit der strategischen Ebene dieser Auf­gabe befasst, stellt dieser Beitrag einige der Möglichkeiten praktisch vor, einen Kubernetes-Cluster in restriktiven Um­gebungen zu erstellen und verschiedene Richtlinien einzuhalten.

Was das Container-Ökosystem betrifft

Für eine sichere Basis sollte man Container-­Images für Applikationen immer als nicht privilegierter User starten. In den meisten Fällen reicht der Benutzer no­body mit der User ID 65534 für Anwendungsprozesse aus. Daher sollten Administratoren beim Bauen eines Containers darauf achten, dass sie unter der Direk­tive USER die User ID anstelle des Benutzernamens verwenden. Listing 1 zeigt ein Beispiel. Ein weiterer Vorteil der Methode: Kubernetes muss sich nicht auf ein einheit­liches Mapping von User-IDs zu Benutzernamen verlassen und weiß immer, mit welcher User-ID es den Container standardmäßig starten soll.

Auch sollten die Container-Images immer minimale Basis-Images benutzen, um den Angriffsvektor in einem Container zu minimieren. Hierfür können entweder die abgespeckten Images der Distributionen zum Einsatz kommen – beispielsweise debian:buster-slim, Red Hat Universal Base Image oder SUSEs JeOS – oder die schlanken Basis-Images von distroless (siehe ix.de/z8zt).

Die Container-Images sollte man regel­mäßig mit auf Container spezialisierten CVE-Scannern wie clair oder An­chore überprüfen. Einige Container-Registries wie goharbor bieten diesen Dienst ohne weitere Einstellungen standardmäßig an (siehe ix.de/z8zt). Ergänzend dazu empfiehlt es sich, auch laufende Container-­Images im Cluster regelmäßig damit zu untersuchen. Wenn der CVE-Scanner anschlägt, sollten Administratoren die gefundenen Sicherheitslücken zunächst bewerten. Ist das Risiko dieser Sicherheitslücke groß, müssen sie das Container-­Image mit dem Patch für die Sicherheitslücke neu bauen. Ist ein Basis-Image betroffen, sind zusätzlich alle darauf basierenden Images neu zu bauen und zu verteilen.

Zusätzliche Sicherheit gewinnt man, wenn Kubernetes die Signaturen der Container-Images überprüft. Das hat den Vorteil, dass die Nutzer auf dem Cluster nur si­gnierte Container-Images starten können. Hierfür lassen sich der Signaturserver Notary oder der Policy-Manager Grafeas in Verbindung mit einem der Kuber­netes-Admission-Controller verwenden.

Aufgaben beim Set-up des Kubernetes-Clusters

Kubernetes selbst bietet viele Konfigurationsmöglichkeiten, mit denen sich ein Cluster nach entsprechenden Sicherheitsrichtlinien erstellen lässt. Diese Konfigurationsmöglichkeiten sind häufig nur zu aktivieren oder einzurichten:

• Alle Komponenten im Kubernetes-­Cluster sollten mit x509-Zertifikaten abge­sichert sein und nur über TLS kommunizieren.
• Die etcd- und Kubernetes-PKIs sollten getrennt werden, um den Zugriff auf den etcd-Cluster nur den Instanzen der Kubern­etes-Server zu erlauben.
• Die Authentifizierung und Autorisierung der Kubelet-API sollte aktiviert werden, um den Zugriff darauf einzuschränken (siehe ix.de/z8zt).
• Für die Benutzerauthentifizierung ­sollte man das zentrale Identity-Managementsystem nutzen. Über eine Proxy-Komponente wie dex kann der Kubernetes-­Cluster die Benutzer über OIDC-Token authentifizieren. Die User können sich dabei mit ihren gewohnten Anmeldedaten am Cluster anmelden.
• Kubernetes’ interne Role-based Access Control (RBAC) erlaubt es, Rechte einzelner Benutzer und Gruppen einzuschränken. Zum Überprüfen der erstellten RBAC-Regeln bietet sich das Tool rakkess an, das die daraus resultierenden Zugriffsrechte optisch aufbereitet. Der Screenshot zeigt exemplarisch das Ergebnis für den Service-Account calico-­node.

Die offizielle Dokumentation beschreibt noch weitere Maßnahmen zum Absichern eines Kubernetes-Clusters. Die dort aufgeführten Schritte sind jedoch immer für den eigenen Anwendungsfall zu bewerten (siehe ix.de/z8zt).