© cwales/Shutterstock.com
RBAC in Kubernetes

Mehr Sicherheit für Container


Container haben sich nach dem ersten Hype etabliert und sind das Maß aller Dinge. Nach Schätzungen von Gartner werden 50 Prozent der Unternehmen bis 2020 Containertechnologie einsetzen. Laut einer Umfrage der Firma RightScale planen 83 Prozent der Enterprise-Business-Unternehmen den Einsatz von Containern oder nutzen diese bereits. Der Einsatz von Containervirtualisierung birgt aber auch neue Herausforderungen. Laut einer Studie der Cloud Native Computing Foundation (CNCF) haben 43 Prozent der befragten Unternehmen angegeben, dass das Thema Containersecurity eine der größten Hürden darstellt.

Die betrieblichen Vorteile von Containern, darunter optimierte Bauzeiten und eine effizientere Nutzung der Infrastrukturressourcen, haben zu einem wachsenden Interesse an der Containerorchestrierungsplattform Kubernetes geführt. Gleichzeitig haben Kubernetes-Implementierungen eine ganze Reihe neuer Sicherheitsbedenken hinsichtlich der Infrastruktur für Entwicklungs- und Betriebsteams ergeben. Dazu zählen auch das User- und Rechtemanagement sowie Rechteeinschränkungen der deployten Container-Services und Namespace Multitenancy. In den letzten Jahren entstanden hierzu diverse Securityanforderungen, um Kubernetes auf einer produktionsreifen Infrastruktur betreiben zu können. Zu den wichtigsten Securityanforderungen gehören:

  • Verschiedenen Benutzern mit unterschiedlichen Eigenschaften einen geeigneten Authentifizierungsmechanismus zur Verfügung zu stellen
  • Vollständige Kontrolle darüber, welche Operationen jeder Benutzer oder jede Benutzergruppe ausführen kann
  • Vollständige Kontrolle darüber, welche Operationen jeder Prozess in einem Pod ausführen kann
  • Ein Benutzer kann Ressourcen nur in seinem autorisierten Namespace sehen; auf diese Weise können Ressourcen innerhalb der Organisation (z. B. zwischen Abteilungen) isoliert werden
  • Beschränkung der Ressourcenerstellung (z. B. Pods, Persistent Volumes, Deployments) auf bestimmte Namespaces; es können auch Kontingente verwendet werden, um sicherzustellen, dass die Ressourcennutzung begrenzt ist und kontrolliert wird

Welche Vorteile ergeben sich durch diese Anforderungen?

Der beschränkte Zugriff ausgewählter Benutzer, die bestimmte Aktionen für eine Ressource ausführen müssen, ist für die Sicherung des Kubernetes-Clusters von entscheidender Bedeutung. Selbst wenn vertrauenswürdige Anwendungen installiert werden, können diese Anwendungen jederzeit anfällig für Angriffe sein. Durch Ausnutzen einer Schwachstelle durch Remote Code Execution kann ein Angreifer beispielsweise mit Hilfe der Anmeldeinformationen der deployten Anwendung auf den Cluster zugreifen. Selbst ohne Remote Code Execution sind Kubernetes Service Accounts anfällig für die Offenlegung lokaler Dateien, sodass Angreifer das JSON Web Token für den Service Account stehlen und Zugriff auf den API-Server erhalten können, auch wenn nur Lesezugriff konfiguriert wurde.

Um diesen Sicherheitsanforderungen gerecht zu werden, wurde mit Kubernetes 1.6 eine rollenbasierte Zugriffskontrolle (Role-based Access Control, kurz RBAC) als Beta eingeführt, als ein alternativer Authentifizierungsmechanismus zum bereits bestehenden, aber schwer versteh- und handhabbaren Attribute-based Access Control (ABAC). Denn Berechtigungsrichtlinien können mithilfe des Kommandozeilenwerkzeugs kubectl oder dem Kubernetes API eingerichtet und verwaltet werden. Um via ABAC Authorization Policy Changes durchzuführen, ist ein Zugriff via SSH auf den Root-Account der Cluster-Master-VMs nötig. Dies sollte aus Securitysicht vermieden werden. Mit Kubernetes 1.8 wurde RBAC als stabiles Release eingeführt und ist seitdem ein wichtiges Element im Security-Toolkit von Kubernetes.

Die Idee

Um die Idee von RBAC zu begreifen, müssen wir zunächst die drei involvierten Elemente verstehen. Zu diesen drei Elementen gehören:

  • Subjects: Diese entsprechen der Entität, die eine Operation im Cluster versucht. Es gibt drei Arten von Subjects:
    • User Accounts sind global und prädestiniert für Menschen und Prozesse, die außerhalb des Clusters leben.
    • Service Accounts sind „namespaced“ und gedacht für Intra-Clusterprozesse, die innerhalb von Pods laufen, die sich gegen da...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang