# Використання авторизації вузлів LLMS index: [llms.txt](/llms.txt) --- Авторизація вузлів — це режим авторизації спеціального призначення, який спеціально авторизує запити API, зроблені kubelet-ами. ## Огляд {#overview} Авторизатор вузлів дозволяє kubelet-ам виконувати операції з API. Це включає: Операції читання: * services * endpoints * nodes * pods * secrets, configmaps, persistent volume claims та persistent volumes, що стосуються Podʼів, привʼязаних до вузла kubelet-а
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.34 [stable](стандартно увімкнено)
Kubelets обмежені читанням власних обʼєктів Node і читанням тільки подів, привʼязаних до їхнього вузла. Операції запису: * вузли та статус вузлів (увімкніть втулок допуску `NodeRestriction`, щоб обмежити kubelet у зміні свого власного вузла) * поди та статус подів (увімкніть втулок допуску `NodeRestriction`, щоб обмежити kubelet у зміні подів, привʼязаних до себе) * події Операції, повʼязані з авторизацією: * доступ на читання/запис [API CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/) для початкового завантаження TLS * можливість створювати TokenReview та SubjectAccessReview для делегованої автентифікації/авторизації У майбутніх випусках авторизатор вузлів може додавати або видаляти дозволи, щоб забезпечити kubelet-и мінімальним набором дозволів, необхідних для правильної роботи. Для того, щоб бути авторизованими авторизатором вузлів, kubelet-и повинні використовувати облікові дані, які ідентифікують їх як членів групи `system:nodes`, з іменем користувача `system:node:`. Цей формат групи та імені користувача відповідає ідентичності, створеній для кожного kubelet-а в рамках [початкового завантаження TLS kubelet-а](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/). Значення `` **має** точно відповідати імені вузла, як зареєстровано kubelet-ом. Типово це імʼя хосту, надане `hostname`, або замінене за допомогою [опції kubelet](/docs/reference/command-line-tools-reference/kubelet/) `--hostname-override`. Однак, при використанні опції kubelet `--cloud-provider`, конкретне імʼя хосту може бути визначено постачальником хмарних послуг, ігноруючи локальний `hostname` та опцію `--hostname-override`. Для деталей щодо визначення імені хосту kubelet-ом, дивіться [довідник з опцій kubelet](/docs/reference/command-line-tools-reference/kubelet/). Щоб увімкнути авторизатор вузла, запустіть API server з прапорцем `--authorization-config`, встановленим у файлі, який містить авторизатор `Node`; наприклад: ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AuthorizationConfiguration authorizers: ... - type: Node ... ``` Або запустіть API server з прапорцем `--authorization-mode`, встановленим на список, розділений комами, який включає `Node`; наприклад: ```shell kube-apiserver --authorization-mode=...,Node --other-options --more-options ``` Щоб обмежити обʼєкти API, які можуть писати kubelet-и, увімкніть [втулок допуску NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#noderestriction) шляхом запуску apiserver з `--enable-admission-plugins=...,NodeRestriction,...`. ## Обмеження аудиторії токена службового облікового запису {#service-account-token-audience-restriction}
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.33 [beta](стандартно увімкнено)
Коли функціональну можливість [`ServiceAccountNodeAudienceRestriction`](/docs/reference/command-line-tools-reference/feature-gates/#ServiceAccountNodeAudienceRestriction) увімкнено і втулок допуску `NodeRestriction` активний, kubelet може запитувати токени службових облікових записів лише для аудиторій, які вже згадуються в Podʼах на цьому вузлі. Це запобігає отриманню токенів для довільних аудиторій у разі компрометації вузла. Дозволені аудиторії визначаються з Pod spec: * Типова аудиторія API сервера (порожня або налаштована аудиторія API сервера). * Аудиторії, встановлені в джерелах томів токенів службових облікових записів. * Аудиторії, налаштовані в `spec.tokenRequests` драйвера CSI для будь-якого драйвера CSI, що використовується подом, незалежно від того, чи це вбудовані томи CSI, томи, підтримувані PersistentVolumeClaim, або ефемерні томи. Це особливо актуально при використанні [токенів службових облікових записів для постачальників облікових даних образів](/docs/tasks/administer-cluster/kubelet-credential-provider/#service-account-token-for-image-pulls), де kubelet запитує токени з аудиторією, специфічною для реєстру, від імені подів. ### Додавання додаткових аудиторій за допомогою RBAC {#allowing-additional-audiences} Ви можете надати kubelet-ам дозвіл на запит токенів для аудиторій, які виходять за межі тих, що згадуються в Pod spec. Коли kubelet запитує токен з аудиторією, яка не знайдена в Pod spec, втулок допуску NodeRestriction перевіряє, чи авторизований kubelet, виконуючи перевірку авторизації з наступними атрибутами: | Атрибут | Значення | | ---------- | ----- | | Дієслово | `request-serviceaccounts-token-audience` | | Група API | (порожній рядок, що означає основну групу API) | | Ресурс | Значення запитуваної аудиторії | | Імʼя | Імʼя службового облікового запису | | Простір імен | Простір імен службового облікового запису | Ви можете використовувати стандартні правила RBAC для авторизації цих перевірок. Поле `resources` контролює, які аудиторії дозволені, а поле `resourceNames` контролює, до яких службових облікових записів застосовується правило. Наприклад, щоб дозволити kubelet-у запитувати аудиторію `my-registry-audience` для конкретного службового облікового запису: ```yaml 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` дозволяє будь-яку аудиторію: ```yaml 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-ів: ```yaml 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 ```

Примітка:

Це обмеження є частиною втулка допуску NodeRestriction і застосовується лише до ідентичностей вузлів (kubelet-ів). Воно не обмежує, які аудиторії можуть запитувати інші виклики API TokenRequest. Якщо вам потрібно обмежити інших викликачів, розгляньте можливість використання ValidatingAdmissionPolicy.
## Міркування щодо міграції {#migration-considerations} ### Kubelet-и поза групою `system:nodes` {#kubelets-outside-the-system-nodes-group} Kubelet-и, що знаходяться поза групою `system:nodes`, не будуть авторизовані режимом авторизації `Node`, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує. Втулок допуску вузлів не буде обмежувати запити від цих kubelet-ів. ### Kubelet-и з недиференційованими іменами користувачів {#kubelets-with-undifferentiated-usernames} У деяких розгортаннях kubelet-и мають облікові дані, що розміщують їх у групі `system:nodes`, але не ідентифікують конкретний вузол, з яким вони повʼязані, оскільки вони не мають імені користувача у форматі `system:node:...`. Ці kubelet-и не будуть авторизовані режимом авторизації `Node`, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує. Втулок допуску `NodeRestriction` буде ігнорувати запити від цих kubelet-ів, оскільки типова реалізація ідентифікатора вузла не вважатиме це ідентичністю вузла.