# Службові облікові записи > Дізнайтеся про обʼєкти ServiceAccount в Kubernetes. --- LLMS index: [llms.txt](/llms.txt) --- Ця сторінка розповідає про обʼєкт ServiceAccount в Kubernetes, надаючи інформацію про те, як працюють службові облікові записи, про їх використання, обмеження, альтернативи та посилання на ресурси для додаткової допомоги. ## Що таке службові облікові записи? {#what-are-service-accounts} Службовий обліковий запис — це тип облікового запису, що використовується компонентами системи (не людьми), який забезпечує окремий ідентифікатор у кластері Kubernetes. Podʼи застосунків, системні компоненти та сутності всередині та поза кластером можуть використовувати облікові дані конкретного ServiceAccount, щоб ідентифікуватися як цей ServiceAccount. Це корисно в різних ситуаціях, включаючи автентифікацію в API-сервері або впровадження політик безпеки на основі ідентичності. Службові облікові записи існують як обʼєкти ServiceAccount в API-сервері. Службові облікові записи мають наступні властивості: - **Привʼязані до простору імен:** Кожен службовий обліковий запис привʼязаний до простору імен Kubernetes. Кожен простір імен отримує [`default` ServiceAccount](#default-service-accounts) при створенні. - **Легкі:** Службові облікові записи існують в кластері та визначені в API Kubernetes. Ви можете швидко створювати службові облікові записи для виконання певних завдань. - **Переносні:** Набір конфігурацій для складного контейнеризованого робочого навантаження може включати визначення службових облікових записів для системних компонентів. Легкість службових облікових записів та ідентичності в межах простору імен роблять конфігурації переносними. Службові облікові записи відрізняються від облікових записів користувачів, які є автентифікованими користувачами-людьми у кластері. Типово облікові записи користувачів не існують в API-сервері Kubernetes; замість цього сервер API розглядає ідентичності користувачів як непрозорі дані. Ви можете пройти автентифікацію за допомогою облікового запису користувача, використовуючи кілька методів. Деякі дистрибутиви Kubernetes можуть додавати власні розширені API для представлення облікових записів користувачів в API-сервері.
Порівняння між службовими обліковими записами та користувачами
Опис ServiceAccount Користувач або група
Місцезнаходження Kubernetes API (обʼєкт ServiceAccount) Зовнішній
Контроль доступу Керування доступом за допомогою RBAC Kubernetes або іншими механізмами авторизації Керування доступом за допомогою RBAC Kubernetes або іншими механізмами управління ідентичністю та доступом
Призначене використання Робочі завдання, автоматизація Люди
### Стандартні службові облікові записи {#default-service-accounts} При створенні кластера Kubernetes автоматично створює обʼєкт ServiceAccount з імʼям `default` для кожного простору імен у вашому кластері. Стандартні службові облікові записи у кожному просторі імен типово не мають прав, окрім [стандартних дозволів на знаходження API](/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings), які Kubernetes надає всім автентифікованим субʼєктам, якщо увімкнено контроль доступу на основі ролей (RBAC). Якщо ви видаляєте обʼєкт ServiceAccount з імʼям `default` в просторі імен, панель управління замінює його новим. Якщо ви розгортаєте Pod у просторі імен, і ви не [вручну призначаєте ServiceAccount для Podʼа](#assign-to-pod), Kubernetes призначає цьому Podʼу ServiceAccount `default` для цього простору імен. ## Використання службових облікових записів Kubernetes {#use-cases} Загалом, ви можете використовувати службові облікові записи для надання ідентичності в таких сценаріях: - Вашим Podʼам потрібно спілкуватися з сервером API Kubernetes, наприклад у таких ситуаціях: - Надання доступу лише для читання конфіденційної інформації, збереженої у Secret. - Надання [доступу між просторами імен](#cross-namespace), наприклад дозволу на читання, перелік та перегляд обʼєктів Lease в просторі імен `example` в просторі імен `kube-node-lease`. - Вашим Podʼам потрібно спілкуватися з зовнішнім сервісом. Наприклад, Podʼам робочого навантаження потрібна ідентичність для комерційного хмарного API, а комерційний постачальник дозволяє налаштувати відповідні довірчі стосунки. - [Автентифікація в приватному реєстрі образів за допомогою `imagePullSecret`](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). - Зовнішньому сервісу потрібно спілкуватися з сервером API Kubernetes. Наприклад, автентифікація у кластері як частина конвеєра CI/CD. - Ви використовуєте стороннє програмне забезпечення безпеки у своєму кластері, яке покладається на ідентичність службового облікового запису різних Podʼів, щоб згрупувати ці Podʼи у різні контексти. ## Як використовувати службові облікові записи {#how-to-use} Щоб скористатися службовим обліковим записом Kubernetes, виконайте наступне: 1. Створіть обʼєкт ServiceAccount за допомогою клієнта Kubernetes, такого як `kubectl`, або за допомогою маніфесту, який визначає обʼєкт. 2. Надайте дозволи обʼєкту ServiceAccount за допомогою механізму авторизації, такого як [RBAC](/docs/reference/access-authn-authz/rbac/). 3. Призначте обʼєкт ServiceAccount Podʼам під час створення Podʼа. Якщо ви використовуєте ідентифікацію із зовнішнього сервісу, [отримайте токен ServiceAccount](#get-a-token) та використовуйте його з цього сервісу. Щоб дізнатися, як це зробити, перегляньте [Налаштування службових облікових записів для Podʼів](/docs/tasks/configure-pod-container/configure-service-account/). ### Надання дозволів обліковому запису ServiceAccount {#grant-permissions} Ви можете використовувати вбудований механізм [керування доступом на основі ролей (RBAC)](/docs/reference/access-authn-authz/rbac/) Kubernetes, щоб надати мінімальні дозволи, необхідні кожному службовому обліковому запису. Ви створюєте *роль*, яка надає доступ, а потім *привʼязуєте* роль до вашого ServiceAccount. RBAC дозволяє визначити мінімальний набір дозволів, щоб дозволи облікового запису слідувати принципу найменших дозволів. Podʼи, які використовують цей службовий обліковий запис, не отримують більше дозволів, ніж необхідно для правильної роботи. Для інструкцій дивіться [Дозволи ServiceAccount](/docs/reference/access-authn-authz/rbac/#service-account-permissions). #### Крос-простірний доступ за допомогою облікового запису ServiceAccount {#cross-namespace} Ви можете використовувати RBAC, щоб дозволити службовим обліковим записам в одному просторі імен виконувати дії з ресурсами в іншому просторі імен в кластері. Наприклад, розгляньте ситуацію, коли у вас є службовий обліковий запис та Pod у просторі імен `dev`, і ви хочете, щоб ваш Pod бачив Job, які виконуються в просторі імен `maintenance`. Ви можете створити обʼєкт Role, який надає дозволи на перелік обʼєктів Job. Потім створіть обʼєкт RoleBinding у просторі імен `maintenance`, щоб привʼязати Role до ServiceAccount. Тепер Podʼи у просторі імен `dev` можуть бачити перелік обʼєктів Job у просторі імен `maintenance`, використовуючи цей службовий обліковий запис. ### Призначення ServiceAccount Podʼу {#assign-to-pod} Щоб призначити ServiceAccount Podʼу, ви встановлюєте поле `spec.serviceAccountName` у специфікації Pod. Kubernetes автоматично надає облікові дані для цього ServiceAccount Podʼу. У версії v1.22 і пізніше Kubernetes отримує короткостроковий, **автоматично змінюваний** токен за допомогою API `TokenRequest` та монтує його як [том projected](/docs/concepts/storage/projected-volumes/#serviceaccounttoken). Типово Kubernetes надає Podʼу облікові дані для призначеного ServiceAccount, хай то `default` ServiceAccount або спеціальний ServiceAccount, який ви вказуєте. Щоб запобігти автоматичному впровадженню Kubernetes облікових даних для вказаного ServiceAccount або `default` ServiceAccount, встановіть поле `automountServiceAccountToken` у вашій специфікації Pod на `false`. У версіях раніше 1.22 Kubernetes надає Podʼу довгостроковий статичний токен як Secret. #### Отримання облікових даних ServiceAccount вручну {#get-a-token} Якщо вам потрібні облікові дані для ServiceAccount, щоб вони монтувалися у нестандартне місце або для аудиторії, яка не є API-сервером, скористайтеся одним із наступних методів: - [API TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) (рекомендовано): Запитайте короткостроковий токен ServiceAccount безпосередньо з вашого власного *коду застосунку*. Термін дії токена автоматично спливає, і токен може змінюватись при закінченні строку дії. Якщо у вас є застаріла програма, яка не враховує Kubernetes, ви можете використовувати контейнер sidecar у тому ж самому Podʼі, щоб отримати ці токени та зробити їх доступними для робочого навантаження застосунку. - [Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection) (також рекомендовано): У Kubernetes v1.20 і пізніше скористайтеся специфікацією Pod, щоб вказати kubelet додати токен ServiceAccount до Pod як *projected том*. Термін дії projected токенів автоматично спливає, а kubelet змінює токен до закінчення строку дії. - [Service Account Token Secrets](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount) (не рекомендується): Ви можете монтувати токени службового облікового запису як Secret Kubernetes у Podʼах. Ці токени не мають терміну дії та не ротуються. У версіях до v1.24 для кожного службового облікового запису автоматично створювався постійний токен. Цей метод більше не рекомендується, особливо у великому масштабі, через ризики, повʼязані зі статичними, довготривалими обліковими даними. Функціональна можливість [LegacyServiceAccountTokenNoAutoGeneration](/docs/reference/command-line-tools-reference/feature-gates-removed) (яка була стандартно увімкнена в Kubernetes з v1.24 по v1.26), перешкоджала автоматичному створенню цих токенів для службових облікових записів. Її було вилучено у версії v1.27, оскільки вона перейшла у статус GA; ви все ще можете вручну створювати нескінченні токени службових облікових записів, але повинні враховувати наслідки для безпеки. #### Обмеження аудиторії вузлів для токенів службових облікових записів {#node-audience-restriction}
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.33 [beta](стандартно увімкнено)
Коли функціональна можливість [`ServiceAccountNodeAudienceRestriction`](/docs/reference/command-line-tools-reference/feature-gates/#ServiceAccountNodeAudienceRestriction) увімкнена, втулок допуску [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#noderestriction) обмежує, які аудиторії kubelet може запитувати при створенні токенів службового облікового запису через API `TokenRequest`. Зазвичай kubelet може запитувати токени лише для аудиторій, які вже згадуються у Podʼах на цьому вузлі (через проєцьовані томи токенів службового облікового запису або запити токенів драйвера CSI). Адміністратори можуть надати kubelet доступ до додаткових аудиторій за допомогою правил RBAC з дієсловом `request-serviceaccounts-token-audience`. Це обмеження застосовується лише до kubelet (ідентичності вузлів) і не впливає на інших клієнтів API `TokenRequest`. Для деталей та прикладів RBAC див. [Обмеження аудиторії токенів службового облікового запису](/docs/reference/access-authn-authz/node/#service-account-token-audience-restriction).

Примітка:

Для застосунків, які працюють поза вашим кластером Kubernetes, ви, можливо, розглядаєте можливість створення довгострокового токена ServiceAccount, який зберігається в Secret. Це дозволяє автентифікацію, але проєкт Kubernetes рекомендує уникати такого підходу. Довгострокові токени на предʼявника є ризиком безпеки, оскільки після розкриття токен може бути використаний не за призначенням. Замість цього розгляньте альтернативу. Наприклад, ваш зовнішній застосунок може автентифікуватися за допомогою добре захищеного приватного ключа та сертифікату або за допомогою спеціального механізму, такого як webhook автентифікації токенів, який ви реалізуєте самостійно.

Ви також можете використовувати TokenRequest для отримання короткострокових токенів для вашого зовнішнього застосунку.

### Обмеження доступу до Secret (застаріло) {#enforce-mountable-secrets}
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.32 [deprecated]

Примітка:

kubernetes.io/enforce-mountable-secrets є застарілим, починаючи з Kubernetes v1.32. Використовуйте окремі простори імен для ізоляції доступу до змонтованих секретів.
У Kubernetes існує анотація з назвою `kubernetes.io/enforce-mountable-secrets`, яку ви можете додати до своїх ServiceAccounts. Коли ця анотація застосовується, Secret ServiceAccount можна монтувати лише на вказані типи ресурсів, покращуючи безпеку вашого кластера. Ви можете додати анотацію до ServiceAccount за допомогою маніфесту: ```yaml apiVersion: v1 kind: ServiceAccount metadata: annotations: kubernetes.io/enforce-mountable-secrets: "true" name: my-serviceaccount namespace: my-namespace ``` Коли ця анотація встановлена на `true`, панель управління Kubernetes переконується, що Secret з цього ServiceAccount підлягають певним обмеженням монтування. 1. Назва кожного Secret, який монтується як том Podʼа, повинна зʼявитися в полі `secrets` ServiceAccount Podʼа. 2. Назва кожного Secret, на який ви посилаєтесь за допомогою `envFrom` у Podʼі, також повинна зʼявитися в полі `secrets` ServiceAccount Podʼа. 3. Назва кожного Secret, на який ви посилаєтесь за допомогою `imagePullSecrets` у Podʼі, також повинна зʼявитися в полі `secrets` ServiceAccount Podʼа. Розуміючи та застосовуючи ці обмеження, адміністратори кластера можуть підтримувати жорсткіший профіль безпеки та забезпечити, що Secret доступні лише відповідним ресурсам. ## Автентифікація службових облікових записів {#authenticating-credentials} ServiceAccounts використовують підписані JSON Web Tokens (JWT) для автентифікації в API-сервері Kubernetes та будь-якій іншій системі, де існує довіра. Залежно від того, як був виданий токен (або обмежений за часом за допомогою `TokenRequest`, або використовуючи застарілий механізм із Secret), токен ServiceAccount може також мати час дії, аудиторію та час, коли токен *починає* бути дійсним. Коли клієнт, який діє як ServiceAccount, намагається спілкуватися з API-сервером Kubernetes, клієнт включає заголовок `Authorization: Bearer ` з HTTP-запитом. API-сервер перевіряє чинність цього токена наступним чином: 1. Перевіряє підпис токена. 2. Перевіряє, чи не закінчився строк дії токена. 3. Перевіряє, чи наразі дійсні посилання на обʼєкти у твердженнях токена. 4. Перевіряє, чи наразі токен є дійсним. 5. Перевіряє аудиторію тверджень. API TokenRequest створює *звʼязані токени* для ServiceAccount. Ця звʼязка повʼязана з життєвим циклом клієнта, такого як Pod, який діє як цей ServiceAccount. Дивіться [Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection) для прикладу схеми та полів JWT звʼязаного токена службового облікового запису. Для токенів, виданих за допомогою API `TokenRequest`, API-сервер також перевіряє, чи існує зараз конкретне посилання на обʼєкт, яке використовує ServiceAccount, за унікальним ідентифікатором цього обʼєкта. Для застарілих токенів, які монтувалися як Secretʼи в Podʼах, API-сервер перевіряє токен за допомогою Secret. Для отримання додаткової інформації про процес автентифікації, див. [Автентифікація](/docs/reference/access-authn-authz/authentication/#service-account-tokens). ### Автентифікація службових облікових записів у вашому власному коді {#authenticating-in-code} Якщо у вас є власні служби, які потребують перевірки службових облікових даних Kubernetes, ви можете скористатися такими методами: - [API TokenReview](/docs/reference/kubernetes-api/authentication-resources/token-review-v1/) (рекомендовано) - Виявлення OIDC Проєкт Kubernetes рекомендує використовувати API TokenReview, оскільки цей метод анулює токени, які привʼязані до обʼєктів API, таких як Secrets, ServiceAccounts, Podʼи або Вузли, коли ці обʼєкти видаляються. Наприклад, якщо ви видаляєте Pod, що містить projected токен ServiceAccount, кластер негайно анулює цей токен, і перевірка TokenReview негайно зазнає невдачі. Якщо ви використовуєте перевірку OIDC замість цього, ваші клієнти продовжують розглядати токен як дійсний, доки токен не досягне часу закінчення дії. Ваш застосунок повинен завжди визначати аудиторію, яку він приймає, і перевіряти, що аудиторії токена відповідають аудиторіям, які очікує ваш застосунок. Це допомагає зменшити обсяг застосування токена так, що він може бути використаний лише у вашому застосунку і ніде більше. ## Альтернативи {#alternatives} - Видавайте свої власні токени, використовуючи інший механізм, а потім використовуйте [Автентифікацію токенів за допомогою веб-хуків](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication), щоб перевіряти токени розробника за допомогою власної служби перевірки. - Надавайте свої власні ідентифікатори для Podʼів. - [Використовуйте SPIFFE CSI driver, щоб надавати SPIFFE SVIDs як пари сертифікатів X.509 для Podʼів](https://cert-manager.io/docs/projects/csi-driver-spiffe/).
🛇 Цей елемент посилається на сторонній проєкт або продукт, який не є частиною Kubernetes. Докладніше
- [Використовуйте сервісні мережі, такі як Istio, для надання сертифікатів Podʼів](https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/). - Автентифікуйтеся ззовні кластера до API-сервера без використання токенів службового облікового запису: - [Налаштуйте API-сервер для прийняття токенів OpenID Connect (OIDC) від вашого постачальника ідентифікації](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens). - Використовуйте службові облікові записи або облікові записи користувачів, створені за допомогою зовнішньої служби управління доступом та ідентифікації (IAM), наприклад від постачальника хмарних послуг, для автентифікації в вашому кластері. - [Використовуйте API-інтерфейс CertificateSigningRequest з клієнтськими сертифікатами](/docs/tasks/tls/managing-tls-in-a-cluster/). - [Налаштуйте kubelet для отримання облікових даних з реєстру образів](/docs/tasks/administer-cluster/kubelet-credential-provider/). - Використовуйте втулок пристрою, щоб отримати доступ до віртуального Trusted Platform Module (TPM), що дозволяє потім автентифікуватися за допомогою приватного ключа. ## Що далі - Дізнайтеся, як [керувати ServiceAccounts як адміністратор кластера](/docs/reference/access-authn-authz/service-accounts-admin/). - Дізнайтеся, як [призначити ServiceAccounts для Podʼів](/docs/tasks/configure-pod-container/configure-service-account/). - Прочитайте [довідку API ServiceAccount](/docs/reference/kubernetes-api/authentication-resources/service-account-v1/).