Kubernetes Pivoting to Clouds
GCP
Якщо ви запускаєте кластер k8s всередині GCP, ви, напевно, захочете, щоб деякий додаток, що працює всередині кластера, мав доступ до GCP. Є 2 поширених способи зробити це:
Монтування ключів GCP-SA як секрету
Поширений спосіб надати доступ до kubernetes-додатку до GCP:
Створити обліковий запис служби GCP
Призначити йому необхідні дозволи
Завантажити json-ключ створеного SA
Замонтувати його як секрет всередині пода
Встановити змінну середовища GOOGLE_APPLICATION_CREDENTIALS, що вказує на шлях, де знаходиться json.
Отже, як зловмисник, якщо ви скомпрометуєте контейнер всередині пода, вам слід перевірити цю змінну середовища та json файли з обліковими даними GCP.
Зв'язування json GSA з секретом KSA
Спосіб надати доступ до GSA для кластера GKE - це зв'язати їх таким чином:
Створити обліковий запис служби Kubernetes в тому ж просторі імен, що й ваш кластер GKE, використовуючи наступну команду:
Створіть Kubernetes Secret, який містить облікові дані облікового запису служби GCP, до якого ви хочете надати доступ до кластера GKE. Ви можете зробити це за допомогою інструменту командного рядка
gcloud
, як показано в наступному прикладі:
Прив'яжіть Kubernetes Secret до облікового запису служби Kubernetes за допомогою наступної команди:
На другому етапі були встановлені облікові дані GSA як секрет KSA. Тоді, якщо ви можете прочитати цей секрет з всередині кластеру GKE, ви можете ескалювати до цього облікового запису служби GCP.
Ідентичність робочого навантаження GKE
З ідентичністю робочого навантаження ми можемо налаштувати обліковий запис служби Kubernetes, щоб він діяв як обліковий запис служби Google. Поди, що працюють з обліковим записом служби Kubernetes, автоматично аутентифікуються як обліковий запис служби Google при доступі до API Google Cloud.
Перший рядок кроків для активації цієї поведінки - це активувати ідентичність робочого навантаження в GCP (кроки) та створити обліковий запис SA GCP, який ви хочете, щоб k8s наслідував.
Активуйте ідентичність робочого навантаження на новому кластері
Створити/Оновити новий пул вузлів (Кластери Autopilot не потребують цього)
Створіть GCP обліковий запис служби для наслідування з K8s з дозволами GCP:
Підключіться до кластера та створіть обліковий запис служби для використання
Прив'язати GSA до KSA
Запустіть pod з KSA та перевірте доступ до GSA:
Перевірте наступну команду для автентифікації у разі потреби:
Як атакуючий всередині K8s, ви повинні шукати SAs з анотацією iam.gke.io/gcp-service-account
, оскільки це вказує на те, що SA може отримати доступ до чогось у GCP. Іншим варіантом буде спробувати зловживати кожним KSA в кластері та перевірити, чи має він доступ.
З GCP завжди цікаво перерахувати зв'язки та дізнатися, який доступ ви надаєте SAs всередині Kubernetes.
Це скрипт для легкого перебору всіх визначень подів, шукаючи цю анотацію:
AWS
Kiam & Kube2IAM (IAM роль для Pods)
Застарілий спосіб надання IAM ролей Pods - це використання Kiam або Kube2IAM сервера. В основному, вам потрібно запустити daemonset у вашому кластері з якоюсь привілейованою IAM роллю. Цей daemonset буде тим, хто надасть доступ до IAM ролей pods, які цього потребують.
По-перше, вам потрібно налаштувати які ролі можуть бути доступні всередині простору імен, і ви робите це за допомогою анотації всередині об'єкта простору імен:
Якщо простір імен налаштований з IAM ролями, які можуть мати Pods, ви можете вказати роль, яку ви хочете для кожного визначення pod, з чимось на зразок:
Як атакуючий, якщо ви знайдете ці анотації в подах або просторах імен, або сервер kiam/kube2iam, що працює (ймовірно, в kube-system), ви можете вдаватись в кожну роль, яка вже використовується подами, і більше (якщо у вас є доступ до облікового запису AWS, перерахувати ролі).
Створити Pod з IAM роллю
IAM роль, яку потрібно вказати, повинна бути в тому ж обліковому записі AWS, що й роль kiam/kube2iam, і ця роль повинна мати можливість отримати до неї доступ.
IAM Role for K8s Service Accounts via OIDC
Це рекомендований спосіб від AWS.
По-перше, вам потрібно створити OIDC провайдера для кластера.
Потім ви створюєте IAM роль з дозволами, які буде вимагати SA.
Створіть довірчі відносини між IAM роллю та SA назва (або простори імен, що надають доступ до ролі всім SA в просторі імен). Довірчі відносини в основному перевірятимуть назву OIDC провайдера, назву простору імен та назву SA.
Нарешті, створіть SA з анотацією, що вказує ARN ролі, і контейнери, що працюють з цим SA, матимуть доступ до токена ролі. Токен записується в файл, а шлях вказується в
AWS_WEB_IDENTITY_TOKEN_FILE
(за замовчуванням:/var/run/secrets/eks.amazonaws.com/serviceaccount/token
)
Щоб отримати aws, використовуючи токен з /var/run/secrets/eks.amazonaws.com/serviceaccount/token
, виконайте:
Як атакуючий, якщо ви можете перерахувати кластер K8s, перевірте наявність облікових записів служби з цією анотацією, щоб ескалювати до AWS. Для цього просто exec/create pod, використовуючи один з привілейованих облікових записів служби IAM, і вкрадіть токен.
Більше того, якщо ви всередині pod, перевірте змінні середовища, такі як AWS_ROLE_ARN та AWS_WEB_IDENTITY_TOKEN.
Іноді політика довіри ролі може бути погано налаштована, і замість того, щоб надати доступ AssumeRole очікуваному обліковому запису служби, вона надає його всім обліковим записам служби. Тому, якщо ви здатні записати анотацію на контрольованому обліковому записі служби, ви можете отримати доступ до ролі.
Перевірте наступну сторінку для отримання додаткової інформації:
Знайти Pods a SAs з IAM ролями в кластері
Це скрипт для легкого ітерації по всіх pod та визначення sas, шукаючи цю анотацію:
Node IAM Role
Попередній розділ стосувався того, як вкрасти IAM ролі за допомогою подів, але зверніть увагу, що вузол K8s кластера буде екземпляром всередині хмари. Це означає, що вузол, ймовірно, буде мати нову IAM роль, яку ви можете вкрасти (зверніть увагу, що зазвичай всі вузли K8s кластера мають однакову IAM роль, тому може не мати сенсу перевіряти кожен вузол).
Однак є важлива вимога для доступу до метаданих з вузла, вам потрібно бути на вузлі (сеанс ssh?) або принаймні мати ту ж мережу:
Вкрасти токен IAM ролі
Раніше ми обговорювали, як прикріпити IAM ролі до Pods або навіть як втекти до вузла, щоб вкрасти IAM роль, яку екземпляр має прикріпленою до нього.
Ви можете використовувати наступний скрипт, щоб вкрасти ваші нові важко зароблені облікові дані IAM ролі:
Посилання
Last updated