Каким образом вышифруете переменные в CI

Я шифрую и храню чувствительные данные в CI через встроенные механизмы секретов (например, Secrets в GitHub Actions, переменные/секреты в GitLab CI, Credentials в Jenkins), чтобы они были зашифрованы "в покое" и не попадали в код или логи. В пайплайне такие значения пробрасываются через переменные окружения и помечаются как скрытые, чтобы не выводиться в вывод сборки. При необходимости использую внешние хранилища секретов (Vault, AWS Secrets Manager и т.п.) и получаю секреты динамически во время запуска пайплайна.

Цель шифрования переменных в CI — безопасно работать с паролями, токенами и ключами, не сохраняя их в репозитории и не светя в логах. Обычно я опираюсь на встроенные механизмы CI-систем и при необходимости дополняю их внешним хранилищем секретов.

Типичный подход выглядит так:

• Использовать встроенное хранилище секретов CI. В GitHub Actions это раздел Settings → Secrets and variables, в GitLab CI — Settings → CI/CD → Variables, в Jenkins — Credentials. Секреты там хранятся зашифрованными, имеют ограниченный доступ и автоматически маскируются в логах.
• Пробрасывать секреты в пайплайн только как переменные окружения. Секрет никогда не пишется в yaml-конфиг или скрипт в открытом виде, а лишь подставляется через переменные окружения, которые CI сам подставляет на этапе запуска job'а.
• При необходимости подключать внешние секрет-менеджеры. Например, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault или GCP Secret Manager. В этом случае пайплайн получает временный токен доступа, запрашивает нужные секреты у внешнего сервиса и использует их только на время выполнения job'а.
• Минимизировать область видимости. Я стараюсь задавать секреты на минимально возможном уровне: только для нужного проекта, окружения или отдельного job'а, плюс разграничивать доступ к ним по ролям.
• Ротация и аудит. Важно регулярно ротировать ключи и токены, а также отслеживать, кто и какие секреты добавляет/изменяет. Многие CI/секрет-менеджеры ведут аудит логов доступа.

Например, в GitHub Actions секрет можно сохранить в настройках репозитория как MY_API_KEY и использовать его в job'е через переменную окружения:

В GitLab CI секреты/переменные задаются в настройках проекта, после чего их можно использовать в конфигурации .gitlab-ci.yml также через переменные окружения: