Новый подход к аутентификации в CI/CD
Команда JetBrains представила официальный плагин, который превращает TeamCity в провайдер OpenID Connect (OIDC). Это нововведение кардинально меняет подход к управлению доступом сборочных агентов к облачным ресурсам. Вместо использования долгоживущих статических секретов, API-ключей или учетных записей, сборка теперь может получать временный, криптографически подписанный токен стандарта JWT (JSON Web Token).
Основная проблема, которую решает этот плагин, — это риски, связанные с компрометацией постоянных учетных данных. Если статический ключ от AWS, Google Cloud, Azure или Oracle Cloud попадет в чужие руки, злоумышленник получит длительный несанкционированный доступ к инфраструктуре. Короткоживущие токены OIDC минимизируют это окно возможностей: даже если токен будет украден, он станет бесполезным через несколько минут или часов.\n
Как работает интеграция
Процесс аутентификации строится на доверии между TeamCity и облачным провайдером. Схема работы выглядит следующим образом:
- Настройка доверия: В консоли управления облачным провайдером (например, AWS IAM или GCP IAM) создается доверительная политика (Trust Policy). В ней указывается, что доступ разрешен только для сборок TeamCity, соответствующих определенным критериям (например, из конкретного проекта или запускаемых определенным пользователем).
- Запрос токена: На этапе сборки агент TeamCity запрашивает у сервера подписанный JWT-токен. Этот токен содержит claims — утверждения о контексте сборки (кто запустил, какой репозиторий, какой коммит).
- Облачная проверка: Агент передает этот JWT напрямую облачному провайдеру (например, через команду AWS CLI). Провайдер проверяет подпись токена, используя публичный ключ TeamCity, и сверяет claims с настроенной политикой доверия.
- Временный доступ: Если проверка пройдена, облачный провайдер выдает стандартные временные учетные данные (например, Access Key и Secret Key в AWS), которые действуют только в рамках текущей сессии сборки.
Требования и настройка
Для внедрения этой схемы необходимо выполнить несколько условий:
- Версия TeamCity: Сервер и агенты должны быть обновлены до версии, поддерживающей OIDC Provider.
- Сетевая доступность: Агенты сборки должны иметь прямой доступ к серверам метаданных облачного провайдера для обмена токенами.
- Конфигурация политик: Требуется тщательная настройка условий (conditions) в политиках облачных провайдеров. Это самый ответственный этап, так как ошибка может либо заблокировать легитимные сборки, либо оставить лазейку для атаки.
Срок жизни токенов (TTL) настраивается администратором TeamCity. Рекомендуется устанавливать минимально возможное время, достаточное для завершения всех операций в облаке (обычно от 5 до 30 минут).
Ротация ключей и подводные камни
Одним из главных преимуществ OIDC является автоматическая ротация ключей. TeamCity периодически обновляет свои пары приватных и публичных ключей. Облачные провайдеры, поддерживающие OIDC, умеют запрашивать актуальные JWKS (JSON Web Key Set) эндпоинты, поэтому администраторам не нужно вручную менять доверенные сертификаты.
Однако существуют и сложности. Главная из них — кэширование ключей на стороне облачных провайдеров. Если вы принудительно отозвали токен или изменили политику, изменения могут вступить в силу не мгновенно. Также усложняется локальная отладка: разработчик не может просто скопировать свой ключ из CI и запустить скрипт локально, ему придется эмулировать процесс выдачи OIDC-токена, что требует дополнительных инструментов.
Внедрение OIDC в TeamCity — это значительный шаг к реализации парадигмы Zero Trust в CI/CD процессах, исключающий необходимость хранения чувствительных долгоживущих секретов в файловых системах агентов или переменных окружения.