Как пайплайны получают доступ к секретам без их хранения
У вас есть пайплайн, который собирает, тестирует и развёртывает приложение. Где-то в этом процессе ему нужен пароль базы данных, ключ API или сертификат. Естественное желание — положить секрет в переменную пайплайна, конфигурационный файл или даже зашить прямо в скрипт. Но это создаёт проблему: как только секрет попадает в пайплайн, он может оказаться там, где вы совсем не планировали.
Секреты просачиваются в логи сборки. Они запекаются в Docker-образы. Они всплывают в файлах артефактов. Они остаются в кэше рабочей области. В тот момент, когда секрет касается кода пайплайна, вы теряете контроль над тем, куда он попадёт.
Решение не в том, чтобы полностью исключить секреты из пайплайна. Пайплайну они нужны для работы. Решение — внедрять секреты так, чтобы они существовали только в памяти, только на время выполнения задачи и никогда не сохранялись нигде постоянно. Есть три распространённых подхода, и у каждого свои компромиссы.
Переменные окружения: просто, но с утечками
Самый распространённый подход — получить секрет из хранилища (vault) и установить его как переменную окружения в запущенном процессе. Когда ваш пайплайн выполняет npm test или dotnet run, переменная DB_PASSWORD уже доступна в памяти процесса.
Этот подход прост и быстр. Он работает почти с любым инструментом и фреймворком. Вам не нужно менять то, как приложение читает конфигурацию. Большинство языков и сред выполнения поддерживают переменные окружения из коробки.
Например, с помощью Vault CLI можно получить секрет и экспортировать его перед запуском сборки:
# Получаем пароль БД из Vault и экспортируем как переменную окружения
export DB_PASSWORD=$(vault kv get -field=password secret/db-prod)
# Запускаем команду сборки, которой нужен секрет
npm run build
Проблема в том, что переменные окружения легко утекают. Многие приложения выводят все переменные окружения при отладке. Фреймворки для логирования часто по умолчанию пишут переменные окружения в файлы логов. Как только секрет оказывается в логе, любой, у кого есть доступ к системе логирования, может его прочитать. Сюда входят разработчики, сотрудники поддержки и, потенциально, злоумышленники, если система логирования скомпрометирована.
Есть и другой риск: артефакты сборки. Когда ваш пайплайн создаёт JAR-файл, Docker-образ или скомпилированный бинарник, переменные окружения могут быть захвачены, если процесс сборки случайно читает все переменные. Docker-сборка, использующая инструкции ARG или ENV, может встроить секреты в слои образа. Как только секрет попал в образ, он остаётся там навсегда, если только вы не пересоберёте и не переразвернёте всё заново.
Переменные окружения хорошо работают для короткоживущих пайплайнов, где вы жёстко контролируете логирование и процесс сборки. Они опасны в пайплайнах, которые создают артефакты или имеют подробное логирование.
Монтирование файлов: больше контроля, больше очистки
Второй подход — получить секрет из хранилища и записать его во временный файл внутри контейнера или рабочей области. Приложение читает этот файл во время запуска. После завершения задачи файл удаляется.
Этот подход даёт больше контроля. Вы можете установить права доступа к файлу так, чтобы только процесс приложения мог его читать. Вы можете смонтировать файл только для чтения. Вы можете удалить его сразу после использования. Многие современные фреймворки поддерживают чтение конфигурации из файлов. Spring Boot читает из application.properties или YAML-файлов. .NET читает из JSON-файлов конфигурации. Вы можете указать этим фреймворкам на временный файл, который содержит только секреты, необходимые для этого запуска.
Риск в том, что файлы могут остаться. Если ваш пайплайн не очищает рабочую область после завершения, файл с секретом остаётся на диске. В контейнерных средах смонтированный файл могут прочитать другие процессы в том же контейнере, если права доступа настроены неправильно. Если ваш пайплайн использует кэширование, например, кэширование слоёв Docker, файл с секретом может попасть в кэш и появиться в последующих сборках.
Монтирование файлов безопаснее переменных окружения, потому что вы контролируете время жизни и права доступа к файлу. Но это требует дисциплины: вы должны очищать всё после каждого запуска и следить, чтобы механизмы кэширования не сохраняли файл.
Прямые вызовы API: секрет не попадает в пайплайн
Третий подход — вообще не передавать секрет пайплайну. Вместо этого приложение или скрипт напрямую вызывает API хранилища каждый раз, когда ему нужен секрет. Пайплайн не обрабатывает секрет. Он не устанавливает переменные окружения. Он не записывает файлы. Приложение само обращается к хранилищу и получает то, что нужно.
Например, вместо передачи пароля базы данных через переменную окружения приложение вызывает GET /v1/secret/db-password, когда ему нужно подключиться к базе данных. Хранилище аутентифицирует запрос, возвращает секрет, и приложение использует его немедленно.
Следующая диаграмма последовательности иллюстрирует этот поток:
Это самый безопасный подход. Секрет никогда не существует в памяти пайплайна. Он никогда не записывается в файл. Он никогда не появляется в логах. Даже если кто-то получит доступ к рабочей области пайплайна, он не сможет найти секрет, потому что его там никогда не было.
Оборотная сторона — доступность. Ваше приложение теперь зависит от доступности хранилища. Если хранилище упадёт или станет недоступным, ваше приложение не сможет запуститься. Каждый вызов API добавляет задержку и оставляет след в журнале аудита хранилища. Этот подход лучше всего подходит для секретов, которые используются редко, или для динамических секретов с коротким сроком жизни, например, временных учётных данных базы данных, которые истекают через несколько минут.
Прямые вызовы API идеальны для производственных сред с высокими требованиями к безопасности, где команды инфраструктуры могут гарантировать доступность хранилища. Они избыточны для сред разработки или тестирования, где риск утечки секретов ниже.
Выбор правильного подхода
Не существует единственного лучшего метода. Выбор зависит от того, как часто используется секрет, насколько строгим должен быть контроль доступа и насколько надёжна ваша инфраструктура хранилища.
Для быстрых пайплайнов разработки, где секреты меняются редко, переменные окружения подходят, если вы контролируете логирование и создание артефактов. Для производственных развёртываний, где секреты не должны утекать, лучше подходят прямые вызовы API или монтирование файлов со строгой очисткой. Для контейнерных сред хорошо работают монтируемые файлы с правами только для чтения и автоматической очисткой после завершения контейнера.
Важно понимать слабые места каждого подхода и проектировать пайплайн так, чтобы закрыть эти пробелы. Не выбирайте просто самый лёгкий метод. Выбирайте метод, который соответствует вашему уровню риска и операционным возможностям.
Практический чек-лист
Прежде чем решить, как ваш пайплайн будет получать доступ к секретам, проверьте эти пункты:
- Создаёт ли ваш пайплайн артефакты (Docker-образы, JAR-файлы, скомпилированные бинарники), которые могут захватить переменные окружения?
- Выводят ли ваши фреймворки логирования переменные окружения по умолчанию?
- Можете ли вы установить права доступа к файлам для смонтированных секретов в вашей контейнерной среде?
- Очищает ли ваш пайплайн файлы рабочей области после каждого запуска?
- Достаточно ли надёжна ваша инфраструктура хранилища для прямых вызовов API из приложений?
- Нужны ли вам журналы аудита для каждого доступа к секрету?
Настоящая проблема
Получить секреты в пайплайн без их хранения — только половина проблемы. Сложнее убедиться, что они не утекают в неожиданные места: логи, артефакты, систему контроля версий или кэшированные слои сборки. Каждый подход даёт способ внедрить секреты, но ни один из них автоматически не предотвращает утечки. Для этого нужны постоянная дисциплина, автоматизированные проверки и чёткое понимание того, куда могут попасть ваши секреты.
Цель не в том, чтобы найти идеальный метод. Цель — выбрать метод, который соответствует вашей среде, и затем выстроить защиту вокруг его слабых мест.