gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-29 06:03:26 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/kubernetes-security/kubernetes-pivotin

Browse Source
This commit is contained in:
Translator
2025-01-02 21:34:34 +00:00
parent ff7e659f3f
commit f3b043d43f
7 changed files with 181 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md
View File

@@ -4,7 +4,7 @@
## GCP
Wenn Sie einen k8s-Cluster innerhalb von GCP betreiben, möchten Sie wahrscheinlich, dass eine Anwendung, die im Cluster läuft, Zugriff auf GCP hat. Es gibt 2 gängige Möglichkeiten, dies zu tun:
Wenn Sie einen k8s-Cluster innerhalb von GCP betreiben, möchten Sie wahrscheinlich, dass eine Anwendung, die innerhalb des Clusters läuft, Zugriff auf GCP hat. Es gibt 2 gängige Möglichkeiten, dies zu tun:
### GCP-SA-Schlüssel als Geheimnis einbinden
@@ -14,7 +14,7 @@ Eine gängige Methode, um **Zugriff auf eine Kubernetes-Anwendung zu GCP** zu ge
- Binden Sie die gewünschten Berechtigungen daran
- Laden Sie einen JSON-Schlüssel des erstellten SA herunter
- Binden Sie es als Geheimnis innerhalb des Pods ein
- Setzen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS, die auf den Pfad zeigt, wo die JSON-Datei gespeichert ist.
- Setzen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS, die auf den Pfad verweist, an dem sich die JSON-Datei befindet.
> [!WARNING]
> Daher sollten Sie als **Angreifer**, wenn Sie einen Container innerhalb eines Pods kompromittieren, nach dieser **env** **Variable** und **json** **Dateien** mit GCP-Anmeldeinformationen suchen.
@@ -46,9 +46,9 @@ iam.gke.io/gcp-service-account=<gcp-service-account-email>
Mit Workload Identity können wir ein[ Kubernetes-Dienstkonto](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) so konfigurieren, dass es als[ Google-Dienstkonto](https://cloud.google.com/iam/docs/understanding-service-accounts) fungiert. Pods, die mit dem Kubernetes-Dienstkonto ausgeführt werden, authentifizieren sich automatisch als das Google-Dienstkonto, wenn sie auf Google Cloud APIs zugreifen.
Die **erste Reihe von Schritten**, um dieses Verhalten zu aktivieren, besteht darin, **Workload Identity in GCP zu aktivieren** ([**Schritte**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) und das GCP-SA zu erstellen, das k8s nachahmen soll.
Die **erste Reihe von Schritten**, um dieses Verhalten zu aktivieren, besteht darin, **Workload Identity in GCP zu aktivieren** ([**Schritte**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) und das GCP SA zu erstellen, das k8s nachahmen soll.
- **Aktivieren Sie Workload Identity** in einem neuen Cluster
- **Aktivieren Sie Workload Identity** auf einem neuen Cluster
```bash
gcloud container clusters update <cluster_name> \
--region=us-central1 \
@@ -59,7 +59,7 @@ gcloud container clusters update <cluster_name> \
# You could update instead of create
gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
```
- Erstellen Sie das **GCP-Dienstkonto zur Impersonation** von K8s mit GCP-Berechtigungen:
- Erstellen Sie das **GCP-Dienstkonto zur Nachahmung** von K8s mit GCP-Berechtigungen:
```bash
# Create SA called "gsa2ksa"
gcloud iam service-accounts create gsa2ksa --project=<project-id>
@@ -92,7 +92,7 @@ kubectl annotate serviceaccount ksa2gcp \
--namespace testing \
iam.gke.io/gcp-service-account=gsa2ksa@security-devbox.iam.gserviceaccount.com
```
- Führen Sie ein **pod** mit der **KSA** aus und überprüfen Sie den **Zugriff** auf die **GSA:**
- Führen Sie ein **pod** mit dem **KSA** aus und überprüfen Sie den **Zugriff** auf **GSA:**
```bash
# If using Autopilot remove the nodeSelector stuff!
echo "apiVersion: v1
@@ -124,7 +124,7 @@ gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-
```
> [!WARNING]
> Als Angreifer innerhalb von K8s sollten Sie **nach SAs suchen**, die die **`iam.gke.io/gcp-service-account` Annotation** haben, da dies darauf hinweist, dass der SA auf etwas in GCP zugreifen kann. Eine weitere Möglichkeit wäre, zu versuchen, jede KSA im Cluster auszunutzen und zu überprüfen, ob sie Zugriff hat.\
> Von GCP aus ist es immer interessant, die Bindungen aufzulisten und zu wissen, **welchen Zugriff Sie SAs innerhalb von Kubernetes gewähren**.
> Von GCP aus ist es immer interessant, die Bindungen zu enumerieren und zu wissen, **welchen Zugriff Sie SAs innerhalb von Kubernetes gewähren**.
Dies ist ein Skript, um einfach **über alle Pod**-Definitionen **zu iterieren** und nach dieser **Annotation** zu suchen:
```bash
@@ -221,12 +221,12 @@ Um **aws mit dem Token** von `/var/run/secrets/eks.amazonaws.com/serviceaccount/
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/EKSOIDCTesting --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
```
> [!WARNING]
> Als Angreifer, wenn Sie einen K8s-Cluster auflisten können, überprüfen Sie **Servicekonten mit dieser Annotation**, um sich **zu AWS zu eskalieren**. Dazu erstellen Sie einfach einen **Pod** mit einem der IAM **privilegierten Servicekonten** und stehlen das Token.
> Als Angreifer, wenn Sie einen K8s-Cluster auflisten können, überprüfen Sie **Servicekonten mit dieser Annotation**, um sich **zu AWS zu eskalieren**. Dazu müssen Sie einfach **exec/create** einen **Pod** mit einem der IAM **privilegierten Servicekonten** erstellen und das Token stehlen.
>
> Darüber hinaus, wenn Sie sich in einem Pod befinden, überprüfen Sie Umgebungsvariablen wie **AWS_ROLE_ARN** und **AWS_WEB_IDENTITY_TOKEN.**
> [!CAUTION]
> Manchmal könnte die **Trust Policy einer Rolle** **schlecht konfiguriert** sein und anstatt den AssumeRole-Zugriff auf das erwartete Servicekonto zu gewähren, gewährt sie ihn **allen Servicekonten**. Daher, wenn Sie in der Lage sind, eine Annotation auf einem kontrollierten Servicekonto zu schreiben, können Sie auf die Rolle zugreifen.
> Manchmal könnte die **Trust Policy einer Rolle** **schlecht konfiguriert** sein und anstatt AssumeRole-Zugriff auf das erwartete Servicekonto zu gewähren, gewährt sie ihn **allen Servicekonten**. Daher, wenn Sie in der Lage sind, eine Annotation auf einem kontrollierten Servicekonto zu schreiben, können Sie auf die Rolle zugreifen.
>
> Überprüfen Sie die **folgende Seite für weitere Informationen**:
@@ -236,7 +236,7 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### Finden Sie Pods und SAs mit IAM-Rollen im Cluster
Dies ist ein Skript, um einfach **über alle Pods und SAs** Definitionen **zu iterieren**, die nach dieser **Annotation** suchen:
Dies ist ein Skript, um einfach **über alle Pods und SAs**-Definitionen **zu iterieren** und nach dieser **Annotation** zu suchen:
```bash
for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
@@ -255,7 +255,7 @@ done | grep -B 1 "amazonaws.com"
```
### Node IAM Rolle
Der vorherige Abschnitt handelte davon, wie man IAM-Rollen mit Pods stiehlt, aber beachten Sie, dass ein **Node des** K8s-Clusters eine **Instanz in der Cloud** sein wird. Das bedeutet, dass der Node höchstwahrscheinlich **eine neue IAM-Rolle haben wird, die Sie stehlen können** (_beachten Sie, dass normalerweise alle Nodes eines K8s-Clusters die gleiche IAM-Rolle haben, sodass es möglicherweise nicht wert ist, zu versuchen, jeden Node zu überprüfen_).
Der vorherige Abschnitt handelte davon, wie man IAM-Rollen mit Pods stiehlt, aber beachten Sie, dass ein **Node des** K8s-Clusters eine **Instanz in der Cloud** sein wird. Das bedeutet, dass der Node höchstwahrscheinlich **eine neue IAM-Rolle haben wird, die Sie stehlen können** (_beachten Sie, dass normalerweise alle Nodes eines K8s-Clusters die gleiche IAM-Rolle haben, sodass es möglicherweise nicht sinnvoll ist, jeden Node zu überprüfen_).
Es gibt jedoch eine wichtige Voraussetzung, um auf den Metadaten-Endpunkt vom Node zuzugreifen: Sie müssen sich im Node befinden (SSH-Sitzung?) oder zumindest dasselbe Netzwerk haben:
```bash
@@ -265,7 +265,7 @@ kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"s
Zuvor haben wir besprochen, wie man **IAM-Rollen an Pods anheftet** oder sogar wie man **zum Knoten entkommt, um die IAM-Rolle zu stehlen**, die der Instanz zugeordnet ist.
Sie können das folgende Skript verwenden, um Ihre neu erarbeiteten **IAM-Rollenanmeldeinformationen** zu **stehlen**:
Sie können das folgende Skript verwenden, um Ihre neu erarbeiteten **IAM-Rollen-Anmeldeinformationen** zu **stehlen**:
```bash
IAM_ROLE_NAME=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null || wget http://169.254.169.254/latest/meta-data/iam/security-credentials/ -O - 2>/dev/null)
if [ "$IAM_ROLE_NAME" ]; then