ServiceAccount

На цій сторінці описано обʼєкт ServiceAccount у Kubernetes: як працюють ServiceAccount, сценарії використання, обмеження, альтернативи та посилання на ресурси з додатковими настановами.

Що таке ServiceAccount?

ServiceAccount — це тип облікового запису не для людей, який у Kubernetes надає окрему ідентичність у кластері. Podʼи застосунків, системні компоненти та сутності всередині й поза кластером можуть використовувати облікові дані певного ServiceAccount, щоб ідентифікуватися як цей ServiceAccount. Така ідентичність корисна в різних ситуаціях, зокрема для автентифікації на API-сервері або реалізації політик безпеки на основі ідентичності.

ServiceAccount існують як обʼєкти ServiceAccount на API-сервері. Вони мають такі властивості:

• Привʼязані до простору імен: Кожен ServiceAccount привʼязаний до простору імен Kubernetes. Кожен простір імен під час створення отримує ServiceAccount default.

• Легкі: ServiceAccount існують у кластері й визначені в API Kubernetes. Ви можете швидко створювати ServiceAccount для виконання певних завдань.

• Переносні: Набір конфігурацій для складного контейнеризованого робочого навантаження може містити визначення ServiceAccount для компонентів системи. Легкість ServiceAccount та ідентичності в межах простору імен роблять конфігурації переносними.

ServiceAccount відрізняються від облікових записів користувачів, які є автентифікованими людьми в кластері. Стандартно облікові записи користувачів не існують на API-сервері Kubernetes; натомість API-сервер розглядає ідентичності користувачів як непрозорі дані. Автентифікуватися як обліковий запис користувача можна кількома способами. Деякі дистрибутиви Kubernetes можуть додавати власні API розширення для представлення облікових записів користувачів на API-сервері.

Стандартні ServiceAccount

Під час створення кластера Kubernetes автоматично створює обʼєкт ServiceAccount з назвою default для кожного простору імен у вашому кластері. ServiceAccount default у кожному просторі імен стандартно не мають дозволів, окрім стандартних дозволів на виявлення API, які Kubernetes надає всім автентифікованим субʼєктам, якщо ввімкнено контроль доступу на основі ролей (RBAC). Якщо ви видалите обʼєкт ServiceAccount default у просторі імен, панель управління замінить його новим.

Якщо ви розгортаєте Pod у просторі імен і вручну не призначаєте Podʼу ServiceAccount, Kubernetes призначає Podʼу ServiceAccount default цього простору імен.

Сценарії використання ServiceAccount у Kubernetes

Загалом ви можете використовувати ServiceAccount для надання ідентичностей у таких сценаріях:

• Вашим Podʼам потрібно взаємодіяти з API-сервером Kubernetes, наприклад у таких ситуаціях:
  • Надання доступу лише для читання до конфіденційної інформації, що зберігається в Secrets.
  • Надання доступу між просторами імен, наприклад дозвіл Podʼу в просторі імен example читати, перелічувати й відстежувати обʼєкти Lease у просторі імен kube-node-lease.
• Вашим Podʼам потрібно взаємодіяти із зовнішнім сервісом. Наприклад, Pod робочого навантаження потребує ідентичності для комерційного хмарного API, а комерційний постачальник дозволяє налаштувати відповідні довірчі стосунки.
• Автентифікація в приватному реєстрі образів за допомогою imagePullSecret.
• Зовнішньому сервісу потрібно взаємодіяти з API-сервером Kubernetes. Наприклад, автентифікація в кластері як частина конвеєра CI/CD.
• Ви використовуєте у своєму кластері стороннє програмне забезпечення безпеки, яке покладається на ідентичність ServiceAccount різних Podʼів, щоб групувати ці Podʼи в різні контексти.

Як використовувати ServiceAccount

Щоб скористатися ServiceAccount у Kubernetes, виконайте такі дії:

1. Створіть обʼєкт ServiceAccount за допомогою клієнта Kubernetes, такого як kubectl, або за допомогою маніфесту, який визначає обʼєкт.

2. Надайте дозволи обʼєкту ServiceAccount за допомогою механізму авторизації, такого як RBAC.

3. Призначте обʼєкт ServiceAccount Podʼам під час створення Podʼа.

   Якщо ви використовуєте ідентичність із зовнішнього сервісу, отримайте токен ServiceAccount і використовуйте його з цього сервісу.

Інструкції дивіться в розділі Налаштування ServiceAccount для Podʼів.

Надання дозволів ServiceAccount

Ви можете використовувати вбудований у Kubernetes механізм контролю доступу на основі ролей (RBAC), щоб надавати кожному ServiceAccount мінімально потрібні дозволи. Ви створюєте роль, яка надає доступ, а потім привʼязуєте її до свого ServiceAccount. RBAC дозволяє визначити мінімальний набір дозволів, щоб дозволи ServiceAccount відповідали принципу найменших привілеїв. Podʼи, що використовують цей ServiceAccount, не отримують більше дозволів, ніж потрібно для правильної роботи.

Інструкції дивіться в розділі Дозволи ServiceAccount.

Доступ між просторами імен за допомогою ServiceAccount

За допомогою RBAC можна дозволити ServiceAccount в одному просторі імен виконувати дії з ресурсами в іншому просторі імен кластера. Наприклад, у вас є ServiceAccount і Pod у просторі імен dev, і ви хочете, щоб ваш Pod бачив Jobs, що виконуються в просторі імен maintenance. Ви можете створити обʼєкт Role, який надає дозволи на перелік обʼєктів Job. Потім створіть обʼєкт RoleBinding у просторі імен maintenance, щоб привʼязати Role до обʼєкта ServiceAccount. Тепер Podʼи у просторі імен dev можуть отримувати перелік обʼєктів Job у просторі імен maintenance, використовуючи цей ServiceAccount.

Призначення ServiceAccount Podʼу

Щоб призначити ServiceAccount Podʼу, встановіть поле spec.serviceAccountName у специфікації Podʼа. Після цього Kubernetes автоматично надає Podʼу облікові дані цього ServiceAccount. У v1.22 і новіших Kubernetes отримує короткостроковий токен з автоматичною ротацією через API TokenRequest і монтує його як проєкційний том.

Стандартно Kubernetes надає Podʼу облікові дані призначеного ServiceAccount, будь то ServiceAccount default чи вказаний вами власний ServiceAccount.

Щоб Kubernetes не додавав автоматично облікові дані вказаного ServiceAccount або ServiceAccount default, встановіть поле automountServiceAccountToken у специфікації Podʼа в false.

У версіях до 1.22 Kubernetes надає Podʼу довгостроковий статичний токен як Secret.

Отримання облікових даних ServiceAccount вручну

Якщо облікові дані ServiceAccount потрібно змонтувати в нестандартне місце або вони потрібні для аудиторії, відмінної від API-сервера, скористайтеся одним із таких методів:

• TokenRequest API (рекомендовано): Запитуйте короткостроковий токен ServiceAccount безпосередньо з коду вашого застосунку. Строк дії токена спливає автоматично, і після цього токен можна ротувати. Якщо у вас є застарілий застосунок, який не знає про Kubernetes, ви можете використати sidecar-контейнер у тому самому Podʼі, щоб отримувати ці токени й надавати їх робочому навантаженню застосунку.
• Token Volume Projection (також рекомендовано): У Kubernetes v1.20 і новіших вкажіть у специфікації Podʼа, щоб kubelet додав токен ServiceAccount до Podʼа як проєкційний том. Строк дії спроєцьованих токенів спливає автоматично, а kubelet ротує токен до завершення строку дії.
• Service Account Token Secrets (не рекомендовано): Ви можете монтувати токени ServiceAccount як Secrets Kubernetes у Podʼах. Ці токени не мають строку дії й не ротуються. У версіях до v1.24 для кожного ServiceAccount автоматично створювався постійний токен. Цей метод більше не рекомендується, особливо у великому масштабі, через ризики, повʼязані зі статичними довгостроковими обліковими даними. Функціональна можливість LegacyServiceAccountTokenNoAutoGeneration (стандартно ввімкнена в Kubernetes з v1.24 до v1.26) не давала Kubernetes автоматично створювати ці токени для ServiceAccount. Її вилучено у v1.27, оскільки вона перейшла на стадію GA; ви все ще можете вручну створювати безстрокові токени ServiceAccount, але маєте враховувати наслідки для безпеки.

Обмеження аудиторій вузлів для токенів ServiceAccount

Коли ввімкнено функціональну можливість ServiceAccountNodeAudienceRestriction, втулок допуску NodeRestriction обмежує аудиторії, які kubelet може запитувати під час створення токенів ServiceAccount через API TokenRequest. Стандартно kubelet може запитувати токени лише для аудиторій, на які вже посилаються Podʼи на цьому вузлі (через проєкційні томи токенів ServiceAccount або запити токенів драйвера CSI). Адміністратори можуть надати kubelet доступ до додаткових аудиторій за допомогою правил RBAC із дієсловом request-serviceaccounts-token-audience.

Це обмеження застосовується лише до kubelet (ідентичностей вузлів) і не впливає на інших клієнтів API TokenRequest. Подробиці та приклади RBAC дивіться в розділі Обмеження аудиторії токенів ServiceAccount.

Обмеження доступу до Secrets (застаріло)

Kubernetes надає анотацію kubernetes.io/enforce-mountable-secrets, яку можна додати до ваших ServiceAccounts. Коли цю анотацію застосовано, Secrets цього ServiceAccount можна монтувати лише на вказані типи ресурсів, що покращує безпеку кластера.

Ви можете додати анотацію до ServiceAccount за допомогою маніфесту:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubernetes.io/enforce-mountable-secrets: "true"
  name: my-serviceaccount
  namespace: my-namespace

Коли цю анотацію встановлено в "true", панель управління Kubernetes гарантує, що на Secrets цього ServiceAccount поширюються певні обмеження монтування.

1. Назва кожного Secret, змонтованого як том у Podʼі, має бути в полі secrets ServiceAccount цього Podʼа.
2. Назва кожного Secret, на який посилається envFrom у Podʼі, також має бути в полі secrets ServiceAccount цього Podʼа.
3. Назва кожного Secret, на який посилається imagePullSecrets у Podʼі, також має бути в полі secrets ServiceAccount цього Podʼа.

Розуміючи та застосовуючи ці обмеження, адміністратори кластера можуть посилити захист і забезпечити доступ до Secrets лише для відповідних ресурсів.

Автентифікація облікових даних ServiceAccount

ServiceAccounts використовують підписані JSON Web Tokens (JWT) для автентифікації на API-сервері Kubernetes та в будь-якій іншій системі, де є довірчі стосунки. Залежно від того, як видано токен (обмежений у часі через TokenRequest чи застарілим механізмом із Secret), токен ServiceAccount може також мати час завершення дії, аудиторію та час, з якого токен починає діяти. Коли клієнт, що діє як ServiceAccount, звертається до API-сервера Kubernetes, він додає до HTTP-запиту заголовок Authorization: Bearer <token>. API-сервер перевіряє чинність цього токена так:

1. Перевіряє підпис токена.
2. Перевіряє, чи не закінчився строк дії токена.
3. Перевіряє, чи чинні наразі посилання на обʼєкти в твердженнях токена.
4. Перевіряє, чи чинний наразі токен.
5. Перевіряє твердження про аудиторію.

TokenRequest API створює привʼязані токени для ServiceAccount. Ця привʼязка повʼязана з часом життя клієнта, такого як Pod, що діє як цей ServiceAccount. Приклад схеми JWT та вмісту привʼязаного токена ServiceAccount Podʼа дивіться в розділі Token Volume Projection.

Для токенів, виданих через API TokenRequest, API-сервер також перевіряє, що обʼєкт, який використовує ServiceAccount, все ще існує, зіставляючи його за унікальним ідентифікатором. Для застарілих токенів, змонтованих як Secrets у Podʼах, API-сервер звіряє токен із Secret.

Докладніше про процес автентифікації дивіться в розділі Автентифікація.

Автентифікація облікових даних ServiceAccount у власному коді

Якщо у вас є власні сервіси, яким потрібно перевіряти облікові дані ServiceAccount Kubernetes, можна скористатися такими методами:

• TokenReview API (рекомендовано)
• Виявлення OIDC

Проєкт Kubernetes рекомендує використовувати TokenReview API, оскільки цей метод анулює токени, привʼязані до обʼєктів API, таких як Secrets, ServiceAccounts, Podʼи або вузли, коли ці обʼєкти видаляються. Наприклад, якщо ви видалите Pod, що містить спроєцьований токен ServiceAccount, кластер негайно анулює цей токен, і TokenReview одразу завершиться невдачею. Якщо натомість використовувати перевірку OIDC, ваші клієнти й надалі вважатимуть токен дійсним, доки не настане час завершення його дії.

Ваш застосунок завжди має визначати аудиторію, яку він приймає, і перевіряти, що аудиторії токена відповідають очікуваним. Це допомагає звузити область дії токена, щоб його можна було використовувати лише у вашому застосунку й ніде більше.

Альтернативи

• Видавайте власні токени за допомогою іншого механізму, а потім використовуйте автентифікацію за токеном через вебхук, щоб перевіряти токени-предʼявники власним сервісом перевірки.
• Надавайте власні ідентичності Podʼам.

  • Використовуйте втулок драйвера SPIFFE CSI, щоб надавати Podʼам SPIFFE SVID як пари сертифікатів X.509.

    🛇 Цей елемент посилається на сторонній проєкт або продукт, який не є частиною Kubernetes. Докладніше

  • Використовуйте service mesh, такий як Istio, щоб надавати сертифікати Podʼам.

• Автентифікуйтеся ззовні кластера на API-сервері без токенів ServiceAccount:
  • Налаштуйте API-сервер для прийняття токенів OpenID Connect (OIDC) від вашого постачальника ідентифікації.
  • Використовуйте ServiceAccount або облікові записи користувачів, створені у зовнішньому сервісі керування ідентичністю та доступом (IAM), наприклад у хмарного провайдера, для автентифікації у вашому кластері.
  • Використовуйте API CertificateSigningRequest із клієнтськими сертифікатами.
• Налаштуйте kubelet для отримання облікових даних з реєстру образів.
• Використовуйте втулок пристроїв, щоб отримати доступ до віртуального Trusted Platform Module (TPM), який дозволяє автентифікуватися за допомогою приватного ключа.

Що далі

• Дізнайтеся, як керувати ServiceAccounts як адміністратор кластера.
• Дізнайтеся, як призначити ServiceAccount Podʼу.
• Прочитайте довідку API ServiceAccount.