Translated ['src/pentesting-cloud/kubernetes-security/kubernetes-pivotin

src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md

@@ -19,7 +19,7 @@
 > [!WARNING]
 > Тому, як **зловмисник**, якщо ви скомпрометували контейнер всередині пода, вам слід перевірити цю **змінну** **середовища** та **json** **файли** з обліковими даними GCP.
 
-### Прив'язка json GSA до секрету KSA
+### Прив'язка GSA json до KSA секрету
 
 Спосіб надати доступ до GSA для кластера GKE - це прив'язати їх таким чином:
 
@@ -27,7 +27,7 @@
 ```bash
 Copy codekubectl 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 \
 --iam-account <gcp-service-account-email>
@@ -123,7 +123,7 @@ 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 в кластері та перевірити, чи має він доступ.\
+> Як атакуючий всередині K8s, ви повинні **шукати SAs** з **анотацією `iam.gke.io/gcp-service-account`**, оскільки це вказує на те, що SA може отримати доступ до чогось у GCP. Іншим варіантом було б спробувати зловживати кожним KSA в кластері та перевірити, чи має він доступ.\
 > З GCP завжди цікаво перерахувати зв'язки та дізнатися, **який доступ ви надаєте SAs всередині Kubernetes**.
 
 Це скрипт для легкого **ітерації по всіх визначеннях подів**, **шукаючи** цю **анотацію**:
@@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: |
 ["role-arn"]
 name: default
 ```
-Якщо простір імен налаштований з IAM ролями, які можуть мати Pods, ви можете **вказати роль, яку ви хочете в кожному визначенні pod за допомогою чогось на зразок**:
+Якщо простір імен налаштований з IAM ролями, які можуть мати Pods, ви можете **вказати роль, яку ви хочете в кожному визначенні pod, за допомогою чогось на зразок**:
 ```yaml:Kiam & Kube2iam
 kind: Pod
 metadata:
@@ -171,7 +171,7 @@ annotations:
 iam.amazonaws.com/role: reportingdb-reader
 ```
 > [!WARNING]
-> Як атакуючий, якщо ви **знайдете ці анотації** в подах або просторах імен, або сервер kiam/kube2iam, що працює (ймовірно, в kube-system), ви можете **вдаватись** в кожну роль, яка вже **використовується подами**, і більше (якщо у вас є доступ до облікового запису AWS, перерахувати ролі).
+> Як атакуючий, якщо ви **знайдете ці анотації** в подах або просторах імен, або сервер kiam/kube2iam, що працює (ймовірно, в kube-system), ви можете **вдаватись в будь-яку р**оль, яка вже **використовується подами**, і більше (якщо у вас є доступ до облікового запису AWS, перерахувати ролі).
 
 #### Створити Pod з IAM роллю
 
@@ -196,10 +196,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).
+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`)
+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`)
 ```bash
 # Create a service account with a role
 cat >my-service-account.yaml <<EOF
@@ -255,7 +255,7 @@ done | grep -B 1 "amazonaws.com"
 ```
 ### Node IAM Role
 
-Попередній розділ стосувався того, як вкрасти IAM ролі за допомогою подів, але зверніть увагу, що **вузол** K8s кластера буде **екземпляром всередині хмари**. Це означає, що вузол, ймовірно, буде **мати нову IAM роль, яку ви можете вкрасти** (_зверніть увагу, що зазвичай всі вузли K8s кластера мають однакову IAM роль, тому може не мати сенсу перевіряти кожен вузол_).
+Попередній розділ стосувався того, як вкрасти IAM ролі за допомогою подів, але зверніть увагу, що **вузол** K8s кластера буде **екземпляром всередині хмари**. Це означає, що вузол, ймовірно, **матиме нову IAM роль, яку ви можете вкрасти** (_зверніть увагу, що зазвичай всі вузли K8s кластера мають однакову IAM роль, тому може не мати сенсу перевіряти кожен вузол_).
 
 Однак є важлива вимога для доступу до метаданих з вузла, вам потрібно бути на вузлі (ssh сесія?) або принаймні мати ту ж мережу:
 ```bash