Облікові записи служб

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

Що таке облікові записи служб?

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

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

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

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

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

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

Стандартні облікові записи служб

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

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

Використання сервісних облікових записів Kubernetes

Загалом, ви можете використовувати сервісні облікові записи для надання ідентичності в таких сценаріях:

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

Як використовувати сервісні облікові записи

Щоб скористатися сервісним обліковим записом Kubernetes, виконайте наступне:

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

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

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

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

Щоб дізнатися, як це зробити, перегляньте Налаштування сервісних облікових записів для Podʼів.

Надання дозволів обліковому запису ServiceAccount

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

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

Крос-простірний доступ за допомогою облікового запису ServiceAccount

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

Додавання ServiceAccount для Pod

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

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

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

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

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

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

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

Обмеження доступу до Secret

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

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

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 доступні лише відповідним ресурсам.

Автентифікація облікових записів служби

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Використовуйте сервісний механізм, такий як Istio, для надання сертифікатів Podʼів.

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

Що далі

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