Управление секретами в GitOps: где рвётся контур доставки
Типичная картина: рядом с манифестами в репозитории лежит файл, где пароли, токены и ключи записаны открытым текстом. Развёртывание из этого репозитория проходит зелёным, всё работает — до первого аудита, ухода инженера или смены подрядчика.
Проблема не в одном файле. Учётные данные лежат в манифестах открытым текстом: подключения к базам, доступы к внешним сервисам, ключи шифрования — всё в открытом виде для любого, у кого есть доступ к репозиторию.
Права на них выданы вручную: инженер заходит в панель, создаёт учётную запись, выдаёт роль и нигде это не фиксирует. Ротации нет — ключ живёт годами, и никто не скажет, сколько его копий уже разошлось по локальным машинам и резервным копиям.
История коммитов помнит всё: даже если удалить файл и закоммитить очищенную версию, значение останется в истории секретов в коммитах — то есть в каждом клоне репозитория у каждого, кто его когда-либо делал. Утечка учётных данных из репозитория вскрывается не сразу: логи показывают, что ключ используется, но не показывают, что он уже вне контроля.
Дороже всего это обходится в момент передачи: уходит инженер или меняется подрядчик, и никто не может перечислить живые доступы, кому они выданы и что сломается при отзыве. Остаётся ручная сверка панелей с репозиторием — при непрослеживаемой ротации и без гарантии, что старые ключи уже мертвы.
Разбираем, как это закрывается: как секреты едут через тот же контур доставки, что и остальные манифесты, но при этом ни в репозитории, ни в его истории не остаётся открытых значений.
Что меняется после внедрения: скорость, доступ, отказы
Переход на управление секретами через Git заметен не по числу инструментов, а по трём изменениям: среды становятся воспроизводимыми, ротация перестаёт быть ручной операцией, а расхождение конфигурации перестаёт ронять сервисы.
Воспроизводимость окружений
Контур поднимается из репозитория целиком: манифесты, политики доступа и зашифрованные значения лежат рядом и версионируются. Тестовая среда получает ту же структуру секретов, что и продуктивная, отличаются только значения, поэтому поведение совпадает. Время восстановления сервиса после аварии упирается в применение манифестов, а не в поиск паролей по чатам и заметкам.
Управляемая ротация без остановки сервисов
Смена ключа или пароля перестаёт быть обходом сервисов вручную. Значение правится в зашифрованном файле или во внешнем хранилище, оператор синхронизации подтягивает новую версию, приложение забирает её по мере обновления пода. Старый секрет отзывается отдельным шагом — остаётся окно, когда валидны обе версии, и выкатка проходит без простоя.
Снятый класс отказов
Расхождение конфигурации между средами закрывается тем, что источник правды один. Изменение проходит ревью и попадает в Git, а не в кластер руками, поэтому не бывает «правку внесли на проде и забыли про стейдж». Если фактическое состояние разошлось с описанным, синхронизация возвращает его к репозиторию, и инцидент не разрастается.
Сравнение подходов: шифрование в репозитории и внешние хранилища
Оба подхода убирают ручное создание секретов в кластере, но платят за это разным. Шифрование файлов оставляет ключ расшифровки внутри кластера и требует перешифровки при каждой ротации; внешнее хранилище добавляет сетевую зависимость и второй контур отказоустойчивости. Выбор определяют число кластеров, частота ротации и требование доказать, кто и когда читал значение.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Шифрование файлов в репозитории (SOPS, Sealed Secrets) | один-два кластера, небольшая команда, десятки секретов | ключ расшифровки всё равно в кластере; отзыв доступа — перешифровка всех файлов |
| Внешнее хранилище и оператор синхронизации (ESO) | мультикластер, несколько команд, ротация по расписанию | нужен отказоустойчивый контур хранилища и сетевая доступность; свой класс отказов |
| Гибрид: загрузочные секреты в репозитории, рабочие — во внешнем | доступы к хранилищу и первичная инициализация | два набора прав и две процедуры ротации |
Чем платят за шифрование файлов в репозитории
Ключ расшифровки живёт в кластере, поэтому разделение прав на расшифровку выходит грубым: доступ к пространству имён открывает все секреты в нём. Ротация — это перешифровка всех файлов и новый коммит, а прежние версии шифротекста остаются в истории репозитория. Диффы нечитаемы: ревью показывает смену блоба, а не изменение значения.
Когда оправдано внешнее хранилище
Хранилище оправдано, когда секретов сотни, кластеров больше двух, а ротация идёт по расписанию: отзыв доступа мгновенный, журнал обращений фиксирует чтения. Цена — сетевой доступ становится критичным путём: если оператор не кеширует значения, недоступность хранилища останавливает выкатку.
Этапы внедрения: аудит, схема, настройка, проверка, передача
Порядок работ опирается на принцип: сначала фиксируем фактическое состояние, затем проектируем контур и только потом меняем рабочие окружения. Секреты переносятся по одному, поэтому релизы не останавливаются.
Как выглядит аудит текущего состояния
Инвентаризация занимает один-два дня и не требует доступа к значениям самих секретов. Собираем, где они лежат сейчас — переменные окружения, файлы на серверах, значения в репозиториях, ручные записи в базах, — кто их читает, что происходит при ротации и у кого на руках мастер-ключи. На выходе — карта зависимостей и перечень мест, где секрет попадает в открытом виде: история коммитов, логи сборки, дампы конфигурации.
- Аудит обращения с секретами — карта зависимостей, точки утечки, критичные сервисы.
- Схема контура доставки — что шифруется в репозитории, что живёт во внешнем хранилище, как значение попадает в под.
- Настройка политик доступа — роли, пространства имён, область видимости ключей.
- Миграция существующих секретов — по одному, со временной параллельной работой старой и новой схемы.
- Встраивание в конвейер сборки и релиза — проверки на попадание открытых значений в коммит.
- Проверка отказа и восстановления — рестарт, потеря узла, отзыв ключа, откат релиза.
- Передача контура команде — доступы, регламент ротации, разбор с дежурными.
Как проходит приёмка контура заказчиком
Приёмка — это прогон сценариев на копии контура, а не демонстрация: добавляем секрет, меняем значение, отзываем доступ, выводим из строя один узел и смотрим, восстанавливается ли выдача. Заказчик повторяет ключевые сценарии вместе с нашими инженерами, получает журнал проверок и регламент ротации — после этого контур считается принятым.
Схемы доступа, политики ротации и документация контура
Пакет документации собираем так, чтобы дежурная смена и новый инженер разбирались в контуре без нас. Материалы лежат рядом с манифестами в том же репозитории и меняются через проверку, а не письмом в почте.
- Схема контура: среды и границы доверия, какие хранилища секретов подключены к репозиторию и как связаны между собой.
- Политики доступа: роли на чтение и запись, разграничение по средам, принцип наименьших прав, порядок выдачи и отзыва доступа.
- Регламент ротации: таблица секретов с периодом замены, порядок смены ключа шифрования, кто запускает ротацию и по каким признакам подтверждает результат.
- Инструкция по восстановлению: что делать при потере корневого ключа или компрометации — от отзыва значений до проверки, что нагрузки получили новые.
- Документация окружения: перечень пространств имён, привязка сервисов к хранилищам, назначение переменных, действия при расхождении.
- Матрица ответственности: кто владеет контуром, кто дежурит, к кому идти при инциденте.
Как эти материалы живут после передачи
Документы версионируются вместе с манифестами: изменения к ним проходят такую же проверку, поэтому инструкция не расходится с фактическим состоянием контура. Раз в квартал сверяем регламент ротации с журналом изменений — если секрет заменяли вне графика, причина попадает в документ.
Восстановление отдельно проверяем на учебном контуре. Если шаги не сходятся, правим инструкцию, а не договариваемся на словах. Так пакет остаётся рабочим инструментом, а не папкой, открытой один раз при приёмке.
Кейс: вывод секретов из репозитория без простоя сервисов
Контур из трёх кластеров и полусотни сервисов держал секреты прямо в репозиториях: токены баз, ключи внешних систем, сертификаты. Читать их мог любой с доступом к проекту, а история правок хранила старые значения. Переводили поэтапно — сначала пилот на некритичных сервисах, потом рабочие, — чтобы не останавливать сервисы.
Что было до
Ротация одного ключа растягивалась на две-три недели: правку готовили руками, согласовывали, ждали окно обслуживания и перезапускали сервисы. Откат изменения означал восстановление из резервной копии и сверку значений вручную, пока часть контура работала со старым ключом. Замеры до: вне репозитория — ноль секретов, средняя ротация — 18 дней, простой при выкатке — до 40 минут.
Что стало после
Шифрование в репозитории закрыли через Sealed Secrets: расшифровка возможна только в кластере, а приложения получают значения по ролям. Ротация в рабочем контуре — один коммит в защищённую ветку, значение расходится по всем кластерам за десятки минут без остановки сервисов. Откат — обычный revert коммита, проверка на боевом контуре идёт на пилоте раньше рабочих кластеров.
«Мы проверяли схему на боевом контуре на каждом шаге: сначала пилот, потом рабочие. Главное — ротация перестала быть событием с простоем и окном обслуживания», — инженер команды.
Как ротировать секреты в GitOps, не останавливая сервисы?
Секрет попадает в pod не сам по себе: его подставляет агент, а приложение читает переменную при старте. Значит, ротация — это не замена значения в хранилище, а последовательность: сначала выпускаем вторую версию, потом переключаем потребителей, и только затем отзываем старую.
Ключевой приём — окно перекрытия доступов. В хранилище одновременно живут две версии: новая и предыдущая, ещё валидная. Приложение получает новую через External Secrets Operator, а старая остаётся рабочей, пока последний экземпляр не перейдёт на неё. Если один pod отстал или держит соединение с внешним ресурсом, он продолжает работать — ротация без простоя держится именно на этом перекрытии.
Дальше — проверка живости. Поды заменяются поочерёдно, не более одного за раз: проба готовности и реальный запрос к зависимому ресурсу подтверждают, что новый доступ действительно принят. Только когда весь набор отвечает, окно ротации закрывается и старая версия отзывается.
Если проверка не прошла, срабатывает автоматический откат: возвращаем предыдущую версию секрета, поды перечитывают её, состояние стабилизируется, а инженер получает уведомление с причиной. Неудачная ротация превращается в один лишний перезапуск вместо простоя.
Практика простая: ротируем по одному сервису, окно перекрытия держим коротким, время выбираем вне пика нагрузки и ведём журнал выпущенных версий. Ротировать всё сразу — самый надёжный способ получить тот самый простой, которого мы избегаем.
Инженерные сомнения: шифрование, доступ, откат, аудит
Технические возражения у команд заказчика почти всегда одни и те же, поэтому отвечаем порядком действий и границами применимости, а не обещаниями. Схема работает там, где секреты описаны декларативно и появляются в кластере из git или внешнего хранилища.
Кто и где расшифровывает секрет?
Зависит от инструмента. Sealed Secrets раскрывает значение только контроллер внутри кластера — приватный ключ не попадает ни в репозиторий, ни на рабочие станции инженеров. SOPS хранит шифротекст в git и раскрывает его ключом age или GPG на этапе применения. External Secrets Operator значения в репозитории не держит: в git лежит ссылка на запись во внешнем хранилище, а объект собирается в кластере.
Как разграничить права между командами и окружениями?
Права делятся на два контура: доступ к git и доступ к расшифровке. В репозитории работают обязательное согласование и CODEOWNERS по каталогам окружений, а ключи расшифровки выдаются отдельно на каждый стенд. Тогда разработчик правит манифест тестового окружения, но не может раскрыть секреты промышленного контура.
Что происходит при откате на предыдущий релиз?
Откат — это revert коммита: прежняя версия секрета возвращается тем же применением, что и любое другое изменение. Условие одно — значение должно оставаться в источнике. Контроллер кластера или внешнее хранилище держат историю версий, иначе откат вернёт ссылку без данных, и под с секретом не поднимется.
Как устроен аудит доступа к секретам?
Аудит сшивается из трёх журналов: история коммитов и автор изменения в git, журнал обращений к API кластера, журнал выдач во внешнем хранилище. По имени секрета и времени видно, кто менял объект, какой контроллер его прочитал и был ли доступ вне обычного контура. Секреты, которые нельзя положить в git даже зашифрованными — корневые токены, начальная конфигурация, ключи самого хранилища, — выносим в отдельный контур ручного ввода и в репозиторий не переносим.
Обсудим задачу и вернёмся с оценкой и планом работ
Секреты в GitOps ломаются не на этапе установки контроллера, а на стыках: расшифровка внутри кластера, ротация, права служебных учётных записей, поведение при откате на предыдущую ревизию. Чтобы оценка объёма была предметной, а не «плюс-минус», начинаем с разбора текущей схемы — как она устроена у вас сейчас.
Что разбираем на созвоне:
- Разбор текущей схемы: где источник истины для секретов, как они попадают в репозиторий, что и на каком шаге расшифровывается.
- Точки отказа: хранение ключей шифрования, доступы служебных учётных записей, расхождения между окружениями, сценарий отката.
- Сравнение вариантов — Sealed Secrets, SOPS, внешний оператор секретов — с ограничениями каждого применительно к вашей схеме, а не в общем виде.
- Порядок шагов: что переносим первым, где оставляем ручной контур на переходный период, как проверяем, что секрет доехал.
- Оценка объёма: состав правок в манифестах и ролях, регламент ротации, зона ответственности за ключи.
- Что остаётся у команды: документация, шаблоны секретов, проверки в конвейере поставки до применения изменений.
Такой разбор занимает один разговор и сразу показывает, где вы уже закрыты, а где остаётся ручная работа. Опишите задачу — текущий контур, масштаб и ограничения по доступам. Вернёмся с оценкой и планом работ.
