Аутентифікація та авторизація kubelet

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Аутентифікація kubelet

З документа:

За замовчуванням запити до HTTPS-ендпоінта kubelet, які не відхиляються іншими налаштованими методами аутентифікації, вважаються анонімними запитами і отримують ім’я користувача system:anonymous та групу system:unauthenticated.

Існує 3 методи аутентифікації:

  • Anonymous (за замовчуванням): встановіть параметр --anonymous-auth=true або в конфігурації:
"authentication": {
"anonymous": {
"enabled": true
},
  • Webhook: Це дозволить увімкнути kubectl API bearer tokens як авторизацію (будь-який дійсний токен буде прийнятий). Дозвольте це за допомогою:
  • переконайтеся, що група API authentication.k8s.io/v1beta1 увімкнена в API-сервері
  • запустіть kubelet з флагами --authentication-token-webhook та --kubeconfig або використайте наступну настройку:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

kubelet звертається до TokenReview API на налаштованому API-сервері, щоб визначити інформацію про користувача з bearer tokens

  • X509 client certificates: Дозволяють автентифікуватися за допомогою X509 client certs
  • дивіться apiserver authentication documentation для детальнішої інформації
  • запустіть kubelet з прапорцем --client-ca-file, надаючи CA bundle для перевірки client certificates. Або з конфігурацією:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Авторизація Kubelet

Будь-який запит, який успішно автентифіковано (включно з анонімним запитом), потім авторизується. За замовчуванням режим авторизації — AlwaysAllow, який дозволяє всі запити.

Однак іншим можливим значенням є webhook (саме це ви найчастіше зустрінете). Цей режим перевіряє права автентифікованого користувача, щоб дозволити або заборонити виконання дії.

Warning

Зверніть увагу, що навіть якщо анонімна автентифікація увімкнена, анонімний доступ може не мати жодних прав для виконання жодної дії.

Авторизацію через webhook можна налаштувати за допомогою параметра --authorization-mode=Webhook або через файл конфігурації за допомогою:

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

Kubelet викликає API SubjectAccessReview на налаштованому API-сервері, щоб визначити, чи кожен запит авторизований.

Kubelet авторизує API-запити, використовуючи той самий підхід request attributes, що й apiserver:

  • Action
HTTP verbrequest verb
POSTcreate
GET, HEADget (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUTupdate
PATCHpatch
DELETEdelete (for individual resources), deletecollection (for collections)
  • Ресурс, який опрацьовує Kubelet API, завжди — nodes, а subresource визначається з шляху вхідного запиту:
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

Запити на основі WebSocket /exec, /run, /attach, and /portforward потрапляють у стандартний підресурс proxy і авторизуються з використанням початкового HTTP GET рукопотискання. Принципал, у якого є лише nodes/proxy GET, все одно може виконувати exec у контейнерах, якщо підключається безпосередньо до https://<node_ip>:10250 через WebSockets. Див. the nodes/proxy GET -> Kubelet /exec verb confusion abuse для деталей.

Наприклад, наступний запит намагався отримати інформацію про pods kubelet без дозволу:

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)
  • Ми отримали Forbidden, тому запит passed the Authentication check. Якби ні, ми б отримали лише повідомлення Unauthorised.
  • Ми бачимо username (у цьому випадку з token)
  • Зверніть увагу, як resource було nodes і subresource — proxy (що узгоджується з попередньою інформацією)

Посилання

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks