Управление конфигурациями и секретами

Управление конфигурациями и секретами

1) Зачем это нужно

• Предсказуемыми (схемы, валидация, версии).
• Безопасными (шифрование, минимальные права, ротация).
• Управляемыми (GitOps, аудит, откаты).
• Динамическими там, где это оправдано (feature flags, параметризация лимитов).

2) Классификация артефактов

Публичные конфиги: фичи, пороги, таймауты, feature flags (без секретов).
Чувствительные конфиги: параметры, которые меняют поведение критичных путей (например, лимиты выплат).
Секреты: пароли/ключи/токены/сертификаты/материалы шифрования.
Артефакты доверия: корневые/промежуточные сертификаты, политики PKI, ключи KMS.

Принцип раздельного хранения и прав: публичные ≠ чувствительные ≠ секреты.

3) Иерархия конфигураций

1. Global defaults (org-wide).

2. Environment (`prod/stage/dev`).

3. Region (`eu-central-1`, `us-east-1`).

4. Tenant/Brand (для мульти-тенантов).

5. Service (конкретный микросервис).

6. Override (runtime) — временные переключатели.

Правила слияния: «ниже побеждает», конфликт — только через MR/approval.

Пример (YAML)

yaml defaults:
http:
timeout_ms: 800 retry: 2 prod:
http:
timeout_ms: 1200 service: payments-api overrides:
eu-central-1:
http:
timeout_ms: 1500

4) Схемы и валидация

Каждый конфиг — контракт со схемой (JSON Schema/OPA/валидаторы в CI).

Типы, диапазоны, обязательные поля, значения по умолчанию.
«Guard-правила» (нельзя поставить `retry>5`, `p95_target<50ms`).
Автоматическая проверка в CI и при применении (admission-webhook/KRM).

Фрагмент JSON Schema

json
{
"type":"object",
"properties":{
"http":{"type":"object","properties":{"timeout_ms":{"type":"integer","minimum":100,"maximum":10000},"retry":{"type":"integer","minimum":0,"maximum":5}},"required":["timeout_ms"]},
"feature_flags":{"type":"object","additionalProperties":{"type":"boolean"}}
},
"required":["http"]
}

5) Модели доставки конфигов

Static (image-baked): надежно, но требует рестартов.
Push/Watch: агенты/sidecar получают обновления (stream/poll) и сигналят приложению.
Pull on startup: получаем снапшот при старте (упростить hot-path).
Edge cache/proxy для гео-распределенных нагрузок.

Главное: атомарность и версионирование снапшотов, контроль совместимости и быстрый откат.

6) Инструменты и роли

Хранилища конфигов: Git (источник правды) + GitOps (Argo/Flux), Parameter Store/Config Service.
Хранилища секретов: Vault, AWS Secrets Manager/SSM, GCP Secrets, Azure KV.
Шифрование: KMS/HSM, SOPS (age/GPG/KMS), Sealed Secrets, Transit-шифрование (Vault).
Доставка: CSI Secrets Store, Vault Agent Injector/Sidecar, init-контейнеры.
Флаги/динамика: платформа фича-флагов (вкл. аварийные kill-switch).

7) Шифрование: модели и практики

At rest: KMS-ключи проекта/окружения, envelope-шифрование.
In transit: TLS/mTLS со взаимной аутентификацией.
At use: дешифрация как можно позже, предпочтительно — в памяти процесса/sidecar (без записи на диск).
Ключевая иерархия: root (HSM) → KMS CMK → data keys (DEK).
Ротация: календарная (90/180 дней) + по событию (компрометация/уход сотрудника).

8) Управление секретами: паттерны

8.1 GitOps + SOPS (статический снапшот)

В Git хранится только шифротекст.
Дешифровка в CI/CD или на кластере (KMS/age).
Применение через контроллер (Flux/Argo) → Kubernetes Secret.

yaml apiVersion: v1 kind: Secret metadata: { name: psp-keys, namespace: payments }
type: Opaque data:
apiKey: ENC[AES256_GCM,data:...,sops]

8.2 Vault Agent Injector (динамическая выдача)

Сервисная учетка (JWT/SA) аутентифицируется в Vault.
Sidecar кладет креды в tmpfs и обновляет по TTL.
Поддержка динамических кредов (DB, cloud — изоляция и короткий срок).

yaml annotations:
vault. hashicorp. com/agent-inject: "true"
vault. hashicorp. com/role: "payments-api"
vault. hashicorp. com/agent-inject-secret-db: "database/creds/payments"

8.3 CSI Secrets Store

Примонтировать секрет как volume, ротация прозрачно.
Для PKI — автоматическое обновление сертификатов/ключей.

9) Kubernetes: практические аспекты

ConfigMap — только публичные/нечувствительные данные.
Secret — чувствительные (с base64 — не шифрование; включите Encryption at Rest для etcd).
Checksum-аннотации: рестарт Deployment при изменении конфига.
Admission-контроль: запрет монтирования секретов не из «белого списка», запрет «plain» паролей в манифестах.
NetworkPolicy: ограничить доступ к провайдерам секретов (Vault/CSI).

Checksum пример (Helm)

yaml annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}

10) Политики доступа (RBAC/ABAC)

Least privilege: сервис видит только свои секреты; доступ по namespace/label/prefix.
Split duties: создание секрета ≠ чтение содержимого; аудит любых чтений.
Временные креды: динамические логины (DB, cloud) с TTL и автоматической ротацией.
Сегментация: prod/stage в разных проектах/аккаунтах/KMS-ключах.

11) Аудит, журналирование, наблюдаемость

Логи чтения/выдачи секретов: кто/когда/что/откуда; корреляция с релизами и инцидентами.
Метрики: частота обращений, истекающие секреты, просроченные сертификаты, доля динамических кредов.
События безопасности: превышение квот, аномалии по IP/времени, множественные неуспешные аутентификации.

12) Ротация секретов и сертификатов

Стандартизируйте сроки: API-ключи — 90 дней, DB-пароли — 30 дней, TLS-серты — 60–90 дней.
Контур ротации: генерация → тест → двойная публикация (grace) → переключение → отзыв старого → верификация.
Безотказность: двойная запись конфигов/секретов, совместимость клиентов (accept new+old).
PKI: собственный CA или интеграция с внешним; автоматическое обновление mTLS-материалов через CSI/Vault.

13) Динамические конфиги и feature flags

«Горячие» параметры (лимиты, таймауты) берите из конфиг-сервиса/флаг-платформы.
Локальный кэш и stickiness (расчет варианта по хешу), короткие TTL.
SLO-охранители на изменение чувствительных параметров (авто-откат и kill-switch).

14) Интеграция с CI/CD и GitOps

Pre-commit/CI: линтеры схем, SOPS-проверки, запрет «голых» секретов (сканеры: gitleaks/trufflehog).
Policy Gate: OPA/Conftest — запрет конфигов без схемы/без аннотаций владельца/без меток среды.
Progressive delivery: промоушен конфигов как артефактов (semver), canary на изменение параметров.
Аннотации релизов: кто/какой конфиг/секрет менял; быстрая корреляция с p95/5xx.

15) Примеры

15.1 Политика OPA: запрет открытых SG в конфиге

rego package policy. config

deny[msg] {
input. kind == "SecurityGroupRule"
input. cidr == "0. 0. 0. 0/0"
input. port = = 5432 msg: = "Postgres open internet banned"
}

15.2 Пример «снапшота» конфига (версионируемый)

yaml version: 1. 12. 0 owner: payments-team appliesTo: [ "payments-api@prod" ]
http:
timeout_ms: 1200 retry: 2 withdraw:
limits:
per_txn_eur: 5000 per_day_eur: 20000 flags:
new_withdrawal_flow: false

15.3 Vault — динамические креды БД

hcl path "database/creds/payments" {
capabilities = ["read"]
}
role issues user/password with TTL = 1h and auto-rollover

16) Анти-паттерны

Секреты в Git в открытом виде / в переменных Helm/Ansible без шифрования.
Единый «мега-секрет» для всех сервисов/окружений.
Долгоживущие токены без TTL/ротации; «бессмертные» сертификаты.
Динамические конфиги без схем/валидации и без аудита изменений.
Отсутствие Encryption at Rest для etcd/KMS и сети без mTLS.
Ручные правки конфигов в проде (обход GitOps).
Доступ разработчикам к прод-секретам «на всякий случай».

17) Чек-лист внедрения (0–60 дней)

0–15 дней

Включить схемы/валидаторы для конфигов; завести репо «configs» и GitOps-поток.
Поднять KMS и шифрование: SOPS/Sealed Secrets/Encryption at Rest в etcd.
Запретить плейнтекст-секреты в CI (сканеры), ввести owners/approvals.

16–30 дней

Разделить хранилища: публичные конфиги vs чувствительные vs секреты.
Внедрить Vault/Secrets Manager, выбрать путь доставки (Agent/CSI/SOPS).
Настроить ротацию TLS/DB/PSP-кредов; дашборды «срок жизни/истекающие».

31–60 дней

Динамические конфиги и флаги с SLO-гейтингом и авто-откатом.
Политики OPA/Conftest; zero-trust (namespace/label-scoped доступ).
Game-day: симуляция утечки секрета и форс-ротации.

18) Метрики зрелости

% секретов под шифрованием и без прямого доступа из Git = 100%.
Покрытие конфигов схемами/валидацией ≥ 95%.
Среднее время ротации критичных секретов (цель: часы, не дни).
Доля динамических кредов (DB/cloud) ≥ 80%.
0 инцидентов из-за «plain secrets»/просроченных сертификатов.
MTTR при ошибке конфига с откатом < 5 минут.

19) Командные роли и процессы

Config Owner: владелец домена/схем/политик.
Security: политики, ключевая иерархия, аудит доступа.
Platform/SRE: GitOps, поставка/инжекция, телеметрия.
App Teams: потребление конфигов/секретов, тесты совместимости.

20) Заключение

Надежный контур конфигураций и секретов — это схемы + GitOps + шифрование + ротация + политика. Разделяйте публичное и секретное, шифруйте все, применяйте конфиги атомарно и версионируемо, минимизируйте права и срок жизни кредов, автоматизируйте ротации и аудит. Тогда изменения станут быстрыми и безопасными, а риск утечек и падений — минимальным.