Container-Workloads schützen Container-Sicherheit unter Kubernetes

Container-Sicherheit ist ein Thema, das Unternehmen nicht vernachlässigen sollten. Zur Absicherung von Containern bietet Kubernetes mehrere Sicherheitsschichten, die es im Rahmen eines „Defense-in-depth“-Ansatzes zu berücksichtigen gilt.

Container sind weniger komplex als virtuelle Maschinen und daher generell sicherer. Da sie sich eine Betriebssysteminstanz teilen, müssen nicht mehrere Betriebssysteme auf derselben Hardware ausgeführt werden, was die Anzahl potenzieller Angriffspunkte verringert. Patches sind zudem nur auf Kernel-Ebene erforderlich. Dies macht Container einfacher und flexibler als virtuelle Maschinen. Container-Sicherheit ist dennoch ein Thema, das Unternehmen nicht vernachlässigen sollten. Sowohl die Absicherung von containerisierten Anwendungen als auch der Zugriff auf Kubernetes selbst sind dabei entscheidend.

Verschiedene Mechanismen und Einschränkungsoptionen

Da die Kubernetes-API die zentrale Steuereinheit eines Kubernetes-Clusters ist, muss der Zugang zu ihr ordnungsgemäß gesichert werden. Dies kann damit beginnen, den Kubernetes-API-Endpunkt in ein privates Netzwerk einzubinden. Vor allem ist jedoch die ordnungsgemäße Verwendung von Authentifizierungs- und Autorisierungs­mechanismen erforderlich.

Um eine Anfrage zu authentifizieren, bietet Kubernetes verschiedene Mechanismen. Hierzu zählen TLS-Client-Zertifikate, OIDC (OpenID Connect), Service Account-Tokens und statische Tokens. Um eine Anfrage zu autorisieren, d. h. ob der authentifizierte Benutzer die angeforderte Aktion durchführen darf, steht eine rollenbasierte Zugriffskontrolle (RBAC) zur Verfügung. Rollen können Benutzern oder Gruppen zugewiesen werden und sollten nur das Nötigste erlauben, damit Benutzer ihre Arbeit ausführen können. Insbesondere clusterweite Berechtigungen gilt es streng zu überwachen und mit Bedacht zu vergeben.

Namespaces ermöglichen die Trennung von Einzelpersonen oder Teams und deren Workloads und geben Cluster-Administratoren die Möglichkeit, RBAC-Berechtigungen auf die logische Einheit eines Teams in einem Kubernetes-Cluster zu beschränken. Die ordnungsgemäße Verwendung von Namespaces kann die Sicherheit verbessern, indem sie die Auswirkungen einer Kompromittierung von Zugangsdaten verringert.

Workload-Einstellungen für mehr Anwendungssicherheit

Abgesehen von Kubernetes selbst lassen sich Container-Workloads über die Standardeinstellungen hinaus schützen. So lässt sich der Netzwerkzugang über Network Policies sperren. Diese Regelsätze, die Firewalls ähneln, erlauben es, Beschränkungen sowohl für den externen Verkehr zu Pods als auch für den Traffic zwischen Pods im selben Cluster zu definieren. Neben der Verhinderung von Angriffen von außen kann der richtige Einsatz von Network Policies die Auswirkungen, die ein kompromittierter Pod auf die Umgebung haben kann, erheblich reduzieren.

Darüber hinaus bietet Kubernetes eine beträchtliche Anzahl optionaler Einstellungen für Workloads, um die Anwendungssicherheit zu erhöhen. So lässt sich etwa für das Dateisystem des Containers auf schreibgeschützt setzen, um Schreibvorgänge zu verhindern. Ebenso ist die Sandbox des Containers über die standardmäßige Prozessisolierung hinaus optimierbar.

Die Einhaltung spezifischer Regeln für Workload-Einstellungen lässt sich ebenfalls durchsetzen, um die einheitliche Verwendung von Standards innerhalb eines Unternehmens zu gewährleisten. So ließe sich beispielsweise eine Regel umsetzen, dass alle Container als ein bestimmter Nicht-Root-Benutzer ausgeführt werden müssen.

Mit Plattformansatz höhere Container-Sicherheit erzielen

Eine robuste Plattform für die Bereitstellung und Verwaltung von Kubernetes-Clustern bietet neben einer intuitiven Benutzeroberfläche und leistungsstarken Automatisierungsfunktionen auch effektive Sicherheitsfunktionen. Dies ist der richtige Ansatz für Unternehmen, um ihre Kubernetes-Workloads zu optimieren und zugleich die Container-Sicherheit zu gewährleisten.

Über den Autor: Sebastian Scheele ist CEO und Mitgründer von Kubermatic.

(ID:49666481)