Защитите рабочие процессы GitLab CI/CD с помощью OIDC JWT на платформе DevSecOps

Сохранение безопасности рабочих процессов CI/CD может быть сложной задачей. Здесь мы рассмотрим технологию токенов JWT и то, как ее можно использовать с аутентификацией OIDC, а также обсудим проблемы реализации в сферах авторизации. Вы узнаете о текущих возможностях и планах на будущее с GitLab 16.0.

Переменные и секреты

Переменные — это эффективный способ контролировать и вводить параметры в ваши задания и конвейеры, упрощая управление и настройку рабочих процессов CI/CD. Дополнительный уровень безопасности поверх переменных для маскировки и защиты — это лучшее, что мы можем сделать сегодня, чтобы предотвращать раскрытие конфиденциальных переменных. Однако переменные не являются заменой секретов. Защита секретов — это решение, которое GitLab стремится предоставить.

Мы рекомендуем хранить конфиденциальную информацию в специальном решении для управления секретами. Интегрировать и извлекать секреты в рамках ваших рабочих процессов CI/CD.

Безопасность на ранних этапах жизненного цикла разработки

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

Решения и фреймворки для управления секретами решили одну проблему, но создали новые. Например: «Какой инструмент подходит для наших нужд?» или «Как лучше всего интегрировать это в процессы DevOps, чтобы мы были в безопасности, но при этом работали максимально эффективно?» Поэтому игнорировать протоколы безопасности в вашей организации нельзя.

Начальная поддержка JWT

Веб-токен JSON (JWT) предназначен для создания моста интеграции в качестве открытого стандарта для обмена заявлениями о безопасности. Это токен, который позволяет безопасно осуществлять аутентификацию между различными продуктами. JWT состоит из трех частей: заголовка, полезной нагрузки и подписи.

Заголовок представляет тип токена и алгоритм шифрования.
Подпись гарантирует, что токен не был изменен.
Полезная нагрузка содержит ряд утверждений с информацией, которой обмениваются две стороны, включая данные о пользователе GitLab (идентификатор, адрес электронной почты, логин) и информацию о конвейере (идентификатор конвейера, идентификатор задания, среду и т. д.).

Пример для GitLab JWT payload


{
"jti": "c82eeb0c-5c6f-4a33-abf5-4c474b92b558",
"iss": "gitlab.example.com",
"iat": 1585710286,
"nbf": 1585798372,
"exp": 1585713886,
"sub": "job_1212",
"namespace_id": "1",
"namespace_path": "mygroup",
"project_id": "22",
"project_path": "mygroup/myproject",
"user_id": "42",
"user_login": "myuser",
"user_email": "[email protected]",
"pipeline_id": "1212",
"pipeline_source": "web",
"job_id": "1212",
"ref": "auto-deploy-2020-04-01",
"ref_type": "branch",
"ref_protected": "true",
"environment": "production",
"environment_protected": "true"
}

С этой информацией («утверждениями») вы можете реализовать условие проверки подлинности, при котором токен будет отклонен, если одно из этих утверждений не соответствует. Вы можете использовать это, чтобы ограничить доступ только авторизованным пользователям и заданиям в ваших конвейерах.

GitLab 12.10 добавила первоначальную поддержку подключений на основе токенов JWT, которая позже была расширена с помощью ключевого слова secrets:, а также предопределенной переменной CI_JOB_JWT, которая автоматически вводится в каждое задание в конвейере. Пользователи могут использовать ее для считывания секретов прямо из хранилища в рамках своего рабочего процесса CI/CD

OIDC (JWT 2.0)

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

Эта проблема была решена в GitLab 14.7, когда выпустили первую альфа-версию JWT V2, которая обеспечивала поддержку Open ID Connect (OIDC) для CI/CD.

OIDC — это уровень идентификации поверх веб-токена JSON. Вы можете безопасно проходить аутентификацию во многих продуктах и сервисах, которые реализуют OIDC, включая AWS, GCP и многие другие, что позволяет использовать потенциал токена наполную. Аналогично первой итерации JWT, GitLab добавил еще одну предопределенную переменную CI_JOB_JWT_V2, которая также автоматически вводится в каждое задание в конвейере CI/CD.

Хранение секретов

Цепочка поставок программного обеспечения должна включать все необходимое для доставки и запуска. Защита этой цепочки означает, что вам необходимо защитить и свое ПО, и окружающую (облачную) инфраструктуру.

В GitLab 15.9 добавили дополнительные уровни защиты, чтобы перевести токен OIDC из альфа-теста в рабочее состояние, повысив безопасность ваших рабочих процессов CI/CD.

Согласие на подключение токена JWT

Итак, веб-токены JSON (V1 и V2) хранятся в переменных CI/CD, которые автоматически внедряются во все задания в конвейере CI/CD. Однако вполне вероятно, что большинству заданий в вашем конвейере токен не нужен.

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

Чтобы объявить веб-токен JSON там, где нужно, настройте задание в файле конфигурации .gitlab-ci.yml, следуя этому примеру:


job_name:
id_token:
MY_JOB_JWT: # or any other variable name
...

Audience claim (aud:)

Мы уже выяснили, что утверждения составляют часть полезной нагрузки веб-токена JSON и представляют собой набор информации, которой обмениваются две стороны. Стандарт JWT различает зарезервированные, общедоступные и частные утверждения.

aud: — это зарезервированное утверждение, которое определяет аудиторию, для которой предназначен JWT (по сути, целевой объект токена): какие службы, API или продукты должны принимать этот токен. Если утверждение об аудитории не совпадает, токен отклоняется, что помогает сохранить безопасность цепочки поставок ПО.

Настроить утверждение аудитории можно в конфигурации CI/CD при объявлении использования токена JWT. Продолжим предыдущий пример:


job_name:
id_token:
MY_JOB_JWT: # or any other variable name
aud: "..." # mandatory field
script: - my-authentication-script.sh MY_JOB_JWT….. # use the declared variables in a script

Это обязательно для пользователей хранилища (Vault), которые используют встроенную интеграцию GitLab/Vault (с использованием ключевого слова «secrets:»).


job_name:
secrets:
VAULT_JWT_1: # or any other variable name
id_token:
aud: 'devs' # audience claim configuration
STAGING_DATABASE_PASSWORD: # VAULT_JWT_1 is the token to be used
vault: staging/db/password@ops

Изменения и совместимость

Чтобы использовать новый токен, пользователи должны принять это изменение в настройках интерфейса и обновить конфигурацию конвейера, как описано в предыдущих разделах. Пользователи могут продолжать использовать альфа-версию или «старый метод» до GitLab 16.0.

Также объявили о нескольких критических изменениях как для пользователей Vault, так и для пользователей «старых» методов JWT. Эти изменения запланированы в GitLab 16.0.

Три способа использования токена JWT

Есть три способа использования JWT для аутентификации в различных продуктах конвейера CI/CD:

«Старый» метод с ключевым словом secrets: и переменной CI_JOB_JWT, который в основном используется для интеграции с Hashicorp Vault.
Альфа-версия, в которой используется токен CI_JOB_JWT_V2 для интеграции с облачными провайдерами.
Готовый к работе токен OIDC, который представляет собой защищенную версию токена CI_JOB_JWT_V2 и используется для аутентификации в Vault, GCP, AWS и т. д.

Все три метода доступны до следующей версии (GitLab 16.0). После — только защищенный токен OIDC.

Чтобы подготовиться к этому изменению, вы должны:

Настройте конвейеры для использования более безопасного ключевого слова id_token.
Включите параметр Ограничить доступ к веб-токенам JSON (JWT) , чтобы предотвратить доступ к старым токенам для любых заданий.
Если вы используете нативную интеграцию GitLab/Hashicorp (с ключевым словом secrets:vault), убедитесь, что связанная аудитория имеет префикс https://.

Это поможет обеспечить плавный переход на GitLab 16.0 без нарушения существующих рабочих процессов.

Наша компания Core 24/7 стала Professional Service Partner для GitLab! Это означает, что теперь мы сможем предоставлять нашим клиентам высококачественные услуги, связанные с продуктами GitLab, и помогать им использовать этот инструмент более успешно.

Для наших клиентов это также означает, что они могут рассчитывать на еще большую квалификацию и опыт наших специалистов.

Если у вас есть вопросы или нужна помощь в использовании GitLab — обращайтесь к нам, мы всегда готовы помочь! Можем начать, например, с аудита инфраструктуры. Ну, или выбирайте ту услугу, которая более актуальна