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