Аутентификация реестра изображений изменена с помощью токена служебной учетной записи (отчет стажера)

Введение

Здравствуйте, я Хироки Ватанабэ, студент третьего курса факультета информатики Университета Цукуба. Я работал стажером во внутренней команде разработчиков Kubernetes в качестве службы в течение 4 недель, начиная с 1 сентября 2025 года. За время своего пребывания там я внедрил систему аутентификации для безопасного и автоматического получения частных образов контейнеров, хранящихся в реестре контейнеров компании. Ключевым моментом этой реализации является то, что она использует функцию KubeletServiceAccountTokenForCredentialProviders, которая была представлена как бета-функция в Kubernetes v1.34. Эта новая функция позволяет kubelet отправлять токен ServiceAccount, связанный с Pod, в плагин Credential Provider при получении изображения, обеспечивая более безопасную аутентификацию изображения с использованием Workload Identity. В этой статье мы кратко объясним реализацию уникальной инфраструктуры аутентификации LINE Yahoo, представим механизм самого поставщика учетных данных изображения и представим примеры реализации в реестре Amazon Elastic Container Registry, Google Cloud Artifact Registry, Azure Container Registry и т. д., чтобы вы могли понять ценность распространенных поставщиков учетных данных изображений.

Как получить частные изображения

Проблемы с аутентификацией частного изображения

В Kubernetes постоянно вносятся функциональные улучшения для повышения безопасности и работоспособности метода аутентификации при использовании приватных образов контейнеров.

Самый простой метод — хранить учетные данные в секрете Kubernetes.imagePullSecretsЭто форма ссылки. Этот метод легко реализовать, поскольку его можно реализовать, используя только стандартные функции Kubernetes, но токен статичен и постоянно хранится внутри кластера, что представляет высокий риск для безопасности. Ротация токенов также осуществляется вручную, поэтому необходимо каждый раз обновлять секрет до истечения срока его действия.

Поставщик учетных данных изображения был представлен в Kubernetes v1.20 для решения этой проблемы. С помощью этого механизма информация аутентификации может быть получена динамически извне при извлечении изображения, что обеспечивает автоматическую ротацию токенов и снижает операционную нагрузку. Однако, поскольку он полагается на роли IAM и ключи учетной записи службы для каждого узла, сложно предоставить подробные разрешения каждому поду, и проблема в том, что все поды разделяют разрешения, назначенные узлу.

Кроме того, KubeletServiceAccountTokenForCredentialProviders, добавленный в качестве альфа-функции в Kubernetes v1.33 и бета-функции в v1.34, позволяет передавать токены ServiceAccount в подключаемый модуль Credential Provider. Это позволяет предоставлять детальные разрешения на основе ServiceAccount, а информацию аутентификации теперь можно получать с использованием удостоверения на основе Pod (рабочей нагрузки), реализуя принцип наименьших привилегий и повышая безопасность.

Сведения о поставщике учетных данных изображения

Основные понятия

Поставщик учетных данных изображенияРасширения Kubelet представлены как функции Alpha в Kubernetes v1.20является.

Эта функция представляет собой механизм, который делегирует получение аутентификационной информации при получении образа контейнера внешней программе (плагину). Когда kubelet инструктирует среду выполнения контейнера получить образ, он при необходимости вызывает внешние плагины с помощью exec и обменивается информацией аутентификации через stdin/stdout. Благодаря динамическому получению токенов извлечения изображений вместо статического управления информацией аутентификации с использованием обычных секретов извлечения изображений, которые реализуются с помощью механизма извлечения изображений Docker, можно использовать кратковременные токены, что позволяет добиться более безопасной и автоматизированной аутентификации. В качестве примечания: Image Pull Secrets может хранить учетные данные в таких вещах, как секреты Kubernetes, что упрощает развертывание в работающем кластере Kubernetes. С другой стороны, Image Credential Provider имеет механизм, в котором кубелет в каждом узле получает кратковременный токен при извлечении образа, поэтому его нельзя установить как манифест Kubernetes, и необходимо установить двоичный файл Image Credential Provider на каждом узле и изменить аргументы запуска kubelet, поэтому его недостаток заключается в том, что его несколько сложно установить.

Сравнение с традиционными методами аутентификации

Традиционные секреты создания имиджа

apiVersion: v1
kind: Secret
metadata:
  name: registry-secret
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: 
---
apiVersion: v1
kind: Pod
spec:
  imagePullSecrets:
  - name: registry-secret

назначение

В описанном выше методе, использующем секреты Kubernetes, информация аутентификации статически хранится в кластере. Поэтому было сложно менять токен после его установки, поэтому приходилось вручную обновлять секрет до истечения срока его действия. Кроме того, при доступе к нескольким реестрам необходимо размещать и управлять секретами для каждого пространства имен и ServiceAccount, что усложняет операции. Более того, поскольку не существует механизма ротации на основе дат истечения срока действия или механизма проверки действительности установленных токенов, вы обычно имеете дело с учетными данными, действительными в течение длительного периода времени, что увеличивает риск утечек.

Динамическая аутентификация с помощью поставщика учетных данных изображения

apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
- name: "my-credential-provider"
  matchImages:
  - "*.example.com"
  defaultCacheDuration: "12h"

преимущество

При использовании поставщика учетных данных изображения kubelet будет вызывать внешний плагин для динамического получения учетных данных при выполнении запроса на извлечение изображения, соответствующего приведенной выше конфигурации. Это обеспечивает следующие преимущества:

• Динамическое получение учетных данных: информация аутентификации динамически получается извне во время получения образа, поэтому ее можно использовать без постоянного хранения в кластере Kubernetes.
• Автоматическая ротация токенов: срок действия токена установлен короткий, он автоматически обновляется и получается, поэтому нет необходимости в замене на стороне пользователя.
• Интеграция с ролями IAM и учетными записями служб.: это тот случай, когда облачный провайдер реализует интеграцию IAM и Kubernetes ServiceAccount, но поскольку KubeletServiceAccountTokenForCredentialProviders позволяет предоставлять токен Kubernetes ServiceAccount поставщику учетных данных, вы можете использовать функции Kubernetes для реализации детального контроля доступа и временной авторизации.
• Упрощенная поддержка нескольких реестров: путем сопоставления шаблонов в настройках плагина вы можете использовать согласованный механизм для поддержки нескольких типов аутентификации реестра, таких как AWS (веб-службы Amazon), GCP (облачная платформа Google), Microsoft Azure и локально.

Как работает реализация

Существует общий шаблон реализации поставщиков учетных данных изображений. kubelet включает необходимую информацию запроса (имя изображения и т. д.) для плагина.CredentialProviderRequestЗаписывает объект в стандартный ввод в формате JSON. Плагин считывает запрос со стандартного ввода и выполняет все необходимые процессы аутентификации внутри себя (например, вызов облачных служб метаданных или API IAM). Если плагин успешно аутентифицируется,CredentialProviderResponseВыводит объект (включая информацию аутентификации) на стандартный вывод в формате JSON. Kubelet получает ответ от стандартного вывода и использует полученные учетные данные, чтобы дать команду среде выполнения контейнера извлечь образ.

Пример запроса (JSON), полученного плагином:

{
  "apiVersion": "credentialprovider.kubelet.k8s.io/v1",
  "kind": "CredentialProviderRequest",
  "image": "registry.example.com/my-project/my-image:latest",
  "serviceAccountToken": "",
  "serviceAccountAnnotations": {"example.com/iam-service-account": "<サービスアカウント名など>"}
}

Пример ответа (JSON), который плагин возвращает в kubelet:

{
  "apiVersion": "credentialprovider.kubelet.k8s.io/v1",
  "kind": "CredentialProviderResponse",
  "cacheKeyType": "Registry",
  "cacheDuration": "1h",
  "auth": {
    "registry.example.com": {
      "username": "oauth2accesstoken",
      "password": ""
    }
  }
}

В приведенном вышеregistry.example.com Содержит информацию аутентификации (токен имени пользователя и пароля) для домена.cacheKeyType: "Registry"означает, что эти учетные данные кэшируются для каждого реестра (повторное использование учетных данных в разных образах в одном и том же реестре).cacheDurationуказывает, как долго эти учетные данные кэшируются, в примере это 1 час.

Начиная с версии Kubernetes 1.26, функция поставщика учетных данных стала GA (общая доступность), и указанный выше формат запроса/ответа теперь доступен как стабильная версия. KubeletServiceAccountTokenForCredentialProviders — это расширение поставщика учетных данных.serviceAccountToken、serviceAccountAnnotationsПоле добавлено. Просто следуя этому формату запроса/ответа, вы можете реализовать плагин аутентификации, не внося никаких изменений в Kubernetes.

KubeletServiceAccountTokenForCredentialProviders

Подробности о новых функциях

Он был добавлен в Kubernetes v1.33 как альфа-функция, которую можно включить с помощью опции Feature Gate, а в Kubernetes v1.34 он стал бета-функцией и включен по умолчанию. Это дальнейшее развитие описанной выше функциональности поставщика учетных данных изображения. Раньше мы полагались на роли IAM на основе узлов и ключи сервисных учетных записей, но с добавлением этой функции теперь можно получать данные аутентификации, используя удостоверения на основе модулей.

• Плагин использует роль IAM, назначенную узлу Image Credential Provider (Kubernetes v1.20+), и долгосрочный ключ учетной записи службы для получения токена из облачного API. Каждому узлу требуется удостоверение с определенными привилегиями, которые тесно связаны с управлением привилегиями за пределами кластера.