В облачном приложении поды должны читать объектное хранилище без хранения ключей в образе. Как механизм workload identity связывает под с правами облачного IAM?
Workload identity связывает под с облачной IAM-ролью через удостоверение его рабочей идентичности, а не через статический ключ. Под получает краткоживущий токен, облачный провайдер проверяет его издателя, аудиторию и принадлежность к разрешённой идентичности, после чего выдаёт временные учётные данные с правами назначенной роли.
Раньше приложения часто хранили ключи облачного API в образах, переменных окружения или секретах кластера. Это создавало риск утечки, усложняло ротацию и нередко приводило к чрезмерно широким правам.
Workload identity появился как способ перенести аутентификацию с долгоживущего секрета на удостоверение самого рабочего экземпляра. Приложению больше не нужно знать постоянный ключ: оно получает временные права только на период работы и только для конкретной роли.
Подам нужно разрешить доступ к объектному хранилищу, но нельзя выдавать всем экземплярам один общий ключ. Если ключ попадёт в образ или будет доступен процессам с чрезмерными правами, компрометация одного приложения может открыть доступ к множеству ресурсов.
Дополнительная сложность состоит в том, что идентичность Kubernetes-пода и идентичность облачного IAM — разные сущности. Их нужно безопасно связать, не основываясь только на изменяемом IP-адресе пода или имени узла.
Обычно под запускается с сервисной идентичностью кластера. Оркестратор выдаёт ему подписанный токен, содержащий сведения о субъекте, например сервисном аккаунте, пространстве имён и кластере. Токен имеет ограниченный срок действия и предназначен для конкретной аудитории.
Облачный провайдер принимает этот токен через механизм федерации, например обмен токена на временные учётные данные через службу безопасности. Он проверяет подпись, доверенного издателя, аудиторию, срок действия и условия доверительной политики. Затем провайдер сопоставляет субъект токена с конкретной IAM-ролью и выдаёт временный доступ.
Приложение использует эти временные данные при обращении к объектному хранилищу. Обычно SDK автоматически обновляет их до истечения срока действия, поэтому приложение не управляет постоянным секретом.
Безопасность зависит от точности доверительной политики. Она должна ограничивать как минимум издателя токена, аудиторию, кластер или идентичность, пространство имён и сервисный аккаунт. Нельзя разрешать роль всей группе подов, если доступ нужен только одному сервису.
Механизм не отменяет принцип минимальных привилегий: IAM-роль должна разрешать только нужные операции и ресурсы. Также остаются риски компрометации самого пода: злоумышленник может использовать временные учётные данные до их истечения, если получит доступ к процессу или окружению.
Важное ограничение — зависимость от корректной настройки федерации и времени. Неверная аудитория, просроченный токен, рассинхронизация часов или ошибочная политика доверия приводят к отказу в доступе. Для отказоустойчивости нужно учитывать доступность службы выдачи временных учётных данных и разумно обрабатывать обновление токенов.
Сервис обработки изображений в Kubernetes должен читать входные файлы из одного контейнера объектного хранилища и записывать результаты в другой. Вариант с общим ключом в секрете был простым, но давал одинаковые права всем репликам и требовал ручной ротации при подозрении на утечку.
Вариант с ключом внутри образа был ещё хуже: ключ попадал в историю сборки и мог быть извлечён из образа. Вариант с проксированием всех операций через отдельный сервис уменьшал распространение полномочий, но добавлял сетевой переход, новую точку отказа и операционные расходы.
Выбрали workload identity: отдельный сервисный аккаунт для обработчика, отдельная IAM-роль, разрешающая чтение входного префикса и запись только в префикс результатов. Роль доверяла лишь этому сервисному аккаунту в конкретном пространстве имён. В результате ротация постоянных ключей исчезла, а компрометация другой службы не давала ей доступ к этим объектам.
Нет. Нужно ограничить всю цепочку доверия: доверенного издателя токена, аудиторию, конкретный кластер или набор кластеров, пространство имён и сервисный аккаунт. Если политика принимает любой токен от доверенного издателя, другой под с подходящими общими признаками может получить ту же роль.
Kubernetes Secret сам по себе не превращает ключ в краткоживущую идентичность: это всё ещё секрет, который нужно защищать, ротировать и отзывать. Workload identity использует временные учётные данные и привязывает доступ к удостоверению рабочего процесса. Однако токены и временные данные всё равно требуют защиты, потому что скомпрометированный процесс может использовать их до истечения срока действия.
IP пода обычно эфемерен и может перейти другому экземпляру после пересоздания. Он также не выражает намерение или принадлежность workload и может быть скрыт сетевыми преобразованиями. Сервисная идентичность с проверяемыми атрибутами субъекта стабильнее для авторизации, но требует корректного управления токенами и доверительной политикой.