AWS добавляет провайдера учетных данных для рабочих нагрузок для доставки сертификатов и секретов

AWS представила AWS Workload Credentials Provider, клиентский сервис с открытым исходным кодом, который дает приложениям локальный путь к сертификатам и секретам из AWS Secrets Manager и AWS Certificate Manager.

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

AWS спроектировала инструмент для рабочих нагрузок в AWS, в дата-центрах и в других средах. Это важно для команд, которые работают в гибридных инфраструктурах, но уже используют AWS для выпуска сертификатов или хранения секретов. Сервис на экземпляре EC2, сервер Windows или локальный Linux-хост могут использовать одни и те же управляемые источники без полного переноса в среду выполнения AWS.

Разработчики настраивают провайдер с помощью файла TOML. Этот файл определяет ARN сертификатов, ARN ролей IAM, пути вывода для материалов сертификата, файлов закрытого ключа, цепочек сертификатов, команды обновления, журналирование и поведение среды выполнения. Затем провайдер получает настроенные материалы, записывает файлы с ограниченными правами доступа и обновляет локальную копию, когда AWS сообщает об изменении содержимого.

AWS сообщает, что провайдер поддерживает экспорт сертификатов ACM для публичных и частных TLS-сертификатов. Это дает архитекторам еще один вариант для веб-серверов и конечных точек сервисов, которым нужны файловые TLS-артефакты, включая стеки, которые не могут вызывать API AWS внутри пути обработки запроса.

Поддержка Secrets Manager расширяет старую модель AWS Secrets Manager Agent. Команды, которые уже развернули этот агент, могут рассматривать Workload Credentials Provider как более широкий путь преемственности, поскольку AWS позиционировала новый проект сразу и вокруг секретов, и вокруг сертификатов.

Провайдер проверяет настроенные сертификаты каждые 24 часа. Он также выполняет начальное обновление при запуске, распределяет время обновления по хостам, чтобы избежать всплесков запросов, и позволяет операторам перезагружать конфигурацию без повторной установки службы. Команды могут настраивать до 50 сертификатов, и провайдер управляет каждым сертификатом в отдельном процессе.

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

Команда перезагрузки закрывает разрыв между ротацией сертификата и его использованием приложением. Провайдер может записать новый сертификат в /etc/pki/tls/certs/example.com.crt, записать ключ в /etc/pki/tls/private/example.com.key, обновить файл цепочки и выполнить /usr/sbin/nginx -s reload. Операторам больше не нужен отдельный cron-задание, которое угадывает, когда ACM изменил сертификат.

Развертывания Linux требуют systemd. Развертывания Windows требуют PowerShell 5.1 или новее. AWS запускает сервис от имени пользователя с низкими привилегиями, что соответствует модели, которую хотят команды безопасности для локальных агентов учетных данных: дать агенту минимальные права на хосте, необходимые для записи файлов и запуска ограниченной команды перезагрузки.

Эта архитектура понравится командам, которые используют программное обеспечение, ориентированное на файлы. Веб-серверы, устаревшие Java-сервисы, service mesh с файловыми наблюдателями и готовые аппаратные или программные комплексы часто ожидают сертификат и ключ на диске. Разработчики могут изменить код приложения, чтобы вызывать API Secrets Manager или ACM, но многие операционные команды предпочитают не держать учетные данные внутри runtime приложения и поручить получение и ротацию хост-сервису.

Провайдер также дает клиентам AWS нативный ответ на паттерн, который многие команды решали с помощью Vault Agent. HashiCorp Vault Agent может аутентифицироваться, кэшировать, рендерить шаблоны и обновлять учетные данные для локальных приложений. Теперь AWS закрывает похожую клиентскую роль для клиентов, которые хранят источник истины в Secrets Manager и ACM.

У этого сравнения есть ограничения. Vault поддерживает более широкую экосистему идентификации и секретов, включая динамические учетные данные для баз данных, множество методов аутентификации и рендеринг шаблонов в разных провайдерах. Workload Credentials Provider имеет больше смысла, когда команда уже выбрала управляемые сервисы AWS и хочет меньше движущихся частей на хосте.

Ценообразование следует за базовыми сервисами. AWS не взимает плату за сам провайдер и выпустила проект под лицензией Apache 2.0. Команды по-прежнему платят за Secrets Manager, функции ACM, использование API и любую связанную инфраструктуру. Кэширование может снизить объем запросов, но архитекторам следует моделировать вызовы Secrets Manager по флотам с большим числом хостов и частыми перезапусками.

Командам безопасности следует проверить дизайн ролей IAM перед развертыванием провайдера. Хосту нужны права на экспорт конкретных сертификатов или чтение конкретных секретов. Слишком широкие права на чтение воспроизведут риск, который центральные хранилища секретов и призваны уменьшать. Более чистая модель дает каждой рабочей нагрузке доступ только к тем ARN сертификатов и секретов, которые ей действительно нужны.

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

Наиболее практичный сценарий начинается с обновления TLS. Команда, запускающая NGINX на EC2, может выпустить сертификат в ACM, настроить провайдер на его экспорт, поместить сертификат и ключ в пути, которые NGINX уже использует, и перезагрузить NGINX после обновления. Стек приложения сохраняет текущую TLS-схему, а AWS берет на себя выпуск сертификата, а провайдер — локальную доставку.

Второй сценарий подходит для гибридных приложений. Компания может запускать прокси базы данных или внутренний API-шлюз в частном дата-центре, при этом хранить секреты в AWS. Workload Credentials Provider позволяет этому хосту потреблять управляемые AWS учетные данные без добавления собственного сервиса синхронизации.

Третий сценарий подходит для миграционных программ. Команды могут сначала перенести хранение секретов в AWS, а затем позже изменить код приложения. Провайдер связывает старый файловый контракт с новым управляемым backend для секретов, что дает платформенным командам менее рискованный путь миграции.

Архитекторам по-прежнему нужно решить, подходят ли для рабочей нагрузки локальные файлы. Для новых cloud-native сервисов прямые вызовы SDK или workload identity могут избавить от записи долговременных данных на диск. Для ПО, которое уже ожидает файлы, провайдер сокращает объем собственного кода и дает операторам управляемый цикл обновления.

AWS также дала платформенным командам точку для управления. Центральные команды могут стандартизировать ACM и Secrets Manager, опубликовать шаблон конфигурации провайдера и позволить командам приложений потреблять локальные файлы, не изучая весь API-поверхность AWS. Это помогает в инфраструктурах, где операционные команды владеют хостами, а команды приложений владеют развертываемыми сервисами.

Компромисс находится в плоскости control plane. Команды получают поддерживаемый AWS путь для локальной доставки, но при этом привязывают больше частей жизненного цикла учетных данных к API AWS, политикам IAM и поведению региональных сервисов. Мультиоблачным командам следует тестировать отказы: поведение устаревшего кэша, запуск во время сбоев API AWS, ошибки экспорта сертификатов и сбои перезагрузки службы.

Workload Credentials Provider не устранит необходимость в архитектуре учетных данных. Он сужает одну проблемную часть этой архитектуры. Команды, которые уже зависят от Secrets Manager и ACM, могут заменить хрупкие скрипты обновления сервисом, который поддерживает AWS, а затем потратить время на ревизию на границах доступа, контроле хоста и безопасности развертывания.

AWS опубликовала проект на GitHub по адресу aws/aws-workload-credentials-provider. Командам, которые оценивают его, следует прочитать документацию проекта, подтвердить поддержку экспорта ACM для своих типов сертификатов и протестировать поведение обновления и перезагрузки на тех же сервисах, которые они запускают в production.