Zarządzanie konfiguracjami i tajemnicami

Zarządzanie konfiguracjami i tajemnicami

1) Dlaczego go potrzebujesz

• Przewidywalne (schematy, walidacja, wersje).
• Bezpieczne (szyfrowanie, minimalne prawa, rotacja).
• Zarządzane (GitOps, audyt, rolki).
• Dynamika, w której jest uzasadniona (flagi funkcji, parametryzacja granic).

2) Klasyfikacja artefaktów

Konfiguracje publiczne: funkcje, progi, timeouts, flagi funkcji (brak tajemnic).
Konfiguracje wrażliwe: parametry, które zmieniają zachowanie ścieżek krytycznych (na przykład limity płatności).
Sekrety: hasła/klucze/tokeny/certyfikaty/materiały szyfrujące.
Artefakty zaufania: certyfikaty podstawowe/pośrednie, zasady PKI, klucze KMS.

Zasada oddzielnego magazynowania i praw: tajemnice „publiczne”.

3) Hierarchia konfiguracji

1. Default globalne (org-wide).

2. Środowisko („prod/stage/dev”).

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

4. Najemca/marka (dla wielu najemców).

5. Usługa (specyficzna mikroservice).

6. Nadjazd (czas trwania) - tymczasowe przełączniki.

Zasady łączenia: „poniżej wygrywa”, konflikt - tylko poprzez MR/zatwierdzenie.

Przykład (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) Systemy i walidacja

Każda konfiguracja jest umową z systemem (JSON Schema/OPA/walidatory w CI).

Typy, zakresy, wymagane pola, wartości domyślne.
„Zasady ochrony” (nie można ustawić na 'retry> 5', 'p95 _ target <50ms').
Automatyczna kontrola w CI i po zastosowaniu (admission-webhook/KRM).

Fragment schematu JSON

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) Modele dostawy Config

Statyczne (pieczone obrazem): niezawodne, ale wymaga ponownego uruchomienia.
Push/Watch :/sidecar agents receive updates (stream/poll) and signal the application.
Pociągnij za startup: dostajemy migawkę przy starcie (uprość gorącą ścieżkę).
Pamięć podręczna/proxy krawędzi dla obciążeń geo-rozproszonych.

Najważniejsze: atomowość i wersioning migawek, kontrola kompatybilności i szybki zwrot.

6) Narzędzia i role

Sklepy Config: Git (źródło prawdy) + GitOps (Argo/Flux), Parameter Store/Config Service.
Tajne repozytoria: Skarbiec, AWS Secrets Manager/SSM, GCP Secrets, Azure KV.
Szyfrowanie: KMS/HSM, SOPS (wiek/GPG/KMS), Zamknięte sekrety, Szyfrowanie tranzytu (Skarbiec).
Dostawa: CSI Secrets Store, Vault Agent Injector/Sidecar, init-containers.
Flagi/dynamika: platforma flagi funkcji (w tym wyłącznik awaryjny).

7) Szyfrowanie: Modele i praktyki

W spoczynku: klucze KMS projektu/środowiska, szyfrowanie koperty.
W tranzycie: TLS/mTLS z wzajemnym uwierzytelnianiem.
W użyciu: odszyfrowanie tak późno, jak to możliwe, najlepiej w pamięci procesowej/bocznej (bez zapisu na dysku).
Hierarchia kluczy: korzeń (HSM) → KMS CMK → klucze danych (DEK).
Rotacja: kalendarz (90/180 dni) + według zdarzeń (kompromis pracowniczy/wyjazd).

8) Tajne zarządzanie: wzory

8. 1 GitOps + SOPS (migawka statyczna)

Git przechowuje tylko szyfry.
Odszyfrowanie w CI/CD lub na klastrze (KMS/wiek).
Aplikacja za pośrednictwem kontrolera (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 wtryskiwacz środka skarbca

Konto serwisowe (JWT/SA) jest uwierzytelnione w Skarbcu.
Sidecar umieszcza kredyty w tmpfs i aktualizacje na TTL.
Wsparcie dla kredytów dynamicznych (DB, chmura - izolacja i krótkoterminowa).

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

Zamontuj sekret jako objętość, obrót jest przezroczysty.
Dla PKI - automatyczne odnawianie certyfikatów/kluczy.

9) Kubernetes: praktyczność

ConfigMap - tylko dane publiczne/nieczułe.
Secret - wrażliwe (z base64 - nie szyfrowanie; włącz szyfrowanie w odpoczynku dla etcd).
Adnotacje kontrolne: uruchom ponownie Wdrożenie przy zmianie konfiguracji.
Kontrola wstęp: zakaz montażu tajemnic nie z „białej listy”, zakaz „zwykłych” haseł w manifestach.
Polityka: ograniczenie dostępu do tajnych dostawców (Vault/CSI).

Przykład Checksum (Helm)

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

10) Polityka dostępu (RBAC/ABAC)

Najmniejszy przywilej: służba widzi tylko swoje tajemnice; dostęp przez przestrzeń nazw/etykieta/przedrostek.
Podział obowiązków: tworzenie tajnej treści do czytania; audyt wszystkich odczytów.
Kredyty tymczasowe: dynamiczne logowania (DB, cloud) z TTL i automatyczną rotacją.
Segmentacja: prod/etap w różnych projektach/kontach/kluczykach KMS.

11) Audyt, pozyskiwanie drewna, obserwowalność

Dzienniki czytania/wydawania tajemnic: kto/kiedy/co/gdzie; korelacja z uwolnieniami i incydentami.
Metryka: częstotliwość połączeń, utracone sekrety, utracone certyfikaty, udział kredytów dynamicznych.
Zdarzenia zabezpieczające - przekroczony przydział, anomalie IP/time, wiele nieudanych uwierzytelnień.

12) Rotacja tajemnic i certyfikatów

Standaryzuj warunki: klucze API - 90 dni, hasła DB - 30 dni, serty TLS - 60-90 dni.
Obrót: generacja → test → podwójna publikacja (grace) → przełączanie → cofnięcie starego → weryfikacja.
Niezawodność: podwójne wejście konfiguracji/tajemnic, kompatybilność klienta (akceptuj nowe + stare).
PKI: własny urząd certyfikacji lub integracja z zewnętrznym; Automatycznie aktualizuj zawartość mTLS poprzez CSI/Vault.

13) Konfiguracje dynamiczne i flagi funkcji

Pobierz parametry „gorące” (limity, terminy) z platformy config service/flag.
Lokalny pamięć podręczna i lepkość (obliczanie wariantu według hash), krótki TTL.
Osłony SLO do zmiany parametrów wrażliwych (auto-rollback i kill-switch).

14) Integracja z CI/CD i GitOps

Pre-commit/CI: lintery obwodów, kontrole SOPS, zakaz „nagich” tajemnic (skanery: gitleaks/trufflehog).
Brama zasad: OPA/Conftest - wyłączenie konfiguracji bez schematu/bez adnotacji właściciela/bez etykiet środowiskowych.
Progresywna dostawa: promocja konfiguracji jako artefaktów (semver), kanarka do zmiany parametrów.
Uwolnij adnotacje: kto/co config/secret zmienił; szybka korelacja z p95/5xx.

15) Przykłady

15. 1 Polityka OPA: Zakaz otwartych usług użyteczności publicznej w Config

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 Przykład migawki konfiguracyjnej (w wersji)

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 Skarbiec - dynamiczne kredyty w bazie danych

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

16) Anty-wzory

Sekrety w Git w przezroczystym tekście/w zmiennych Helm/Ansible bez szyfrowania.
Pojedynczy „mega-secret” dla wszystkich usług/środowisk.
Długotrwałe żetony bez TTL/rotacji; „nieśmiertelne” świadectwa.
Konfiguracje dynamiczne bez systemów/walidacji i bez zmian audytu.
Brak szyfrowania w odpoczynku dla sieci etcd/KMS i non-mTLS.
Ręczne edytowanie konfiguracji w produkcie (omijanie GitOps).
Dostęp do deweloperów do tajemnic handlowych „na wszelki wypadek”.

17) Lista kontrolna wdrażania (0-60 dni)

0-15 dni

Włączenie schematów/walidatorów dla konfiguracji; start repo "configs' i strumień GitOps.
Podnieś KMS i szyfrowanie: SOPS/Sealed Secrets/Encryption at Rest in etcd.
Zabronić tajemnic zwykłego tekstu w CI (skanerach), wprowadzić właścicieli/zatwierdzeń.

16-30 dni

Podziel skarbce: public configs vs sensitive vs secrets.
Implementacja Menedżera Skarbca/Tajemnic, wybierz ścieżkę dostawy (Agent/CSI/SOPS).
ustanowienie rotacji kredytów TLS/DB/PSP; deski rozdzielcze „żywotność/wygasająca”.

31-60 dni

Dynamiczne konfiguracje i flagi z SLO-gating i auto-rollback.
polityka OPA/Conftest; zero-trust (dostęp w przestrzeni nazw/na etykiecie).
Gra-day: symulacja tajnego wycieku i rotacji siły.

18) Wskaźniki zapadalności

% tajemnic pod szyfrowaniem i bez bezpośredniego dostępu z Git = 100%.
Zakres konfiguracji/walidacji ≥ 95%.
Średni czas na obrót tajemnic krytycznych (cel: godziny, nie dni).
Udział kredytów dynamicznych (DB/chmura) ≥ 80%.
0 incydentów z powodu „zwykłych tajemnic „/wygasłych certyfikatów.
MTTR w przypadku błędu konfiguracyjnego przy wałku <5 minut.

19) Role i procesy dowodzenia

Właściciel programu Config: właściciel domeny/schematu/zasad.
Bezpieczeństwo: polityka, kluczowa hierarchia, kontrola dostępu.
Platforma/SRE: GitOps, zasilanie/wtrysk, telemetria.
Zespoły aplikacji: konfiguracja/tajne zużycie, testy kompatybilności.

20) Wniosek

Niezawodny kontur konfiguracji i tajemnic to + GitOps + szyfrowanie + rotacja + schematy zasad. Oddzielne publiczne i tajne, szyfrować wszystko, stosować konfiguracje atomowo i versally, zminimalizować prawa i żywotność kredytów, zautomatyzować rotacje i audyty. Wtedy zmiany staną się szybkie i bezpieczne, a ryzyko wycieków i upadków będzie minimalne.