Kubernetes v1.33: Аутентифікація завантаження образів за допомогою токенів сервісного облікового запису

Kubernetes продовжує свій шлях до епhemeral безпеки, заснованої на ідентичності. У версії v1.33 платформа усуває важливу прогалину в аутентифікації робочих навантажень, інтегруючи токени облікових записів служб (Service Account Tokens) у фреймворк постачальників облікових даних kubelet. Це нововведення виключає статичні imagePullSecrets і забезпечує аутентифікацію, що відповідає OIDC, для доступу до контейнерних реєстрів на рівні кожного пода.

Передумови: Від статичних секретів до ідентичності робочих навантажень

Історично, робочі навантаження Kubernetes, які завантажували образи з приватних реєстрів, покладалися на довгострокові imagePullSecrets, що зберігалися на API-сервері. Ці облікові дані були:

• Статичними JSON або .dockerconfigjson об’єктами без вбудованої ротації.
• Обмеженими або до облікового запису служби, або явно змонтованими в кожній специфікації пода.
• Вразливими до компрометації кластера у випадку неналежного управління або витоку.

З появою підтримки OIDC у ServiceAccountTokenProjection у версії v1.21 та API TokenRequest, Kubernetes почав видавати короткоживучі JWT токени для аутентифікації в кластері. Тепер версія v1.33 розширює цю роботу на завантаження образів, узгоджуючи доступ до реєстру з сучасними практиками управління ідентичністю та доступом.

Проблема зі статичними секретами для завантаження образів

1. API-підтримувані imagePullSecrets

   • Довгий термін дії за замовчуванням (часто місяці або роки).
   • Ручна ротація є складною та схильною до помилок.
   • Компрометація надає доступ до реєстру на рівні всього кластера.

2. Кредитні провайдери на рівні вузлів kubelet

   • Отримують облікові дані через exec плагіни (наприклад, AWS ECR, GCR, ACR).
   • Усі поди на вузлі ділять один і той же токен або IAM роль.
   • Відсутня ізоляція на рівні пода; порушує принципи найменших привілеїв.

Жодна з цих моделей не відповідає маніфесту Zero Trust CNCF про найменші привілеї та епhemeral токени. Це залишає кластери вразливими до бічного переміщення у разі порушення безпеки.

Рішення: Інтеграція токенів облікових записів служб для провайдерів облікових даних kubelet

Функція ServiceAccountTokenForKubeletCredentialProviders, яка знаходиться на етапі альфа в v1.33, дозволяє kubelet впроваджувати JWT, специфічний для пода, у запит CredentialProviderRequest. Провайдери облікових даних, налаштовані через блок credentialProviders у kubelet, можуть підключитися для отримання цих токенів і обмінювати їх на короткоживучі облікові дані, обмежені реєстром.

• Ідентичність, специфічна для пода: Кожен JWT генерується для облікового запису служби певного пода, з налаштуваннями аудиторії, адаптованими до плагіна реєстру.
• Автоматична ротація: Токени мають термін дії за замовчуванням 15 хвилин з буфером для поновлення в 5 хвилин, що налаштовується через KEP.
• Семантика OIDC: Відповідає JWT C RFC 7519 і використовує API TokenRequest Kubernetes для внутрішніх процесів.

Як це працює

1. Проекція токена та запит

Коли credentialProviders увімкнено, kubelet видає TokenRequest для облікового запису служби пода, зазначаючи:

• audience: Унікальний ідентифікатор плагіна облікових даних (наприклад, sts.amazonaws.com для AWS ECR).
• expirationSeconds: Бажаний термін дії токена (за замовчуванням 900 секунд).

Отриманий JWT включається в корисне навантаження CredentialProviderRequest, яке передається до exec плагіна через stdin.

2. Обмін плагінів та завантаження з реєстру

• Exec плагін перевіряє JWT (перевіряючи iss, aud, exp вимоги) і обмінює його на кінцевій точці STS реєстру.
• Реєстр (наприклад, AWS STS, GCP IAM Credentials API, Azure Managed Identities) видає епhemeral облікові дані, обмежені дозволами пода.
• Kubelet використовує ці короткоживучі облікові дані для завантаження образів, кешуючи їх на рівні пода до закінчення терміну дії.

Основні переваги

• Безпека: Виключає статичні секрети; зменшує зону ураження у випадках компрометації.
• Гранульований контроль доступу: Забезпечує дотримання IAM/RBAC політик для кожного пода на рівні реєстру.
• Операційна простота: Відсутність ручної ротації секретів — kubelet автоматично обробляє поновлення токенів.
• Відповідність: Відповідає вимогам організацій щодо уникнення постійних облікових даних у кластері.

Розгляд продуктивності та масштабованості

Попередні тести від SIG-Node показали затримку менше 10 мс на кожен TokenRequest для кластерів до 5000 вузлів. Кешуючі шари в exec плагінах можуть додатково зменшити затримку мережі. У планах на майбутню версію v1.34 — централізований кеш токенів на вузлі, що зменшить повторні запити, коли кілька подів використовують один і той же обліковий запис служби та конфігурацію плагіна реєстру.

Інтеграція з IAM постачальників хмари

Основні постачальники хмари вже тестують цю альфа-функцію:

• Amazon EKS: AWS опублікував попередню версію свого провайдера облікових даних ECR (v0.6.0+) з явною підтримкою ServiceAccountTokenForKubeletCredentialProviders.
• Google GKE: Плагін GCP Artifact Registry знаходиться на етапі приватної альфи, використовуючи федерацію Workload Identity для генерації STS токенів.
• Azure AKS: Підтримка ACR через Managed Identities планується в рамках KEP-4053.

Дорожня карта та наступні кроки

Ця функція запланована на бета в Kubernetes v1.34, і спільнота зосередиться на:

• Впровадженні налаштовуваних TTL кешу токенів у kubelet для балансування свіжості та продуктивності.
• Покращенні сумісності Ensure Secret Pulled Images (KEP-2535) для перевірки доступу до образів пода після їх завантаження.
• Розширенні SDK exec плагінів з допоміжними бібліотеками для парсингу та перевірки проекційних токенів.

Спробуйте це

1. Встановіть Kubernetes v1.33+ та увімкніть ServiceAccountTokenForKubeletCredentialProviders на kubelet.
2. Розгорніть або оновіть плагін провайдера облікових даних (наприклад, ecr-credential-provider v0.6.0+).
3. Налаштуйте credentialProviders у конфігурації kubelet YAML, включаючи tokenAttributes для вашого реєстру.
4. Створіть тестове простір імен з обліковим записом служби, прив’язаним до мінімальних IAM ролей.
5. Розгорніть под, використовуючи цей обліковий запис служби, і перевірте завантаження образів у логах kubelet.

Як долучитися

Ми запрошуємо до співпраці та зворотного зв’язку від спільноти. Приєднуйтесь до каналів SIG-Auth та SIG-Node:

• #sig-auth-authenticators-dev: Обговорення API TokenRequest та KEP-4412.
• #sig-node: Обмін показниками продуктивності, реалізаціями плагінів та досвідом операторів.

Беріть участь у наших двотижневих зустрічах SIG або подавайте запити на виправлення та пулл-реквести на репозиторіях Kubernetes GitHub.

Джерело: Kubernetes Blog