JetBrains объявила о выпуске нового дополнения OIDC JWT для платформы TeamCity, предназначенного для аутентификации процессов сборки в AWS, Google Cloud и других сервисах, поддерживающих OpenID Connect, без использования постоянных ключей или паролей в среде CI/CD. Дополнение призвано устранить один из источников операционных и безóпасных рисков в конвейерах сборки: постоянные учетные данные могут утечь через журналы или файлы сборки, а также обычно требуют регулярной ротации для соблюдения требований безопасности.
Как работает аутентификация?
В рамках этого процесса TeamCity выпускает от имени процесса сборки криптографически подписанный JSON Web Token. Токен содержит утверждения, определяющие идентификатор рабочей нагрузки, срок его действия, целевую аудиторию и адрес издателя. После получения токена внешний сервис проверяет подпись с помощью открытых ключей, связанных с издателем, а затем проверяет указанную аудиторию и срок действия, прежде чем использовать утверждения для аутентификации процесса сборки.
Некоторые сервисы принимают токен поставщика удостоверений напрямую, тогда как другие выполняют обмен токенами, чтобы выпустить собственные временные учетные данные. JetBrains оставляет детали настройки этого процесса для каждого сервиса, рекомендуя пользователям обращаться к документации AWS или Google Cloud при настройке аудитории и условий проверки.
Что дополнение добавляет в TeamCity?
OIDC JWT добавляет серверу TeamCity возможности поставщика удостоверений, необходимые для выпуска токенов. Дополнение поддерживает подпись токенов с помощью алгоритмов на основе RSA или ECDSA, а также ротацию ключей подписи через веб-интерфейс или специальную конечную точку HTTP для авторизованных запросов. По данным JetBrains, ротация ключей по умолчанию не приводит к остановке выполняющихся процессов сборки и не делает недействительными ранее выпущенные токены.
Для общедоступных серверов TeamCity дополнение предоставляет документ .well-known/openid-configuration и набор открытых ключей JWKS. Для серверов, не доступных из интернета, можно настроить пользовательский адрес источника и разместить документы конфигурации на общедоступном хосте, использующем HTTPS, не открывая сам сервер TeamCity для общего доступа. Дополнение также предоставляет программный интерфейс, позволяющий другим дополнениям добавлять новые способы подписи, включая интеграцию с аппаратными модулями безопасности HSM или сервисами управления ключами, такими как Google Cloud KMS.
Варианты выпуска токенов и требования к использованию
После установки дополнения из JetBrains Marketplace и его активации им можно управлять в разделе Admin | Integrations | OIDC Tokens. Требуется Java 17; поддерживаются TeamCity 2025.11 и более поздние версии. Администратор может указать адрес источника, параметры подписи и настройки управления ключами подписи.
Дополнение предоставляет два типа шагов сборки для выпуска токенов. Первый — OIDC Token (in build parameters) — создает токен при запуске сборки и сохраняет его в указанном параметре сборки. Срок действия можно настроить; по умолчанию он равен времени ожидания сборки или 10 минутам, если время ожидания не задано. Также можно выпустить токен для одной или нескольких аудиторий и добавить отдельную функцию, если сервисам требуются независимые токены для одной аудитории.
Второй тип — OIDC Token (on demand via HTTP request) — подходит для длительных процессов сборки, поскольку позволяет скриптам запрашивать краткосрочный токен во время выполнения через HTTP. Срок действия таких токенов всегда составляет 5 минут и не может быть изменен.
Почему это важно?
Практическое изменение заключается в переносе аутентификации с долгоживущих секретов на токены, связанные с процессом сборки и ограниченные по сроку действия и аудитории. Это снижает ценность токена в случае утечки, но не отменяет необходимости тщательно настраивать разрешения и проверять адрес источника и аудиторию. JetBrains предупреждает, что изменения настроек дополнения могут нарушить существующие интеграции, поэтому рекомендует настроить его до подключения процессов сборки к аутентификации через OIDC. Кроме того, эффективность решения зависит от поддержки целевым сервисом OIDC и его официальных настроек; эти моменты необходимо проверять отдельно для каждой интеграции.