Einführung
Orchestrierungstools wie Kubernetes führten zu einem beispiellosen Maß an Ausfallsicherheit und Vielseitigkeit bei der Softwarebereitstellung und -verwaltung. Sie haben auch die Unzulänglichkeiten der aktuellen Sicherheitslandschaft ins Rampenlicht gerückt.
Die verteilte Architektur von Kubernetes bietet uns mehrere zusätzliche Ebenen. Wir können sie verwenden, um vorhandene Sicherheitseinstellungen zu verbessern und darauf aufzubauen. Wenn Sie diese Schichten richtig konfigurieren, können sie jede Sicherheitsbedrohung isolieren, bevor sie von ihrem Ursprungsort ausbricht.
Dieser Artikel konzentriert sich auf die Maßnahmen, die Sie ergreifen können, um die Gesamtsicherheit Ihres Kubernetes-Clusters zu verbessern.
1. Rollenbasierte Zugriffskontrolle (RBAC) aktivieren
Die Komplexität eines Systems, das auf mehreren Geräten läuft, mit vielen miteinander verbundenen Microservices, die von Hunderten von Einzelpersonen und Dienstprogrammen verwaltet werden, ist ein logistischer Albtraum.
Üben Sie strenge Kontrolle über die Berechtigungen aus, die Benutzern gewährt werden. Kubernetes ist ein Befürworter der rollenbasierten Zugriffssteuerung (RBAC) Methode. Die rollenbasierte Zugriffssteuerungsmethode bedeutet, dass kein Benutzer mehr Berechtigungen hat, als er benötigt um ihre Aufgaben effektiv zu erfüllen. Bei Kubernetes dreht sich alles um Automatisierung, und RBAC verwendet eine API-Gruppe, um Autorisierungsentscheidungen über die Kubernetes-API zu steuern.
Ab Kubernetes Version 1.8 ist der RBAC-Modus stabil und wird von der rbac.authorization.k8s.io/v1-API unterstützt. Aktivieren Sie RBAC, indem Sie den API-Server mit dem folgenden Befehl starten:
--authorization-mode=RBACKubernetes verfügt über eine Reihe vordefinierter Rollen sowohl für menschliche Benutzer als auch für Komponenten wie Apps, Controller und Knoten. Diese vordefinierten Rollen sind zahlreich und bieten ein angemessenes Standardniveau an separaten Rollen für die häufigsten Aufgaben.
2. Halten Sie Ihre Geheimnisse geheim
In Kubernetes ist ein Secret ein kleines Objekt, das vertrauliche Daten wie ein Passwort oder einen Token enthält.
Auch wenn ein Pod nicht auf die Geheimnisse eines anderen Pods zugreifen kann, ist es wichtig, das Geheimnis von einem Bild oder Pod getrennt zu halten. Andernfalls hätte jeder, der Zugriff auf das Bild hat, auch Zugriff auf das Geheimnis. Komplexe Anwendungen, die mehrere Prozesse verarbeiten und öffentlich zugänglich sind, sind in dieser Hinsicht besonders anfällig.
Prozesse verschiedenen Containern zuweisen
Jeder Container in einem Pod muss das geheime Volume in seinem Volume anfordern. Reduzieren Sie das Risiko, dass Geheimnisse preisgegeben werden, indem Sie Prozesse in separate Container aufteilen. Verwenden Sie einen Front-End-Container, der mit Benutzern interagiert, aber den privaten Schlüssel nicht sehen kann.
Ergänzen Sie diesen Container mit einem Unterzeichner-Container, der den privaten Schlüssel sehen und auf einfache Signaturanforderungen vom Front-End reagieren kann. Dieser partitionierte Ansatz zwingt einen Angreifer dazu, eine Reihe komplexer Aktionen auszuführen, um zu versuchen, Ihre Sicherheitsmaßnahmen zu durchbrechen.
3. Beschränken Sie den Pod-zu-Pod-Datenverkehr mit einer Kubernetes-Netzwerkrichtlinie
Es handelt sich um eine Best Practice für Kubernetes-Sicherheit um das TLS-Sicherheitsprotokoll auf jeder Ebene der Anwendungsbereitstellungspipeline durchzusetzen. Es ist jedoch auch zwingend erforderlich, die einzelnen Elemente, aus denen der Cluster besteht, und die Elemente, die den Zugriff auf den Cluster steuern, zu sichern.
Pods akzeptieren standardmäßig Datenverkehr von jeder Quelle. Wenn Sie Netzwerkrichtlinien definieren legen Sie spezifische Regeln fest, wie Pods innerhalb eines Clusters und mit externen Ressourcen kommunizieren.
Netzwerkrichtlinien widersprechen sich nicht, sondern sind stattdessen additiv. Das Definieren einer Netzwerkrichtlinie in einem Namespace bedeutet, dass der Pod jede Verbindung ablehnt, die von dieser Richtlinie nicht zugelassen wird, wodurch der Pod effektiv isoliert wird. Der Pod ist auf das beschränkt, was durch die Kombination mehrerer Netzwerkrichtlinien genehmigt wird.
4. Pod-Sicherheit verbessern
Sichern des Kernels mit AppArmor oder SELinux
Container teilen sich den gleichen Kernel, was die Verwendung zusätzlicher Tools zur Verbesserung der Containerisolation erforderlich macht. Sicherheitsmodule wie AppArmor und Systeme, die Zugriffskontrollrichtlinien erzwingen, wie SELinux , beschränken Benutzerprogramme und Systemdienste. Sie werden auch verwendet, um den Zugriff auf Dateien zu verweigern und Netzwerkressourcen einzuschränken.
AppArmor begrenzt den Satz von Ressourcen, die einem Container innerhalb des Systems zur Verfügung stehen. Jedes Profil kann entweder erzwingend ausgeführt werden Modus, der den Zugriff auf unzulässige Ressourcen blockiert, oder beschweren Modus, der nur Verstöße meldet. Ein rechtzeitiger Bericht über potenzielle Probleme verbessert die Protokollierungs- und Prüfungsfunktionen Ihrer Systeme erheblich.
SELinux verwaltet die Ressourcenzuweisung unabhängig vom allgemeinen Linux ACM (Access Control Mechanism). Es erkennt keinen Superuser (root) an und ist nicht abhängig von setuid/setgid-Binärdateien.
Die Sicherung eines Systems ohne SELinux hängt von der richtigen Konfiguration privilegierter Anwendungen und des Kernels selbst ab. Eine Fehlkonfiguration in diesen Bereichen kann das gesamte System gefährden. Die Sicherheit eines Systems, das auf einem SELinux-Kernel basiert, hängt von der Korrektheit des Kernels und seiner Sicherheitsrichtlinienkonfiguration ab.
Angriffe stellen nach wie vor eine erhebliche Bedrohung dar. Bei SELinux müssen jedoch nicht unbedingt einzelne Benutzerprogramme und Systemdämonen die Sicherheit des gesamten Systems gefährden.
Befleckungen und Toleranzen
Kubernetes bietet die Option, vordefinierte Regeln zu erstellen, wenn das System Knoten neue Pods zuweist.
Als Orchestrierungstool neigt Kubernetes dazu, Pods am effizientesten Ort im Cluster zu starten, d. h. am Ort mit der geringsten Arbeitslast. Es ist möglich, die Platzierung von Pods zu optimieren, indem Sie Markierungen und Toleranzen definieren.
Taints ermöglichen Knoten, einen Pod oder eine Reihe von Pods basierend auf den vordefinierten Regeln abzulehnen. Andererseits werden Toleranzen auf Pod-Ebene angewendet und ermöglichen es Pods, Nodes mit passenden Taints zu planen (die Schlüssel und Effekte sind gleich).
Markierungen und Toleranzen sollten zusammen verwendet werden, um sicherzustellen, dass Pods nicht auf ungeeigneten Knoten geplant werden.
Namespaces
Kubernetes verfügt über keinen Mechanismus, der Sicherheit über Namespaces hinweg bietet. Beschränken Sie die Verwendung von Namespaces als Sicherheitsfunktion innerhalb vertrauenswürdiger Domänen und für interne Zwecke. Verwenden Sie keine Namespaces, wenn Sie einem Benutzer des Kubernetes-Clusters den Zugriff auf die Ressourcen anderer Namespaces verweigern möchten.
Die watch und list Anfragen ermöglichen es Clients, die Werte aller Geheimnisse zu überprüfen, die sich in diesem Namespace befinden. Nur die privilegiertesten Komponenten auf Systemebene sollten die Berechtigung haben, diese Anforderungen zu implementieren.
5. Laufende Kubernetes-Updates
Es ist unmöglich geworden, alle potenziellen Angriffsvektoren zu verfolgen. Diese Tatsache ist bedauerlich, da es nichts Wichtigeres gibt, als sich über potenzielle Bedrohungen im Klaren zu sein. Die beste Verteidigung besteht darin, sicherzustellen, dass Sie die neueste verfügbare Version von Kubernetes ausführen.
Es gibt mehrere Techniken wie rollierende Updates und Knotenpoolmigrationen, mit denen Sie ein Update mit minimaler Unterbrechung und Ausfallzeit durchführen können.
6. Prüfrichtlinien definieren
Die Audit-Protokollierung zeichnet die Zeitleiste von Ereignissen auf, die in einem Kubernetes-Cluster auftreten. Indem sie die von Benutzern und der Kubernetes-API durchgeführten Aktionen verfolgen, können Administratoren die Kette von Ereignissen analysieren, die zu einem potenziellen Problem geführt haben.
Mit Kubernetes können Sie Audit-Richtlinien optimieren, indem Sie definieren, wie oft Ereignisse protokolliert werden, ob Warnungen ausgegeben werden sollen und wie die betroffenen Pods beendet werden sollen.
Verwenden Sie die Audit-Protokollierung regelmäßig, um sicherzustellen, dass Ihr System auf dem neuesten Stand ist und Bedrohungen unter Kontrolle gehalten werden. Eine Container-basierte Bereitstellung fügt dem Audit-Prozess eine weitere Dimension hinzu. Ein Vergleich zwischen dem Original-Image und dem im Container laufenden Image kann effektiv verwendet werden, um festzustellen, ob Abweichungen zu Sicherheitsbedenken führen können. Stellen Sie sicher, dass Ihre Softwareversionen immer die neuesten Sicherheitspatches enthalten.