TeamCity получил OIDC-плагин: облачные ключи в CI заменяют короткие JWT

JetBrains 1 сентября представила TeamCity OIDC JWT Plugin: с ним сервер TeamCity становится провайдером идентификации и выдаёт каждой сборке подписанный короткоживущий JWT вместо постоянных ключей доступа к облаку. Для команд, у которых в переменных CI лежат AWS-ключи с бессрочным сроком действия, это способ убрать их совсем, как это давно умеют GitHub Actions и GitLab CI.

Повод для новости у JetBrains не самый удобный: в августе компания разбирала взлом собственного сервиса Cadence через непропатченный TeamCity, где утекли в том числе облачные учётные данные. Автор публикации Игорь Бровцин формулирует проблему прямо: «статические учётные данные в средах CI/CD остаются значительным источником рисков безопасности и операционных издержек» (перевод редакции).

Как устроена цепочка доверия

Схема стандартная для OIDC-федерации. TeamCity публикует документ .well-known/openid-configuration и набор публичных ключей JWKS. В облаке администратор регистрирует TeamCity как доверенного провайдера с конкретным issuer и audience. Сборка получает JWT, подписанный приватным ключом сервера, предъявляет его облаку, а то проверяет подпись по JWKS и обменивает токен на временные учётные данные с нужной ролью. Ключей в CI-конфигурации нет вообще: есть только правило «сборкам проекта X с такими claims можно роль Y».

Поток OIDC-аутентификации между TeamCity и облачным провайдером. Источник: JetBrains

Есть два режима выдачи. Токен, выданный при старте сборки, действует до таймаута сборки плюс 10 минут. Токен, запрошенный по HTTP во время сборки, живёт, по README, «всегда 5 минут и не может быть изменён»: для длинных шагов его нужно запрашивать заново.

Требования и настройка

• TeamCity 2025.11.1 и новее, Java 17.
• Алгоритмы подписи RSA (RS256, RS384, RS512, PS256, PS384, PS512) с ключом 2048, 3072 или 4096 бит и ECDSA (ES256, ES384, ES512).
• Конфигурация в разделе Administration, Integrations, OIDC Tokens; в сборке добавляется build feature.
• Для сервера, недоступного из интернета, OIDC-документы и JWKS можно вынести на публичный HTTPS-хост: облаку нужен доступ только к ним, а не к самому TeamCity.

Последний пункт важен для российских установок: облачные провайдеры должны скачать JWKS по HTTPS, и если TeamCity живёт в закрытом контуре, плагин позволяет опубликовать только ключи. Кроме перечисленных облаков токен примет любой сервис, умеющий проверять JWT по JWKS; про другие провайдеры JetBrains не пишет, и их совместимость придётся проверять самостоятельно.

Подводный камень ротации ключей

README оговаривает: ротация ключа подписи по умолчанию не отзывает уже выданные токены. Старый публичный ключ остаётся в JWKS, пока не очищен JWK cache, поэтому при компрометации сервера нужно не только сменить ключ, но и явно сбросить кэш, а на стороне облака дождаться обновления JWKS. При коротком сроке жизни токенов окно риска небольшое, но оно есть.

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

Что делать сегодня

1. Провести ревизию: где в TeamCity лежат постоянные облачные ключи и какие у них права.
2. Обновить сервер до 2025.11.1 и новее, поставить плагин из репозитория JetBrains на GitHub.
3. Настроить в облаке доверие к issuer TeamCity с узким условием по audience и claims проекта.
4. Перевести одну некритичную сборку, убедиться, что она получает временные учётные данные, затем удалить её статический ключ.
5. Записать процедуру ротации с очисткой JWK cache в runbook инцидентов.

Плагин открыт и лежит в репозитории JetBrains. Редакция проверит, войдёт ли он в стандартную поставку TeamCity и появится ли настраиваемый срок жизни HTTP-токена.

Источники: Блог JetBrains: Authenticating TeamCity builds with OIDC, README плагина teamcity-oidc-jwt

Изображение на обложке: JetBrains