Kubelet Authentication & Authorization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
За замовчуванням запити до HTTPS-інтерфейсу kubelet, які не відхилені іншими налаштованими методами аутентифікації, розглядаються як анонімні запити і отримують ім'я користувача system:anonymous
та групу system:unauthenticated
.
3 методи аутентифікації:
Анонімний (за замовчуванням): Використовуйте налаштування, встановивши параметр --anonymous-auth=true
або конфігурацію:
Webhook: Це дозволить токени API bearer kubectl як авторизацію (будь-який дійсний токен буде дійсним). Дозвольте це з:
переконайтеся, що група API authentication.k8s.io/v1beta1
увімкнена на сервері API
запустіть kubelet з прапорами --authentication-token-webhook
та --kubeconfig
або використайте наступне налаштування:
Kubelet викликає TokenReview
API на налаштованому API сервері, щоб визначити інформацію про користувача з токенів доступу
X509 клієнтські сертифікати: Дозволяють аутентифікацію через X509 клієнтські сертифікати
дивіться документацію з аутентифікації apiserver для отримання додаткової інформації
запустіть kubelet з прапором --client-ca-file
, надаючи пакет CA для перевірки клієнтських сертифікатів. Або з конфігурацією:
Будь-який запит, який успішно аутентифікований (включаючи анонімний запит) потім авторизується. За замовчуванням режим авторизації - AlwaysAllow
, який дозволяє всі запити.
Однак інше можливе значення - webhook
(що ви в основному будете знаходити там). Цей режим перевіряє дозволи аутентифікованого користувача для дозволу або заборони дії.
Зверніть увагу, що навіть якщо анонімна аутентифікація увімкнена, анонімний доступ може не мати жодних дозволів для виконання будь-якої дії.
Авторизація через webhook може бути налаштована за допомогою параметра --authorization-mode=Webhook
або через конфігураційний файл з:
The kubelet викликає SubjectAccessReview
API на налаштованому API сервері, щоб визначити, чи кожен запит є авторизованим.
Kubelet авторизує API запити, використовуючи той же підхід атрибутів запиту, що й apiserver:
Дія
Ресурс, що спілкується з Kubelet api, є завжди вузлами, а підресурс визначається з шляху вхідного запиту:
Наприклад, наступний запит намагався отримати доступ до інформації про поди kubelet без дозволу:
Ми отримали Заборонено, тому запит пройшов перевірку автентифікації. Якщо б ні, ми отримали б лише повідомлення Неавторизовано
.
Ми можемо бачити ім'я користувача (в даному випадку з токена)
Перевірте, як ресурс був вузлами і субресурс проксі (що має сенс з попередньою інформацією)
HTTP verb | request verb |
---|---|
Kubelet API | ресурс | підресурс |
---|---|---|
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
POST
create
GET, HEAD
get (для окремих ресурсів), list (для колекцій, включаючи повний вміст об'єкта), watch (для спостереження за окремим ресурсом або колекцією ресурсів)
PUT
update
PATCH
patch
DELETE
delete (для окремих ресурсів), deletecollection (для колекцій)
/stats/*
вузли
stats
/metrics/*
вузли
metrics
/logs/*
вузли
log
/spec/*
вузли
spec
всі інші
вузли
proxy