Kubernetes v1.34: Інтеграція токенів службових облікових записів для витягування образів контейнерів переходить у стадію бета

Автор: Anish Ramasekar (Microsoft) | Перекладач(і): Андрій Головін | 03.09.2025

Спільнота Kubernetes продовжує вдосконалювати найкращі практики безпеки, зменшуючи залежність від довготривалих облікових даних. Після успішного випуску альфа-версії в Kubernetes v1.33, Інтеграція токенів службових облікових записів для постачальників облікових даних Kubelet перейшла на бета-версію в Kubernetes v1.34, що наблизило нас до усунення довготривалих секретів витягування образів контейнерів із кластерів Kubernetes.

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

Що нового в бета-версії?

Перехід у бета-версію приносить кілька важливих змін, які роблять цю функцію більш надійною та готовою до промислової експлуатації:

Обовʼязкове поле `cacheType`

Істотна зміна порівняно з альфа-версією: поле cacheType є обовʼязковим у конфігурації постачальника облікових даних під час використання токенів службового облікового запису. Це поле є новим у бета-версії і має бути вказане для забезпечення належного функціонування кешування.

# УВАГА: це не повний приклад конфігурації, а лише посилання на поле 'tokenAttributes.cacheType'.
tokenAttributes:
  serviceAccountTokenAudience: "my-registry-audience"
  cacheType: "ServiceAccount"  # Required field in beta
  requireServiceAccount: true

Обирайте поміж двома стратегіями кешування:

Token: Робіть кешування облікових даних для кожного токена службового облікового запису (використовуйте, коли термін дії облікових даних повʼязаний із токеном). Це корисно, коли постачальник облікових даних перетворює токен службового облікового запису на облікові дані реєстру з таким же терміном дії, як і токен, або коли реєстри безпосередньо підтримують токени службових облікових записів Kubernetes. Примітка: Kubelet не може безпосередньо надсилати токени службових облікових записів до реєстрів; для перетворення токенів у формат імені користувача/пароля, очікуваний реєстрами, потрібні втулки постачальників облікових даних.
ServiceAccount: Кешуйте облікові дані для кожної ідентичності службового облікового запису (використовуйте, коли облікові дані дійсні для всіх подів, які використовують один і той же службовий обліковий запис)

Ізольовані облікові дані для витягування образів

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

Коли постачальники облікових даних використовують токени службових облікових записів, система відстежує ідентичність службового облікового запису (простір імен, імʼя та UID) для кожного витягнутого образу. Коли под намагається використовувати кешований образ, система перевіряє, що службовий обліковий запис пода точно збігається з службовим обліковим записом, який був використаний для початкового витягування образу.

Адміністратори можуть відкликати доступ до раніше витягнутих образів, видаливши та створивши наново ServiceAccount, що змінює UID і робить недоступним кешований доступ до образів.

Для отримання додаткової інформації про цю можливість дивіться документацію перевірки облікових даних для витягування образів.

Як це працює

Конфігурація

Постачальники облікових даних використовують токени службових облікових записів за допомогою поля tokenAttributes:

#
# УВАГА: це не повний приклад конфігурації, а лише посилання на поле 'tokenAttributes'.
#
apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
- name: my-credential-provider
  matchImages:
  - "*.myregistry.io/*"
  defaultCacheDuration: "10m"
  apiVersion: credentialprovider.kubelet.k8s.io/v1
  tokenAttributes:
    serviceAccountTokenAudience: "my-registry-audience"
    cacheType: "ServiceAccount"  # New in beta
    requireServiceAccount: true
    requiredServiceAccountAnnotationKeys:
    - "myregistry.io/identity-id"
    optionalServiceAccountAnnotationKeys:
    - "myregistry.io/optional-annotation"

Порядок отримання образів

На високому рівні, kubelet координує свою роботу з постачальником облікових даних та середовищем виконання контейнерів наступним чином:

Коли образ відсутній локально:
- kubelet перевіряє свій кеш облікових даних, використовуючи налаштований cacheType (Token або ServiceAccount)
- Якщо потрібно, kubelet запитує токен ServiceAccount для ServiceAccount пода і передає його, а також будь-які необхідні анотації, постачальнику облікових даних
- Постачальник обмінює цей токен на облікові дані реєстру і повертає їх kubelet
- kubelet кешує облікові дані відповідно до стратегії cacheType і витягує образ з цими обліковими даними
- kubelet записує координати ServiceAccount (простір імен, імʼя, UID) повʼязані з витягнутим образом для подальших перевірок авторизації
Коли образ вже присутній локально:
- kubelet перевіряє координати ServiceAccount пода на відповідність обліковим даним, записаним для кешованого образу
- Якщо вони точно збігаються, можна використовувати кешований образ без витягування з реєстру
- Якщо вони відрізняються, kubelet виконує нове витягування з використанням облікових даних для нового ServiceAccount
З увімкненою перевіркою облікових даних для витягування образів:
- Авторизація виконується з використанням записаних облікових даних ServiceAccount, що забезпечує використання подами лише образів, витягнутих за допомогою ServiceAccount, до яких вони мають право доступу
- Адміністратори можуть відкликати доступ, видаливши та створивши наново ServiceAccount; UID змінюється, і раніше записана авторизація більше не збігається

Обмеження аудиторії

Бета-реліз базується на обмеженнях аудиторії вузлів службових облікових записів (бета з v1.33), щоб забезпечити можливість kubelet запитувати токени лише для авторизованих аудиторій. Адміністратори налаштовують дозволені аудиторії за допомогою RBAC, щоб дозволити kubelet запитувати токени службових облікових записів для витягування образів:

#
# УВАГА: це лише приклад конфігурації.
#          Не використовуйте це для свого кластера!
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubelet-credential-provider-audiences
rules:
- verbs: ["request-serviceaccounts-token-audience"]
  apiGroups: [""]
  resources: ["my-registry-audience"]
  resourceNames: ["registry-access-sa"]  # Опціонально: конкретний SA

Початок роботи з бета-версією

Необхідні умови

Kubernetes v1.34 або пізніше
Увімкнено функціональні можливості: KubeletServiceAccountTokenForCredentialProviders=true (бета, стандартно увімкнено)
Підтримка постачальника облікових даних: Update your credential provider to handle ServiceAccount tokens

Міграція з альфа-версії

У випадку, якщо ви вже використовуєте альфа-версію, міграція на бета-версію вимагає мінімальних змін:

Додайте поле cacheType: Оновіть конфігурацію вашого постачальника облікових даних, щоб включити необхідне поле cacheType
Перегляньте стратегію кешування: Виберіть між типами кешу Token і ServiceAccount на основі поведінки вашого постачальника
Перевірте обмеження аудиторії: Переконайтеся, що ваша конфігурація RBAC або інші правила авторизації кластера правильно обмежують аудиторії токенів

Приклад налаштування

Ось повний приклад налаштування постачальника облікових даних з токенами службових облікових записів (цей приклад передбачає, що ваш кластер використовує авторизацію RBAC):

#
# УВАГА: це лише приклад конфігурації.
#          Не використовуйте це для свого кластера!
#

# Service Account з анотаціями реєстру
apiVersion: v1
kind: ServiceAccount
metadata:
  name: registry-access-sa
  namespace: default
  annotations:
    myregistry.io/identity-id: "user123"
---
# RBAC для обмеження аудиторії
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: registry-audience-access
rules:
- verbs: ["request-serviceaccounts-token-audience"]
  apiGroups: [""]
  resources: ["my-registry-audience"]
  resourceNames: ["registry-access-sa"]  # Опціонально: конкретний ServiceAccount
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubelet-registry-audience
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: registry-audience-access
subjects:
- kind: Group
  name: system:nodes
  apiGroup: rbac.authorization.k8s.io
---
# Pod що використовує ServiceAccount
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: registry-access-sa
  containers:
  - name: my-app
    image: myregistry.example/my-app:latest

Що далі?

Для Kubernetes v1.35 ми, Kubernetes SIG Auth, очікуємо, що функція залишиться в бета-версії, і ми будемо продовжувати збирати відгуки.

Ви можете дізнатися більше про цю функцію на сторінці токена службового облікового запису для витягування зображень в документації Kubernetes.

Ви також можете стежити за KEP-4412, щоб відстежувати прогрес у майбутніх випусках Kubernetes.

Дійте

У цьому блозі ми висвітлили бета-випуск інтеграції токенів службових облікових записів для Kubelet Credential Providers в Kubernetes v1.34. Ми розглянули ключові поліпшення, включаючи необхідне поле cacheType та вдосконалену інтеграцію з Ensure Secret Pull Images.

Ми отримали позитивні відгуки від спільноти під час альфа-фази і хотіли б почути більше, оскільки ми стабілізуємо цю функцію для GA. Зокрема, ми хотіли б отримати відгуки від розробників постачальників облікових даних під час інтеграції з новим бета-API та механізмами кешування. Будь ласка, звʼяжіться з нами в каналі #sig-auth-authenticators-dev на Kubernetes Slack.

Як взяти участь

Якщо ви зацікавлені в участі в розробці цієї функції, поділіться відгуками або візьміть участь в інших поточних проектах SIG Auth, будь ласка, зв'яжіться з нами в каналі #sig-auth на Kubernetes Slack.

Ви також можете приєднатися до двотижневих зборів SIG Auth, які проходять кожну другу середу.