Rechteausweitung in Kubernetes / Sudo Null IT News

Wenn jemand von Sicherheit spricht, meint er in erster Linie Autorisierung und Authentifizierung, aber im Kontext von Kubernetes sind diese beiden Teile nur kleine Teile eines größeren Puzzles.

In diesem Artikel erfahren Sie, wie ein eingeschränkter Benutzer seine Berechtigungen erhöhen und Clusteradministrator werden kann.

Eingabedaten

Wir haben also einen Benutzer Lanzette, mit eingeschränkten Rechten: Er kann Bereitstellungen bearbeiten und erstellen und Informationen über Pods abrufen – innerhalb seines Namespace. Es scheint, dass seine Rechte innerhalb eines Namensraums beschränkt sind, und Sie könnten denken, dass hier aus Sicherheitsgründen alles in Ordnung ist, aber leider ist es das nicht!

Angriffsplan

Was wissen wir:

  • ca.key ist der private Schlüssel der CA. Mit dieser Datei, die normalerweise in einem bekannten Pfad auf den Master-Knoten gespeichert ist, können wir zusammen mit ca.cert jede CSR signieren. Das Problem ist, dass diese Datei nur Root-Benutzern zur Verfügung steht.

  • Unser Benutzer (Lanzette) können Bereitstellungen bearbeiten, jedoch nur innerhalb desselben Namespace. Es kann auch Informationen über Pods lesen, einschließlich ihrer Protokolle!

  • Bereitstellungen erzeugen Pods und Container drehen sich in Pods.

  • Verwendungszweck HostPfad ermöglicht es Ihnen, einen Teil des Host-Dateisystems innerhalb des Pods zu mounten.

Also der Plan selbst:

  1. Wir erstellen ein Deployment und versuchen, Kubernetes dazu zu bringen, Pods auf dem Master-Knoten auszuführen, wo sich die von uns benötigten Zertifikate befinden.

  2. Mounten des Verzeichnisses /etc/kubernetes/pki über hostPath im Pod.

  3. Innerhalb des erstellten Pods liegen die von uns benötigten Zertifikate. Wir können uns die Protokolle ansehen – das reicht aus, um sie zu stehlen.

  4. Erstellen Sie eine CSR für einen neuen Benutzer − Drachen, Mitglied der Gruppe system:masters, und signieren Sie es mit dem gestohlenen ca.key und ca.cert.

Pod dem Master-Knoten zuweisen

Wie Sie wahrscheinlich wissen, wählt kube-scheduler jedes Mal, wenn Sie versuchen, einen Pod zu erstellen, den besten Node aus, um diesen Pod auszuführen. Sie können dies überprüfen, indem Sie den Befehl “describe” für einen bestimmten Pod aufrufen:

kubectl beschreiben pod Die Ereignisse zeigen, dass der Pod auf node01 gestartet wirdDie Ereignisse zeigen, dass der Pod auf node01 gestartet wird

Die Aufgabe von kube-scheduler besteht darin, den am besten geeigneten Node zum Ausführen eines bestimmten Pods zu finden. Daher können Sie in der Regel nicht vorhersagen, auf welchem ​​Knoten der Pod ausgeführt wird. Es gibt jedoch mehrere Möglichkeiten, den Pod auf dem von uns benötigten Node zum Laufen zu bringen – am einfachsten ist die Verwendung des nodeSelector.

nodeSelector

Vom Beamten Dokumentation:

nodeSelector ist die einfachste empfohlene Form der Knotenauswahlbeschränkung. Sie können das Feld nodeSelector zu Ihrer Pod-Spezifikation hinzufügen und die angeben Knotenetiketten den Zielknoten haben soll. Kubernetes plant den Pod nur auf Knoten, die jedes der von Ihnen angegebenen Labels haben.

Mit anderen Worten, Sie können den nodeSelector verwenden, um einen Pod so zu planen, dass er auf einem Knoten mit einem bestimmten Label ausgeführt wird. Es wäre schön, wenn es ein Standardlabel gäbe, mit dem wir den Pod auf dem gewünschten Knoten ausführen könnten.

Lassen Sie uns prüfen, ob es ein solches Label gibt:

kubectl get node -o jsonpath='{.metadata.labels}’ | jqStandardbezeichnung für Master-KnotenStandardbezeichnung für Master-Knoten

Das Label „node-role.kubernetes.io/master“ ist das, was wir brauchen!

Ein Beispiel für ein Manifest, in dem wir ein Deployment mit einem Replikat erstellen, in dem sich ein Container mit nginx dreht, und dieser generierte Pod auf dem Master-Knoten ausgeführt werden soll:

Katze <Mal sehen, was passiert, wenn wir dieses Manifest anwenden:

kubectl get pod -widePod wurde Knoten nicht zugewiesenPod wurde Knoten nicht zugewiesen

Irgendetwas scheint schief gelaufen zu sein – der Pod befindet sich im Status „Ausstehend“. Wenn wir versuchen, den Befehl “describe” über unser Dienstkonto aufzurufen Lanzenlot, dann werden wir keine Ereignisse sehen (dieser Benutzer hat keine Berechtigung dazu).

Allerdings der Benutzer Lanzette hat die Berechtigung, Pods zu lesen. Das bedeutet, dass wir den Status des Pods herausfinden können:

kubectl get po nginx-… -o jsonpath=”{.status.conditions}” | jq

Der Fehler sagt uns, dass wir auf dem richtigen Weg sind! nodeSelector veranlasste den Scheduler, zwei Worker-Knoten zu überspringen, aber der Pod startete aufgrund von Taint nicht auf dem Master-Knoten.

Makel & Toleranzen

Sie können auf verschiedene Weise erklären, was es ist, aber lassen Sie mich versuchen, es so einfach wie möglich zu machen. Stellen Sie sich vor, dass Taints eine Art Zaun sind, der die VIP-Zone im Club abgrenzt, und Sie können diese Zone nur auf Einladung betreten. Und Duldungen sind nur eine Einladung, die VIP-Zone zu betreten.

Zurück zu Kubernetes: Der Taint & Tolerations-Mechanismus wird benötigt, um Pods nur auf dem richtigen Node auszuführen – zum Beispiel mit der richtigen Hardware. Oder umgekehrt – Taint kann verwendet werden, um zu verhindern, dass Pods auf einem bestimmten Knoten ausgeführt werden.

Das Format ist:

Schlüssel=Wert:Effekt

Schlüssel und Wert sind beliebige Zeichenfolgen, aber Wirkung kann verschiedene Werte annehmen:

  • Kein plan – Hülsen ohne Toleranz kann nicht auf Knoten mit ausgeführt werden verderben (unser Fall).

  • NeinAusführen – Pods laufen weiter verderben Knoten ohne Toleranzwird aus Node entfernt.

Es gibt zwei Arten von Toleranzen:

  1. Gleich – Toleranzen funktionieren nur, wenn Tonart, Wert und Effekte genau übereinstimmen

    Toleranzen:
    – Schlüssel: “Schlüssel1”
    Operator: “Gleich”
    Wert: “Wert1”
    Wirkung: “NoSchedule”

  2. Existieren – Toleranz funktioniert, wenn es eine Übereinstimmung mit Tonart und Effekten gibt

    Toleranzen:
    – Schlüssel: “Schlüssel1”
    Operator: “existiert”
    Wirkung: “NoSchedule”

Wenn Sie mehr über Taint & Tolerations erfahren möchten – Schauen Sie sich die offizielle Dokumentation an!

Unsere aktuelle Situation ist jedoch:

Wir konnten unseren Pod aufgrund von Taint nicht zum Laufen bringen. Aber jetzt wissen wir, wie wir das umgehen können. Bearbeiten wir unser Deployment, indem wir 4 Zeilen hinzufügen:

… spec: toleranzen: – key: “” operator: “Exists” effect: “NoSchedule” …

Jetzt läuft unser Pod auf dem Master Node:

Schlüssel- und Zertifikatsdiebstahl

Jetzt, da wir den Pod auf dem Master Node ausführen können, können wir den Angriff weiterentwickeln. Mounten Sie nämlich einen Teil des Node-Dateisystems (ein Ordner mit den erforderlichen Schlüsseln und Zertifikaten) innerhalb des Pods mit HostPfad. Weisen Sie dann unseren Container an, den Inhalt dieses Ordners in den Protokollen zu protokollieren. Das endgültige Deployment sieht so aus:

Katze <Wenn Sie sich die Pod-Protokolle ansehen, können Sie die Schlüssel und Zertifikate sehen, nach denen wir gesucht haben:

kubectl protokolliert busybox-…Jackpot: Wir haben den Schlüssel und das Zertifikat!Jackpot: Wir haben den Schlüssel und das Zertifikat!

Wir generieren Credits mit Admin-Rechten

Wir haben die Schlüssel und Zertifikate erhalten, die wir brauchten. Es ist an der Zeit, ein Zertifikat mit Administratorrechten für den Benutzer zu erstellen Drachen:

openssl genrsa -out dragon.key 2048 openssl req -new -key dragon.key -out dragon.csr -subj “/CN=dragon/O=system:masters” openssl x509 -req -in dragon.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out dragon.crt -days 365

Anschließend können wir das neue Zertifikat zu KUBECONFIG hinzufügen. Bitte beachten Sie, dass der Name meines Clusters camelot ist, Ihr Name wird anders sein.

kubectl config set-credentials dragon –client-certificate=dragon.crt –client-key=dragon.key –embed-certs kubectl config set-context dragon@camelot –user=dragon –cluster=camelot kubectl config use -Kontextdrache@camelot

Herzliche Glückwünsche! Sie sind Cluster-Administrator geworden:

kubectl auth can-i delete namespaces -A > yes

Similar Posts

Leave a Reply

Your email address will not be published.