DevSecOps для самых маленьких: 3\n. Эндер-сундук. Секреты.
В Minecraft есть обычный сундук и эндер-сундук. Обычный сундук стоит у тебя на базе. Если кто-то забрёл на базу или нашёл координаты — он его обчистит. Эндер-сундук — другое дело. Он привязан к игроку. Даже если кто-то найдёт твою базу, даже если тебя убьют, содержимое эндер-сундука останется с тобой. Достать его может только владелец.
С секретами в DevSecOps ровно та же история. Kubernetes Secret, .env-файл, переменная CI — это обычные сундуки. Они стоят на виду, и любой, кто получил доступ к кластеру, репозиторию или пайплайну, может их открыть. Vault, Deckhouse Stronghold, StarVault — это эндер-сундуки. Централизованные хранилища, куда доступ по ролям, аудит каждого чтения и ротация. А Gitleaks — это проверка перед выходом из дома. Прежде чем уйти в рейд, ты смотришь, не забыл ли ты координаты базы на табличке у входа. Gitleaks делает то же самое: перед коммитом проверяет, не написал ли ты пароль или токен прямо в коде.
В статье All Pick — мы разобрали, какие роли вообще есть. Теперь берём первого героя и играем. Начинаем с секретов. Потому что без них остальные практики DevSecOps не имеют смысла: харденинг кластера бесполезен, если пароль от базы лежит в Git. Микросегментация бесполезна, если токен от registry в переменной CI.
Для новичка: запомни, base64 — это не шифрование. Это кодирование. Любой раскодирует за секунду. Пароль в Git — это пароль, который уже утёк. Дальше — серьёзный разбор.
Что такое управление секретами и почему это не «просто .env»
Секрет — это любой артефакт, который даёт доступ к чему-то важному: пароль к базе данных, API-токен, приватный ключ, сертификат, SSH-ключ. Проблема в том, что эти артефакты живут в местах, которые разработчики считают удобными, а безопасники — потенциальными утечками.
Типичный жизненный цикл секрета в незрелой команде выглядит так. Секрет появляется в .env-файле на ноутбуке разработчика. Потом он попадает в .gitignore — но не всегда. Иногда попадает в Git. Иногда — в переменные окружения CI/CD. Иногда — в Helm values. Иногда — в Kubernetes Secret. Иногда — во всё сразу, потому что «надо быстро».
Проблема не в том, что Kubernetes Secret плохой. Проблема в том, что Kubernetes Secret — это не хранилище. Это механизм доставки. По умолчанию он хранится в etcd в base64, то есть фактически в открытом виде. Он не даёт аудита доступа. Он не даёт ротации. Он не даёт динамических учёток. Он даёт только «положи сюда — и поды прочитают». И если кто-то получил доступ к etcd или к API-серверу с правом читать Secrets — он получил всё.
Три уровня зрелости: от обычного сундука до эндер-сундука
Уровень 1: Базовая гигиена
Это то, с чего начинают все. Не потому что это модно, а потому что без этого остальное не имеет смысла.
Gitleaks — сканер, который ищет секреты в Git-репозитории: в коде, в истории коммитов, в ветках. Он работает по правилам (регулярные выражения плюс энтропия) и умеет ловить AWS-ключи, токены Slack, приватные ключи, пароли и многое другое.
Минимальное внедрение. Первое — pre-commit hook. Файл .pre-commit-config.yaml в корне репозитория. Gitleaks запускается до коммита и не даёт запушить секрет. Второе — CI job. В GitLab CI добавляется стадия secret-detection, которая запускает Gitleaks по всему репозиторию. Если найдено — пайплайн падает. Третье — ротация. Если секрет уже в истории — его надо не «удалить из последнего коммита», а отозвать и заменить. История Git хранит всё. git filter-branch или BFG помогут почистить историю, но отозвать ключ всё равно нужно.
Что это даёт: секреты перестают попадать в новые коммиты. Старые утечки остаются, но перестают расти. Это как проверка перед выходом из базы: ты перестаёшь оставлять координаты на табличке.
Чего это не даёт: нет централизованного хранения, нет аудита, нет ротации. Каждый разработчик всё ещё может положить секрет в переменную окружения или в Helm values.
Уровень 2: Git-native подход
Если у вас нет Vault, но есть требования к безопасности — можно использовать SOPS плюс age.
SOPS (Secrets OPerationS) — утилита, которая шифрует значения в YAML, JSON и ENV-файлах, оставляя ключи открытыми. То есть вы можете положить зашифрованный файл в Git, и он будет выглядеть так: database, password, ENC[AES256_GCM,data:...,type:str]. Расшифровать может только тот, у кого есть ключ.
age — современный инструмент шифрования, который используется как бэкенд для SOPS. Каждый инженер генерирует свою пару ключей через age-keygen, публичный ключ добавляется в .sops.yaml, приватный хранится локально или в защищённом месте.
Как это работает. В корне репозитория создаётся .sops.yaml. Файл с секретами шифруется командой sops -e secrets.yaml > secrets.enc.yaml. В CI/CD при деплое файл расшифровывается командой sops -d secrets.enc.yaml > secrets.yaml. Приватный ключ для CI хранится в защищённой переменной (masked, protected).
Что это даёт: секреты в Git в зашифрованном виде. Аудит — через историю коммитов. Ротация — через перевыпуск ключей. Это как запирать сундук на замок, ключ от которого только у тебя. Сундук стоит на базе, но открыть его без ключа никто не может.
Чего это не даёт: нет динамических секретов, нет централизованного управления доступом, нет автоматической ротации. Если приватный ключ утёк — всё расшифровано. Это как потерять ключ от сундука: содержимое больше не твоё.
Уровень 3: Централизованное хранилище
Это то, к чему приходят банки и крупные заказчики. Хранилище секретов — это отдельный сервис, который хранит секреты в зашифрованном виде, даёт доступ по ролям (policy-based access), ведёт аудит каждого чтения, умеет ротацию и умеет динамические секреты — создаёт временную учётку в базе на 15 минут и удаляет её после. Это и есть эндер-сундук.
HashiCorp Vault — эталон в этой категории. Но здесь есть важный нюанс, который пропускают почти все обзоры.
С августа 2023 года Vault распространяется под лицензией BUSL 1.1 (Business Source License). Это не open source в понимании OSI. Лицензия разрешает использовать, копировать, модифицировать и распространять код, но запрещает предоставлять его как конкурирующий hosted-сервис с продуктами HashiCorp. Для внутреннего использования в компании — можно. Для построения SaaS на базе Vault — нельзя. Причём «конкурирующий» определяется HashiCorp в одностороннем порядке и может меняться без уведомления. Каждый релиз Vault через четыре года конвертируется в MPL 2.0, но для актуальных версий юридическая проверка обязательна.
Как Vault интегрируется с Kubernetes. Есть несколько паттернов.
Первый — Vault Agent Injector. Mutating webhook, который добавляет в под sidecar-контейнер. Sidecar аутентифицируется в Vault через Kubernetes ServiceAccount, забирает секреты и рендерит их в файлы в shared volume. Приложение читает файлы.
Второй — Vault Secrets Operator (VSO). Рекомендуемый современный паттерн. Оператор синхронизирует секреты из Vault в Kubernetes Secrets. Для высокорегулируемых сред есть режим VSO protected secrets с CSI-драйвером, при котором секреты не хранятся в etcd — только монтируются в поды.
Третий — CSI Provider. Secrets Store CSI Driver монтирует секреты из Vault как файлы. Это стандартный механизм Kubernetes для внешних секретов.
Важное правило: никогда не инжектить динамические секреты как переменные окружения. Если секрет ротируется или истекает во время выполнения — приложение не узнает об этом. Всегда использовать volume mounts. Это как положить вещь в эндер-сундук, а не носить её в руке. Пока она в руке, её могут выбить при смерти.
Российские решения
Deckhouse Stronghold от «Флант» — хранилище секретов, которое позиционируется как замена HashiCorp Vault. Community Edition — бесплатная. Certified Security Edition (CSE) получила сертификат ФСТЭК России номер 5038 от 10 февраля 2026 года. Сертификат подтверждает соответствие требованиям приказа ФСТЭК номер 76 и техническим условиям по 4-му уровню доверия. Это означает, что продукт можно использовать в ГИС, КИИ и системах, работающих с персональными данными.
StarVault от Orion soft — система управления секретами с интеграцией в CI/CD и Kubernetes. Поддерживает аутентификацию через JWT, OIDC, LDAP/LDAPS. Подтверждена совместимость с GitFlic — российской платформой для разработки — секреты могут безопасно использоваться в пайплайнах без передачи чувствительных данных в открытом виде. StarVault также совместим с РЕД ОС и MULTIFACTOR.
ЦУП 2.0 от «АТ Консалтинг» — модуль управления секретами, интегрируется с Jenkins, Ansible и другими CI/CD-инструментами. Есть интеграция с «Платформой Боцман» — контейнерной платформой от «Астры».
Что делать на практике: порядок внедрения
Неделя 1. Добавить Gitleaks в pre-commit. Убедиться, что ни один новый секрет не попадает в Git. Если есть старые утечки — отозвать ключи.
Неделя 2. Добавить Gitleaks в CI. Сделать так, чтобы критичные находки ломали сборку.
Неделя 3–4. Если есть требования к хранению секретов в Git — внедрить SOPS плюс age. Зашифровать .env-файлы, Helm values, конфиги.
Месяц 2–3. Выбрать централизованное хранилище. Если есть требования ФСТЭК — смотреть на Deckhouse Stronghold CSE или StarVault. Если нет — можно начать с Vault, с юридической проверкой BUSL. Настроить Kubernetes auth, включить аудит, перевести хотя бы базу данных на динамические секреты.
Чеклист. Gitleaks в pre-commit. Gitleaks в CI/CD. Все утёкшие секреты отозваны и заменены. .env-файлы не коммитятся. Секреты в Git — только в зашифрованном виде, SOPS или аналог. Kubernetes Secret не используется как хранилище — только как доставка. Включено encryption at rest для etcd. RBAC ограничивает доступ к Secret-объектам. Есть план ротации секретов. Выбрано централизованное хранилище — Vault, Stronghold, StarVault или другое.
Нюансы импортозамещения
Open source в России — это не «просто скачал и забыл». BUSL у Vault — пример того, что лицензия может измениться в любой момент. GPL и AGPL — copyleft, который может «заразить» проприетарный код. Для критичных проектов стоит иметь локальное зеркало репозиториев или использовать российские платформы: GitVerse, GitFlic, Mos.Hub.
Сертификация ФСТЭК — не формальность. Для КИИ, ГИС и персональных данных наличие сертификата у инструмента — часто обязательное условие. Deckhouse Stronghold CSE имеет сертификат номер 5038 от 10 февраля 2026 года. Это значит, что его можно использовать в регулируемых средах без дополнительных согласований.
Реестр отечественного ПО — при наличии аналога в реестре закупка зарубежного ПО требует обоснования. StarVault и Deckhouse Stronghold — в реестре.
Главное
Секреты — это фундамент. Без них остальное не работает: харденинг, микросегментация, policy as code — всё это рушится, если пароль лежит в Git.
Обычный сундук — это Kubernetes Secret. Эндер-сундук — это Vault или его аналоги. Gitleaks — проверка перед выходом из базы. Не оставляй координаты на табличке.
