Das Sichern des Kubernetes-Clusters ist eine Sache, aber die Aufrechterhaltung der Sicherheit ist immer noch eine Herausforderung. Kubernetes wurde jedoch um neue Tools erweitert: Jetzt ist es viel einfacher, beides zu tun.
Kubernetes (seit Version 1.6) führte das Konzept der rollenbasierten Zugriffssteuerung (RBAC) ein, mit der Administratoren Einschränkungsrichtlinien für Clusterbenutzer definieren können. Das heißt, Sie erstellen einen Benutzer mit eingeschränktem Zugriff: Beschränken Sie den Benutzerzugriff auf Ressourcen wie Geheimnisse oder bestimmte Namespaces.
In diesem Beitrag werden wir nicht verstehen, wie RBAC implementiert wird. Es gibt genügend anständige Quellen, in denen dieses Thema von und nach diskutiert wird:
Es ist besser, sich darauf zu konzentrieren, wie Sie sicherstellen können, dass die Anforderungen Ihres Unternehmens erfüllt werden, und zu prüfen, ob ausgeführte RBAC-Objekte überprüft werden müssen, um festzustellen, ob sie ihre Funktionen ausführen.
Unser Drehbuch
Einige Organisationen akzeptieren mehrere Gruppen, um mit dem neuen Kubernetes-Cluster zu arbeiten. Es gibt eine Anforderung: Sie können sich nicht in die Bereitstellung einer benachbarten Gruppe einmischen, damit keine unvorhergesehenen Probleme oder Ausfallzeiten zwischen Gruppen auftreten.
Daher hat der Eigentümer des Clusters RBAC im Cluster bereitgestellt und dadurch den Zugriff auf einen bestimmten Namespace eingeschränkt. Die erste Überprüfung ergab: Gruppen können die Pods der anderen nicht im Namespace anzeigen.
Eine Woche ist vergangen. Der Eigentümer des Clusters hat festgestellt, dass ein Benutzer aus einem isolierten Namespace Geheimnisse aus einem anderen Namespace liest. Wie so? Er hat RBAC benutzt!
Ich habe es angewendet, aber wie bei der Arbeit mit Code muss das System auf Übereinstimmung mit dem gewünschten Ergebnis getestet werden. Es ist gut, dass das kubectl CLI Kubernetes- kubectl eine Reihe von Tools zum Überprüfen der RBAC-Konfiguration bereitstellt. kubectl auth can-i
Kann ich ("Kann ich?")
can-i prüft mit der API nur, ob eine bestimmte Aktion ausgeführt werden kann. Er verwendet die folgenden Parameter: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] . Jetzt kann der aktuelle Benutzer prüfen, ob ihm eine bestimmte Aktion zur Verfügung steht. Lass uns gehen:
kubectl auth can-i create pods
Dies sollte eine "Ja" - oder "Nein" -Antwort mit dem entsprechenden Exit-Code zurückgeben.
Beim Versuch, die Rechte eines anderen Benutzers zu überprüfen, tritt jedoch ein Problem auf: Der Benutzer, unter dem wir im Cluster autorisiert sind, wird in der ./kube/config angegeben, und es ist unpraktisch, separate Konfigurationen zum Testen einzelner Benutzer zu haben. Glücklicherweise kommt Kubernetes wieder zur Rettung: Es kann Benutzer mit den --as= und --as-group= simulieren.
Aktualisieren Sie den Befehl und verwenden Sie die Simulation eines anderen Benutzers:
kubectl auth can-i create pods --as=me
Wir sollten sehen, dass mit dem Exit-Code 1 die Antwort "no" zurückgegeben wird.
Und das ist großartig, denn wir haben jetzt eine Reihe von Befehlen, mit denen wir überprüfen können, ob ein Benutzer oder eine Gruppe von Benutzern Zugriff auf eine der Kubernetes-Ressourcen hat - vom Anzeigen von Pods bis zum Löschen von Geheimnissen.
Automatisierung
Es ist jedoch noch zu früh, um damit aufzuhören: Jetzt können wir eine Testsequenz implementieren, die die Liste der Anforderungen beschreibt und als Teil der CD-Pipeline ausführt. Zur Sache!
Es gibt eine große Auswahl, es gibt genügend Sprachen, die implementiert werden können: beginnend mit Ava und Mocha in JavaScript und endend mit Rspec. In diesem Fall implementiere ich das reine Bash-Test-Framework Bats .
Unten finden Sie ein Beispiel für die Durchführung eines Tests. Es überprüft die Funktionsweise von RBAC-Regeln, mit denen ein Benutzer aus einer Gruppe die Anzahl der laufenden Herde im Namespace ändern kann. Es wird ausgeführt, wenn das Attribut "ausführbar" festgelegt wurde. Oder - mit bats filename .
#!/usr/bin/env bats @test "Team namespaces can scale deployments within their own namespace" { run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns [ "$status" -eq 0 ] [ "$output" == "yes" ] done }
Die --as-group --as und --as-group erfordern die Verwendung der folgenden RBAC-Regeln:
rules: - apiGroups: - authorization.k8s.io resources: - selfsubjectaccessreviews - selfsubjectrulesreviews verbs: - create
Hier ist eine einfache Methode, mit der Sie Überprüfungen Ihrer RBAC-Regeln in Kubernetes implementieren können. Indem wir es in die Kubernetes-Pipeline aufnehmen, werden wir die RBAC-Politik erheblich stärken. Die Methode wurde in der Praxis getestet: Änderungen zu erfassen, die gegen Zugriffsrichtlinien verstoßen, ist viel schneller!
Vielen Dank, dass Sie sich die Zeit genommen haben, diesen Beitrag zu lesen!