Как правильно управлять секретами в инфраструктуре и CI/CD? Почему нельзя хранить их в git и чем плохи «голые» Secrets в Kubernetes?
Короткий ответ
- Секреты в git остаются в истории навсегда
- Kubernetes Secret — base64, не шифрование; нужен RBAC и шифрование etcd
- Централизованные хранилища: Vault, облачные Secret Manager
- GitOps-варианты: SOPS и Sealed Secrets, External Secrets Operator
- Короткоживущие и динамические креденшелы лучше статических
- Ротация, аудит доступа и сканирование утечек — обязательные процессы
Секреты живут в специализированном хранилище с RBAC, аудитом и ротацией, а не в коде и не в base64.
Как сказать вслух
пример ответаСекреты нельзя коммитить в git, потому что они навсегда остаются в истории, и даже удалённый файл легко достать. В Kubernetes штатный Secret — это просто base64, поэтому обязательно включают шифрование etcd и ограничивают доступ через RBAC. Правильный подход — централизованное хранилище вроде Vault или облачного Secret Manager, откуда секреты доставляются в приложения, например через External Secrets Operator. Хорошим тоном считаю короткоживущие динамические креденшелы и обязательную ротацию, плюс сканеры секретов в CI, чтобы ловить случайные коммиты.
Подробный ответ
Основной ответ
Проблемы: git хранит историю вечно, доступ к репозиторию шире, чем к секрету; Kubernetes Secret кодируется base64 и без encryption at rest лежит в etcd открыто, а доступ по умолчанию слишком широкий. Решения по уровням: централизованное хранилище (HashiCorp Vault, AWS/GCP Secret Manager) с аутентификацией по identity (IRSA, Kubernetes ServiceAccount, OIDC в CI вместо долгоживущих токенов), аудитом и ротацией; доставка в кластер через External Secrets Operator, CSI Secrets Store или сайдкары; для GitOps — шифрование в репозитории через SOPS (age/KMS) или Sealed Secrets. Высший уровень зрелости — динамические секреты: Vault выписывает креденшелы БД на время жизни задачи. Дополнительно: git-hooks и сканеры (gitleaks, trufflehog) в CI, маскирование в логах пайплайнов, план реагирования на утечку с немедленной ротацией.
Ключевые моменты
- Git — навсегда. Попавший в историю секрет считается скомпрометированным: ротация обязательна, одной чистки истории недостаточно.
- Kubernetes Secret. Base64 — кодирование, не защита; нужны шифрование etcd, RBAC и запрет широких прав на чтение секретов.
- Identity вместо паролей. OIDC-федерация в CI и IAM-роли убирают долгоживущие ключи — красть становится нечего.
- Ротация и аудит. Хранилище должно отвечать на вопросы «кто, когда и к какому секрету обращался» и позволять быструю замену.
Практический контекст
Тема всплывает на каждом senior-собеседовании и в каждом аудите безопасности. Практические задачи: перевод команды с .env-файлов на Vault, настройка External Secrets в Kubernetes, OIDC вместо статических облачных ключей в GitHub Actions или GitLab CI, реагирование на случайно закоммиченный токен. Интервьюер часто спрашивает именно сценарий утечки: порядок действий и почему ротация важнее удаления из истории.
Частые ошибки
- Называют base64 в Kubernetes Secret шифрованием
- Предлагают просто удалить утёкший секрет из истории git без ротации
- Хранят долгоживущие облачные ключи в переменных CI вместо OIDC-федерации