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».

Есть два режима выдачи. Токен, выданный при старте сборки, действует до таймаута сборки плюс 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