Доставка и эксплуатация секретов¶
Требования применяются к доставке, хранению, ротации и доступности runtime-
секретов. Уровни обязательности определены в корневом README.md.
INF-SEC-001. Допустимые источники секретов¶
Уровень: MUST
Применяется к: runtime-секретам
Kubernetes-цель должна получать секрет через SealedSecret, HashiCorp Vault или Kubernetes Secret, созданный управляемым pipeline/контроллером. Docker-цель MAY получать секрет через защищённые GitLab CI/CD Variables или внешнее secret storage. Открытое значение не должно храниться в Git, image, Compose-файле, Helm values, Kustomize overlay или CI artifact.
Способ доставки должен реализовывать architecture:BE-CONF-005,
architecture:BE-CONF-007 и architecture:SEC-SCRT-006–SEC-SCRT-009.
Обоснование¶
Base64 и шаблонизация не защищают открытый секрет в истории Git.
Проверка¶
- secret scan репозитория, image и artifacts;
- трассировка каждого secret reference к допустимому источнику.
Исключения¶
Публичное тестовое значение, не предоставляющее доступ, не является секретом.
INF-SEC-002. Sealed Secrets¶
Уровень: MUST
Применяется к: SealedSecret
SealedSecret должен шифроваться для требуемого кластера и namespace с минимальной областью расшифрования. Закрытый ключ контроллера должен резервироваться защищённо и иметь проверенную процедуру восстановления.
Обоснование¶
Потеря ключа делает Git-секреты невосстановимыми, а широкая область увеличивает последствия переноса ciphertext.
Проверка¶
- негативная расшифровка в другом namespace;
- rehearsal восстановления ключа контроллера.
Исключения¶
Cluster-wide scope требует обоснования общего секрета.
INF-SEC-003. Vault¶
Уровень: MUST
Применяется к: секрету HashiCorp Vault
Аутентификация workload должна использовать его идентичность, а policy — ограничивать точные paths и operations. Долгоживущий root token и общий token нескольких приложений запрещены. Lease и ротация должны соответствовать времени обновления приложения.
Обоснование¶
Динамическая идентичность и минимальная policy ограничивают утечку.
Проверка¶
- review auth role, policy, TTL и renew;
- негативный запрос чужого path.
Исключения¶
Статический секрет допустим, если система-источник не поддерживает динамический.
INF-SEC-004. Kubernetes Secret¶
Уровень: MUST
Применяется к: напрямую создаваемому Kubernetes Secret
Secret должен создаваться защищённым pipeline или контроллером, иметь ограниченный RBAC и не выводиться командой CI в job log. Использование Kubernetes Secret само по себе не должно считаться шифрованием значения в Git.
Обоснование¶
Secret защищён только границами доступа и конфигурацией etcd.
Проверка¶
- review pipeline masking, RBAC и audit;
- поиск значения в Git и job logs.
Исключения¶
Не допускаются.
INF-SEC-005. Ротация и отзыв¶
Уровень: MUST
Применяется к: production credential
Deployment- и secret-automation должны реализовывать процедуру ротации и отзыва
из architecture:SEC-SCRT-007–SEC-SCRT-009 без пересборки image. Результат
должен подтверждать доставку нового значения требуемым workload и отзыв
старого; владелец, срок и допустимое поведение при недоступности источника
берутся из архитектурного контракта проекта.
Обоснование¶
Секрет без ротации превращает временную утечку в постоянный доступ.
Проверка¶
- rehearsal ротации;
- тест запуска приложения с новым значением и отказа старого.
Исключения¶
Не допускаются.
INF-SEC-008. Шифрование Kubernetes Secrets в datastore¶
Уровень: MUST
Применяется к: production Kubernetes-платформе
Kubernetes API datastore должен шифровать Secret resources at rest проверенным encryption provider. Ключ шифрования должен храниться отдельно от backup datastore, иметь ограниченный доступ, ротацию и восстановление. Изменение configuration provider должно учитывать перешифрование существующих Secrets.
Обоснование¶
Kubernetes Secret по умолчанию не гарантирует шифрование значения в datastore.
Проверка¶
- проверка encryption configuration без вывода ключа;
- чтение сырого тестового значения из backup datastore;
- rehearsal ротации и восстановления ключа.
Исключения¶
Внешний KMS MAY управлять ключом при том же проверяемом результате.
INF-SEC-009. GitLab CI/CD Variables¶
Уровень: MUST
Применяется к: secret в GitLab CI/CD Variable
Production variable должна быть protected, environment-scoped и masked/hidden, если формат поддерживает masking. Многострочное значение должно передаваться через file-type variable. Job не должен передавать секрет в аргументе команды, debug trace или artifact; доступ к variable должен иметь только deployment job целевой среды.
Обоснование¶
Group-wide variable и аргумент процесса расширяют доступ за пределы цели.
Проверка¶
- review scope/protection и pipeline graph;
- canary-secret scan job log, process list и artifacts;
- запуск из незащищённой ветки.
Исключения¶
Невозможность masking из-за формата требует file-type variable и запрета вывода, но не разрешает изменить значение фиктивным способом.
INF-SEC-010. Минимальная доставка секрета в Pod¶
Уровень: MUST
Применяется к: Pod с несколькими containers или несколькими secrets
Каждый secret должен монтироваться или передаваться только в container, который его использует. Secret volume должен быть read-only. Приложение не должно получать список всех secrets namespace или token Kubernetes API только ради чтения собственного значения.
Обоснование¶
Компрометация sidecar не должна раскрывать несвязанный credential.
Проверка¶
- инспекция env, volumeMounts, projected volumes и RBAC;
- негативное чтение secret из другого container.
Исключения¶
Init container MAY получать тот же secret для подготовки данных, если временный результат не расширяет доступ.
INF-SEC-013. Доступность источника секретов¶
Уровень: MUST
Применяется к: production Vault, Sealed Secrets controller или иному компоненту доставки secrets
Владелец платформы должен определить HA/recovery profile, backup необходимого
state/keys, health и alert компонента. Должно быть проверено поведение уже
работающего workload, нового Pod и ротации при недоступном источнике. Fail-open
с устаревшим значением допускается только в пределах численного срока,
согласованного с architecture:SEC-SCRT-008.
Обоснование¶
Недоступность secret control plane может не затронуть старые Pod, но заблокировать restart, scaling и recovery.
Проверка¶
- отключение источника с существующим и новым Pod;
- восстановление state/key и последующая ротация;
- проверка alert и runbook.
Исключения¶
Статический Kubernetes Secret без внешнего контроллера применяет
INF-SEC-008, backup/recovery платформы и rotation procedure вместо HA
контроллера.