Как правильно работать с секретами в CI/CD и инфраструктуре?

Question

Accepted Answer

Секреты не хранят в коде, образах и логах. Источник — хранилище секретов (Vault, облачный менеджер, секреты CI), выдача — по минимальным правам и по возможности короткоживущая (OIDC вместо статических ключей облака). Утёкший в Git секрет считается скомпрометированным: сначала отозвать и заменить, потом уже чистить историю. Удаление коммита не помогает: история уже у всех, в форках и кэшах Сканеры секретов в pre-commit и CI (gitleaks, trufflehog) CI маскирует секреты в логах, но echo в base64 или опечатка обходят маску Секреты из CI не доступны сборкам из форков — иначе любой PR их украдёт Иерархия решений: 1. Не иметь секрета: OIDC-федерация CI с облаком, workload identity в Kubernetes — временные токены вместо постоянных ключей. 2. Короткоживущие динамические секреты (Vault выдаёт пароль к БД на час). 3. Статические секреты в хранилище с ротацией и аудитом доступа. Утечка в Git — порядок действий: 1. Отозвать ключ, выпустить новый, обновить потребителей. 2. Проверить журналы использования ключа. 3. Почистить историю (git filter-repo) — для гигиены, а не защиты. 4. Добавить сканер, чтобы не повторилось. Частые ошибки: .env в репозитории, секреты в ARG Dockerfile, вывод переменных окружения в логи при отладке, один общий ключ на всё, self-hosted раннер с доступом к проду, на котором запускаются чужие PR.

Как правильно работать с секретами в CI/CD и инфраструктуре?

Подробно

Что хотят услышать

Связанные вопросы

Подсказки на собеседовании — в реальном времени