Авторизація вузлів — це режим авторизації спеціального призначення, який спеціально авторизує запити API, зроблені kubelet-ами.
Авторизатор вузлів дозволяє kubelet-ам виконувати операції з API. Це включає:
Операції читання:
Kubernetes v1.34 [stable](стандартно увімкнено)Kubelets обмежені читанням власних обʼєктів Node і читанням тільки подів, привʼязаних до їхнього вузла.
Операції запису:
NodeRestriction, щоб обмежити kubelet у зміні свого власного вузла)NodeRestriction, щоб обмежити kubelet у зміні подів, привʼязаних до себе)Операції, повʼязані з авторизацією:
У майбутніх випусках авторизатор вузлів може додавати або видаляти дозволи, щоб забезпечити kubelet-и мінімальним набором дозволів, необхідних для правильної роботи.
Для того, щоб бути авторизованими авторизатором вузлів, kubelet-и повинні використовувати облікові дані, які ідентифікують їх як членів групи system:nodes, з іменем користувача system:node:<nodeName>. Цей формат групи та імені користувача відповідає ідентичності, створеній для кожного kubelet-а в рамках TLS початкового запуску kubelet-а.
Значення <nodeName> має точно відповідати імені вузла, як зареєстровано kubelet-ом. Стандартно це імʼя хосту, надане hostname, або замінене за допомогою опції kubelet --hostname-override. Однак, при використанні опції kubelet --cloud-provider, конкретне імʼя хосту може бути визначено постачальником хмарних послуг, ігноруючи локальний hostname та опцію --hostname-override. Для деталей щодо визначення імені хосту kubelet-ом, дивіться довідник з опцій kubelet.
Щоб увімкнути авторизатор вузла, запустіть API server з прапорцем --authorization-config, встановленим у файлі, який містить авторизатор Node; наприклад:
apiVersion: apiserver.config.k8s.io/v1
kind: AuthorizationConfiguration
authorizers:
...
- type: Node
...
Або запустіть API server з прапорцем --authorization-mode, встановленим на список, розділений комами, який включає Node; наприклад:
kube-apiserver --authorization-mode=...,Node --other-options --more-options
Щоб обмежити обʼєкти API, які можуть писати kubelet-и, увімкніть втулок допуску NodeRestriction шляхом запуску apiserver з --enable-admission-plugins=...,NodeRestriction,....
Kubernetes v1.33 [beta](стандартно увімкнено)Коли функціоналну можливість ServiceAccountNodeAudienceRestriction увімкнено і втулок допуску NodeRestriction активний, kubelet може запитувати токени службових облікових записів лише для аудиторій, які вже згадуються в Podʼах на цьому вузлі. Це запобігає отриманню токенів для довільних аудиторій у разі компрометації вузла.
Дозволені аудиторії визначаються з Pod spec:
spec.tokenRequests драйвера CSI для будь-якого драйвера CSI, що використовується подом, незалежно від того, чи це вбудовані томи CSI, томи, підтримувані PersistentVolumeClaim, або епhemeral томи.Це особливо актуально при використанні токенів службових облікових записів для постачальників облікових даних образів, де kubelet запитує токени з аудиторією, специфічною для реєстру, від імені подів.
Ви можете надати kubelet-ам дозвіл на запит токенів для аудиторій, які виходять за межі тих, що згадуються в Pod spec. Коли kubelet запитує токен з аудиторією, яка не знайдена в Pod spec, втулок допуску NodeRestriction перевіряє, чи авторизований kubelet, виконуючи перевірку авторизації з наступними атрибутами:
| Атрибут | Значення |
|---|---|
| Дієслово | request-serviceaccounts-token-audience |
| Група API | (порожній рядок, що означає основну групу API) |
| Ресурс | Значення запитуваної аудиторії |
| Імʼя | Імʼя службового облікового запису |
| Простір імен | Простір імен службового облікового запису |
Ви можете використовувати стандартні правила RBAC для авторизації цих перевірок. Поле resources контролює, які аудиторії дозволені, а поле resourceNames контролює, до яких службових облікових записів застосовується правило.
Наприклад, щоб дозволити kubelet-у запитувати аудиторію my-registry-audience для конкретного службового облікового запису:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-audience-my-registry
rules:
- verbs: ["request-serviceaccounts-token-audience"]
apiGroups: [""]
resources: ["my-registry-audience"]
resourceNames: ["my-service-account"]
Пропуск resourceNames дозволяє аудиторію для будь-якого службового облікового запису. Використання зірочки ("*") для resources дозволяє будь-яку аудиторію:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-audience-unrestricted
rules:
- verbs: ["request-serviceaccounts-token-audience"]
apiGroups: [""]
resources: ["*"] # будь-яка аудиторія
# без resourceNames: будь-який службовий обліковий запис
Привʼязка ClusterRole до групи system:nodes, щоб застосувати його до всіх kubelet-ів:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: node-audience-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: node-audience-my-registry
subjects:
- kind: Group
name: system:nodes
apiGroup: rbac.authorization.k8s.io
TokenRequest. Якщо вам потрібно обмежити інших викликів, розгляньте можливість використання ValidatingAdmissionPolicy.system:nodesKubelet-и, що знаходяться поза групою system:nodes, не будуть авторизовані режимом авторизації Node, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує. Вутлок допуску вузлів не буде обмежувати запити від цих kubelet-ів.
У деяких розгортаннях kubelet-и мають облікові дані, що розміщують їх у групі system:nodes, але не ідентифікують конкретний вузол, з яким вони повʼязані, оскільки вони не мають імені користувача у форматі system:node:.... Ці kubelet-и не будуть авторизовані режимом авторизації Node, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує.
Втулок допуску NodeRestriction буде ігнорувати запити від цих kubelet-ів, оскільки стандартна реалізація ідентифікатора вузла не вважатиме це ідентичністю вузла.