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

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

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 + шифрування + ротація + політика. Поділяйте публічне і секретне, шифруйте все, застосовуйте конфіги атомарно і версіоновано, мінімізуйте права і термін життя кредів, автоматизуйте ротації і аудит. Тоді зміни стануть швидкими і безпечними, а ризик витоків і падінь - мінімальним.