Автентифікація/авторизація kubelet
Огляд
HTTP-запити до HTTPS-точки доступу kubelet надають доступ до даних різного рівня чутливості та дозволяють виконувати операції з різними рівнями повноважень на вузлі та в контейнерах.
У цьому документі описано, як автентифікувати та авторизувати доступ до HTTPS-точки доступу kubelet.
Автентифікація kubelet
Стандартно запити до HTTPS-точки доступу kubelet, які не відхилені іншими налаштованими методами автентифікації, розглядаються як анонімні запити та отримують імʼя користувача system:anonymous
та групу system:unauthenticated
.
Щоб вимкнути анонімний доступ та надсилати відповіді 401 Unauthorized
на невідомі запити:
- запустіть kubelet з прапорцем
--anonymous-auth=false
Щоб увімкнути автентифікацію за допомогою клієнтських сертифікатів X509 до HTTPS-точки доступу kubelet:
- запустіть kubelet з прапорцем
--client-ca-file
, надаючи набір кореневих сертифікатів для перевірки клієнтських сертифікатів - запустіть apiserver з прапорцями
--kubelet-client-certificate
та--kubelet-client-key
- див. документацію з автентифікації apiserver для отримання додаткових відомостей
Щоб увімкнути використання API-токенів на предʼявника (включаючи токени службових облікових записів) для автентифікації до HTTPS-точки доступу kubelet:
- переконайтеся, що група API
authentication.k8s.io/v1beta1
ввімкнена в apiserver - запустіть kubelet з прапорцями
--authentication-token-webhook
та--kubeconfig
- kubelet викликає API
TokenReview
на налаштованому apiserver, щоб визначити інформацію про користувача з токенів на предʼявника
Авторизація kubelet
Будь-який запит, який успішно автентифікується (включаючи анонімний запит), потім авторизується. Стандартний режим авторизації — AlwaysAllow
, який дозволяє всі запити.
Є багато можливих причин для розподілу доступу до API kubelet:
- ввімкнено анонімну автентифікацію, але потрібно обмежити можливості анонімних користувачів викликати API kubelet
- ввімкнено автентифікацію з використанням токенів на предʼявника, але потрібно обмежити можливості довільних користувачів API (наприклад, службові облікові записи) викликати API kubelet
- ввімкнено автентифікацію за допомогою клієнтських сертифікатів, але дозволено використовувати API kubelet тільки деяким сертифікатам клієнтів, які підписані налаштованим кореневим сертифікатом
Щоб розділити доступ до API kubelet, делегуйте авторизацію apiserver:
- переконайтеся, що група API
authorization.k8s.io/v1beta1
ввімкнена в apiserver - запустіть kubelet з прапорцями
--authorization-mode=Webhook
та--kubeconfig
- kubelet викликає API
SubjectAccessReview
на налаштованому apiserver, щоб визначити, чи авторизований кожний запит
Kubelet авторизує запити до API, використовуючи той самий підхід до атрибутів запиту, що й apiserver.
Дієслово визначається з HTTP-дії вхідного запиту:
HTTP-дія | Дієслово запиту |
---|---|
POST | create |
GET, HEAD | get |
PUT | update |
PATCH | patch |
DELETE | delete |
Ресурс та субресурс визначаються з шляху вхідного запиту:
Kubelet API | Ресурс | Субресурс |
---|---|---|
/stats/* | nodes | stats |
/metrics/* | nodes | metrics |
/logs/* | nodes | log |
/spec/* | nodes | spec |
/checkpoint/* | nodes | checkpoint |
всі інші | nodes | proxy |
Атрибути простору імен та групи API завжди є порожніми рядками, а імʼя ресурсу завжди є імʼям обʼєкта Node
kubelet.
При використанні цього режиму переконайтеся, що користувач, визначений прапорцями --kubelet-client-certificate
та --kubelet-client-key
, переданими до apiserver, має дозвіл наступних атрибутів:
- verb=*, resource=nodes, subresource=proxy
- verb=*, resource=nodes, subresource=stats
- verb=*, resource=nodes, subresource=log
- verb=*, resource=nodes, subresource=spec
- verb=*, resource=nodes, subresource=metrics
Детальна авторизація
Kubernetes v1.32 [alpha]
(стандартно увімкнено: false)Коли увімкнено функціональну можливість KubeletFineGrainedAuthz
, kubelet виконує детальну перевірку перед поверненням до підресурсу proxy
для кінцевих точок /pods
, /runningPods
, /configz
та /healthz
. Ресурс і підресурс визначаються за шляхом вхідного запиту:
Kubelet API | ресурс | підресурс |
---|---|---|
/stats/* | nodes | stats |
/metrics/* | nodes | metrics |
/logs/* | nodes | log |
/spec/* | nodes | spec |
/pods | nodes | pods, proxy |
/runningPods/ | nodes | pods, proxy |
/healthz | nodes | healthz, proxy |
/configz | nodes | configz, proxy |
all others | nodes | proxy |
Коли функціональну можливість KubeletFineGrainedAuthz
увімкнено, переконайтеся, що користувач, ідентифікований прапорцями --kubelet-client-certificate
та --kubelet-client-key
, переданими серверу API, є авторизованим для наступних атрибутів:
- verb=*, resource=nodes, subresource=proxy
- verb=*, resource=nodes, subresource=stats
- verb=*, resource=nodes, subresource=log
- verb=*, resource=nodes, subresource=spec
- verb=*, resource=nodes, subresource=metrics
- verb=*, resource=nodes, subresource=configz
- verb=*, resource=nodes, subresource=healthz
- verb=*, resource=nodes, subresource=pods