Kubernetes Pivoting to Clouds
GCP
Wenn Sie einen k8s-Cluster in GCP betreiben, möchten Sie wahrscheinlich, dass eine Anwendung, die im Cluster läuft, auf GCP zugreifen kann. Es gibt 2 gängige Möglichkeiten, dies zu tun:
Einbinden von GCP-SA-Schlüsseln als Geheimnis
Ein üblicher Weg, einer Kubernetes-Anwendung Zugriff auf GCP zu geben, ist:
Erstellen Sie ein GCP-Servicekonto
Binden Sie die gewünschten Berechtigungen daran
Laden Sie einen JSON-Schlüssel des erstellten SA herunter
Binden Sie ihn als Geheimnis im Pod ein
Legen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS fest, die auf den Pfad zeigt, an dem sich das JSON befindet.
Daher sollten Sie als Angreifer, wenn Sie einen Container in einem Pod kompromittieren, diese Umgebungsvariable und JSON-Dateien mit GCP-Anmeldeinformationen überprüfen.
Verknüpfung von GSA-JSON mit KSA-Geheimnis
Eine Möglichkeit, einem GSA Zugriff auf einen GKE-Cluster zu geben, besteht darin, sie folgendermaßen zu binden:
Erstellen Sie ein Kubernetes-Servicekonto im selben Namespace wie Ihr GKE-Cluster mit dem folgenden Befehl:
Erstellen Sie ein Kubernetes Secret, das die Anmeldeinformationen des GCP-Dienstkontos enthält, dem Sie Zugriff auf den GKE-Cluster gewähren möchten. Dies können Sie mit dem
gcloud
Befehlszeilentool tun, wie im folgenden Beispiel gezeigt:
Binden Sie das Kubernetes Secret an das Kubernetes-Service-Konto mit dem folgenden Befehl:
Im zweiten Schritt wurden die Anmeldedaten des GSA als Geheimnis des KSA festgelegt. Wenn Sie dann dieses Geheimnis innerhalb des GKE-Clusters lesen können, können Sie zu diesem GCP-Dienstkonto eskalieren.
GKE-Workload-Identität
Mit der Workload-Identität können wir ein Kubernetes-Servicekonto konfigurieren, um als Google-Dienstkonto zu fungieren. Pods, die mit dem Kubernetes-Servicekonto ausgeführt werden, authentifizieren sich automatisch als das Google-Dienstkonto beim Zugriff auf Google Cloud APIs.
Die erste Reihe von Schritten, um dieses Verhalten zu aktivieren, besteht darin, Workload-Identität in GCP zu aktivieren (Schritte) und das GCP SA zu erstellen, das Sie möchten, dass k8s es imitiert.
Aktivieren Sie die Workload-Identität auf einem neuen Cluster
Erstellen/Aktualisieren eines neuen Nodepools (Autopilot-Cluster benötigen dies nicht)
Erstellen Sie den GCP-Dienstaccount zum Impersonieren von K8s mit GCP-Berechtigungen:
Verbinde dich mit dem Cluster und erstelle das Service-Konto, das verwendet werden soll
Verbinden Sie die GSA mit der KSA
Führen Sie ein Pod mit dem KSA aus und überprüfen Sie den Zugriff auf GSA:
Überprüfen Sie den folgenden Befehl zur Authentifizierung, falls erforderlich:
Als Angreifer innerhalb von K8s sollten Sie nach SAs suchen, die die iam.gke.io/gcp-service-account
-Annotation aufweisen, da dies darauf hinweist, dass der SA auf etwas in GCP zugreifen kann. Eine andere Option wäre, jeden KSA im Cluster zu missbrauchen und zu überprüfen, ob er Zugriff hat.
Von GCP aus ist es immer interessant, die Bindungen aufzulisten und zu wissen, welchen Zugriff Sie den SAs innerhalb von Kubernetes geben.
Dies ist ein Skript, um einfach über alle Pod-Definitionen zu iterieren und nach dieser Annotation zu suchen:
AWS
Kiam & Kube2IAM (IAM-Rolle für Pods)
Ein (veralteter) Weg, IAM-Rollen an Pods zu vergeben, besteht darin, einen Kiam oder einen Kube2IAM Server zu verwenden. Grundsätzlich müssen Sie einen Daemonset in Ihrem Cluster mit einer Art privilegierter IAM-Rolle ausführen. Dieses Daemonset wird IAM-Rollen den Pods zugänglich machen, die sie benötigen.
Zunächst müssen Sie konfigurieren, auf welche Rollen innerhalb des Namespaces zugegriffen werden kann, und das geschieht mit einer Annotation im Namespace-Objekt:
Sobald der Namespace mit den IAM-Rollen konfiguriert ist, die die Pods haben können, können Sie die Rolle, die Sie für jede Pod-Definition möchten, angeben mit etwas Ähnlichem wie:
Als Angreifer, wenn Sie diese Anmerkungen in Pods oder Namespaces finden oder einen kiam/kube2iam-Server (wahrscheinlich in kube-system) laufen lassen, können Sie jede Rolle übernehmen, die bereits von Pods verwendet wird, und mehr (wenn Sie Zugriff auf das AWS-Konto haben, die Rollen auflisten).
Pod mit IAM-Rolle erstellen
Die IAM-Rolle, die angegeben werden muss, muss sich im selben AWS-Konto wie die kiam/kube2iam-Rolle befinden und diese Rolle muss darauf zugreifen können.
IAM-Rolle für K8s-Servicekonten über OIDC
Dies ist der empfohlene Weg von AWS.
Zunächst müssen Sie einen OIDC-Anbieter für den Cluster erstellen.
Erstellen Sie dann eine IAM-Rolle mit den Berechtigungen, die das SK benötigen wird.
Erstellen Sie eine Vertrauensbeziehung zwischen der IAM-Rolle und dem SK Namen (oder den Namespaces, die dem SK Zugriff auf die Rolle aller SKs des Namespaces gewähren). Die Vertrauensbeziehung überprüft hauptsächlich den OIDC-Anbieter-Namen, den Namespace-Namen und den SK-Namen.
Schließlich erstellen Sie ein SK mit einer Annotation, die die ARN der Rolle angibt, und die Pods, die mit diesem SK ausgeführt werden, haben Zugriff auf das Token der Rolle. Das Token wird in einer Datei geschrieben und der Pfad wird in
AWS_WEB_IDENTITY_TOKEN_FILE
angegeben (Standard:/var/run/secrets/eks.amazonaws.com/serviceaccount/token
).
Um aws mit dem Token von /var/run/secrets/eks.amazonaws.com/serviceaccount/token
zu erhalten, führen Sie aus:
Als Angreifer können Sie, wenn Sie einen K8s-Cluster aufzählen können, nach Service-Konten mit dieser Annotation suchen, um zu AWS zu eskalieren. Dazu müssen Sie einfach einen Pod ausführen/erstellen, der eines der IAM-privilegierten Service-Konten verwendet, und das Token stehlen.
Darüber hinaus sollten Sie, wenn Sie sich innerhalb eines Pods befinden, nach Umgebungsvariablen wie AWS_ROLE_ARN und AWS_WEB_IDENTITY_TOKEN suchen.
Manchmal ist die Vertrauensrichtlinie einer Rolle möglicherweise falsch konfiguriert und gibt anstelle des Erteilen des AssumeRole-Zugriffs auf das erwartete Service-Konto diesen Zugriff an alle Service-Konten. Wenn Sie also in der Lage sind, eine Annotation auf einem kontrollierten Service-Konto zu schreiben, können Sie auf die Rolle zugreifen.
Überprüfen Sie die folgende Seite für weitere Informationen:
Pods und SAs mit IAM-Rollen im Cluster finden
Dies ist ein Skript, um einfach über alle Pods und SA-Definitionen zu iterieren und nach dieser Annotation zu suchen:
Knoten IAM-Rolle
Der vorherige Abschnitt handelte davon, wie man IAM-Rollen mit Pods stiehlt, aber beachten Sie, dass ein Knoten des K8s-Clusters ein Instanz innerhalb der Cloud sein wird. Dies bedeutet, dass es höchstwahrscheinlich eine neue IAM-Rolle geben wird, die Sie stehlen können (beachten Sie, dass in der Regel alle Knoten eines K8s-Clusters dieselbe IAM-Rolle haben, daher lohnt es sich möglicherweise nicht, jeden Knoten zu überprüfen).
Es gibt jedoch eine wichtige Voraussetzung, um auf den Metadaten-Endpunkt vom Knoten aus zuzugreifen: Sie müssen auf dem Knoten sein (SSH-Sitzung?) oder zumindest das gleiche Netzwerk haben:
IAM-Rollen-Token stehlen
Zuvor haben wir besprochen, wie man IAM-Rollen an Pods anhängt oder sogar wie man zum Knoten entkommt, um die IAM-Rolle zu stehlen, die der Instanz angehängt ist.
Sie können das folgende Skript verwenden, um Ihre neu erarbeiteten IAM-Rollenanmeldeinformationen zu stehlen:
Referenzen
Last updated