Використання авторизації вузлів
Авторизація вузлів — це режим авторизації спеціального призначення, який спеціально авторизує запити API, зроблені kubelet-ами.
Огляд
Авторизатор вузлів дозволяє kubelet-ам виконувати операції з API. Це включає:
Операції читання:
- services
- endpoints
- nodes
- pods
- secrets, configmaps, persistent volume claims та persistent volumes, що стосуються Podʼів, привʼязаних до вузла kubelet-а
Kubernetes v1.31 [alpha]
(стандартно увімкнено: false)Коли функціональну можливість AuthorizeNodeWithSelectors
увімкнено (разом із передумовою AuthorizeWithSelectors
), kubelets можуть читати лише власні обʼєкти Node і можуть читати лише Podʼи, привʼязані до їхнього вузла.
Операції запису:
- вузли та статус вузлів (увімкніть втулок допуску
NodeRestriction
, щоб обмежити kubelet у зміні свого власного вузла) - поди та статус подів (увімкніть втулок допуску
NodeRestriction
, щоб обмежити kubelet у зміні подів, привʼязаних до себе) - події
Операції, повʼязані з авторизацією:
- доступ на читання/запис API CertificateSigningRequests для TLS початкового запуску
- можливість створювати TokenReview та SubjectAccessReview для делегованої автентифікації/авторизації
У майбутніх випусках авторизатор вузлів може додавати або видаляти дозволи, щоб забезпечити kubelet-и мінімальним набором дозволів, необхідних для правильної роботи.
Для того, щоб бути авторизованими авторизатором вузлів, kubelet-и повинні використовувати облікові дані, які ідентифікують їх як членів групи system:nodes
, з іменем користувача system:node:<nodeName>
. Цей формат групи та імені користувача відповідає ідентичності, створеній для кожного kubelet-а в рамках TLS початкового запуску kubelet-а.
Значення <nodeName>
має точно відповідати імені вузла, як зареєстровано kubelet-ом. Стандартно це імʼя хосту, надане hostname
, або замінене за допомогою опції kubelet --hostname-override
. Однак, при використанні опції kubelet --cloud-provider
, конкретне імʼя хосту може бути визначено постачальником хмарних послуг, ігноруючи локальний hostname
та опцію --hostname-override
. Для деталей щодо визначення імені хосту kubelet-ом, дивіться довідник з опцій kubelet.
Щоб увімкнути авторизатор вузлів, запустіть apiserver з --authorization-mode=Node
.
Щоб обмежити обʼєкти API, які можуть писати kubelet-и, увімкніть втулок допуску NodeRestriction
шляхом запуску apiserver з --enable-admission-plugins=...,NodeRestriction,...
.
Міркування щодо міграції
Kubelet-и поза групою system:nodes
Kubelet-и, що знаходяться поза групою system:nodes
, не будуть авторизовані режимом авторизації Node
, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує. Вутлок допуску вузлів не буде обмежувати запити від цих kubelet-ів.
Kubelet-и з недиференційованими іменами користувачів
У деяких розгортаннях kubelet-и мають облікові дані, що розміщують їх у групі system:nodes
, але не ідентифікують конкретний вузол, з яким вони повʼязані, оскільки вони не мають імені користувача у форматі system:node:...
. Ці kubelet-и не будуть авторизовані режимом авторизації Node
, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує.
Втулок допуску NodeRestriction
буде ігнорувати запити від цих kubelet-ів, оскільки стандартна реалізація ідентифікатора вузла не вважатиме це ідентичністю вузла.