Konfigurations- und Secret-Management

Verwaltung von Konfigurationen und Geheimnissen

1) Warum es notwendig ist

• Vorhersehbar (Schemata, Validierung, Versionen).
• Sicher (Verschlüsselung, Mindestrechte, Rotation).
• Verwaltet (GitOps, Audit, Rollbacks).
• Dynamisch, wo dies gerechtfertigt ist (Feature Flags, Parametrisierung von Limits).

2) Klassifizierung von Artefakten

Öffentliche Configs: Fichi, Stromschnellen, Timeouts, Feature Flags (keine Geheimnisse).
Sensitive Configs: Parameter, die das Verhalten kritischer Pfade verändern (z.B. Auszahlungslimits).
Geheimnisse: Passwörter/Schlüssel/Token/Zertifikate/Verschlüsselungsmaterialien.
Vertrauensartefakte: Stamm-/Stagingzertifikate, PKI-Richtlinien, KMS-Schlüssel.

Das Prinzip der getrennten Speicherung und Rechte: öffentliche ≠ sensible ≠ Geheimnisse.

3) Hierarchie der Konfigurationen

1. Global defaults (org-wide).

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

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

4. Tenant/Brand (für Multi-Tenants).

5. Service (spezifischer Microservice).

6. Override (Laufzeit) - Zeitschalter.

Fusionsregeln: „unten gewinnt“, Konflikt nur durch MR/approval.

Beispiel (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) Schemata und Validierung

Jedes config ist ein Vertrag mit einem Schema (JSON Schema/OPA/Validators in CI).

Typen, Bereiche, Pflichtfelder, Standardwerte.
„Guard-Regeln“ ('retry> 5', 'p95 _ target <50ms' kann nicht gesetzt werden).
Automatische Validierung im CI und in der Anwendung (Admission-Webhook/KRM).

JSON Schema-Fragment

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) Config Liefermodelle

Statisch (image-baked): zuverlässig, erfordert aber Neustarts.
Push/Watch: Agenten/sidecar erhalten Updates (Stream/Poll) und signalisieren der App.
Pull on startup: Wir erhalten beim Start einen Snapshot (vereinfachen den Hot-Path).
Edge Cache/Proxy für geo-verteilte Lasten.

Die Hauptsache: Atomarität und Versionierung von Snapshots, Kompatibilitätskontrolle und schnelles Rollback.

6) Werkzeuge und Rollen

Config-Speicher: Git (Quelle der Wahrheit) + GitOps (Argo/Flux), Parameter Store/Config Service.
Geheime Tresore: Tresor, AWS Secrets Manager/SSM, GCP Secrets, Azure KV.
Verschlüsselung: KMS/HSM, SOPS (Alter/GPG/KMS), Versiegelte Geheimnisse, Transit-Verschlüsselung (Vault).
Lieferung: CSI Secrets Store, Vault Agent Injector/Sidecar, Init-Container.
Flaggen/Lautsprecher: Plattform der Ficha-Flaggen (inkl. Notkill-Schalter).

7) Verschlüsselung: Modelle und Praktiken

Bei Rest: KMS-Schlüssel des Projekts/der Umgebung, Envelope-Verschlüsselung.
Im Transit: TLS/mTLS mit gegenseitiger Authentifizierung.
Bei Verwendung: Entschlüsselung so spät wie möglich, vorzugsweise im Prozess/sidecar-Speicher (ohne Brennen auf Disc).
Schlüsselhierarchie: root (HSM) → KMS CMK → data keys (DEK).
Rotation: Kalender (90/180 Tage) + nach Veranstaltung (Gefährdung/Weggang des Mitarbeiters).

8) Verwaltung von Geheimnissen: Muster

8. 1 GitOps + SOPS (statischer Schnappschuss)

In Git wird nur der Chiffretext gespeichert.
Entschlüsselung in CI/CD oder auf einem Cluster (KMS/Alter).
Anwendung über Controller (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 (dynamische Ausgabe)

Das Servicekonto (JWT/SA) wird im Vault authentifiziert.
Sidecar setzt Credits in tmpfs und aktualisiert durch TTL.
Unterstützung dynamischer Credits (DB, Cloud - Isolation und Short Term).

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

Primonte das Geheimnis als Volumen, Rotation transparent.
Für PKI - Automatische Aktualisierung von Zertifikaten/Schlüsseln.

9) Kubernetes: praktische Aspekte

ConfigMap - nur öffentliche/unempfindliche Daten.
Secret - empfindlich (mit base64 - nicht Verschlüsselung; Encryption at Rest für etcd aktivieren).
Checksum-Annotationen: Neustarten des Deployments beim Ändern des Config.
Admission-Kontrolle: Verbot der Installation von Geheimnissen, die nicht auf der „weißen Liste“ stehen, Verbot von „Plain“ -Passwörtern in Manifesten.
NetworkPolicy: Einschränkung des Zugangs zu Secret Providern (Vault/CSI).

Checksum-Beispiel (Helm)

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

10) Zugriffsrichtlinien (RBAC/ABAC)

Least privilege: der Service sieht nur seine Geheimnisse; Zugriff über namespace/label/prefix.
Split duties: Erstellen eines Geheimnisses ≠ Lesen des Inhalts; Prüfung aller Lesungen.
Temporäre Credits: dynamische Logins (DB, Cloud) mit TTL und automatischer Rotation.
Segmentierung: prod/stage in verschiedenen Projekten/Accounts/KMS-Keys.

11) Auditierung, Protokollierung, Beobachtbarkeit

Protokolle zum Lesen/Ausgeben von Geheimnissen: wer/wann/was/woher; Korrelation mit Releases und Incidents.
Metriken: Fallhäufigkeit, auslaufende Geheimnisse, abgelaufene Zertifikate, Anteil dynamischer Credits.
Sicherheitsereignisse: Quotenüberschreitungen, IP/Zeit-Anomalien, mehrere fehlgeschlagene Authentifizierungen.

12) Rotation von Geheimnissen und Zertifikaten

Standardisieren Sie Fristen: API-Schlüssel sind 90 Tage, DB-Passwörter sind 30 Tage, TLS-Serts sind 60-90 Tage.
Rotationsschleife: Generierung → Test → Doppelpublikation (Grace) → Umschalten → Widerruf des Alten → Verifizierung.
Ausfallsicherheit: Doppelaufzeichnung von Konfig/Secrets, Kundenkompatibilität (accept new + old).
PKI: eigene CA oder Integration mit einer externen; automatische Aktualisierung von mTLS-Materialien über CSI/Vault.

13) Dynamische Configs und Feature-Flags

Nehmen Sie die „heißen“ Parameter (Limits, Timeouts) aus dem Config-Service/der Flag-Plattform.
Lokaler Cache und Stickiness (Berechnung der Variante nach Hash), kurze TTL.
SLO-Wächter zum Ändern empfindlicher Parameter (Auto-Rollback und Kill-Switch).

14) Integration mit CI/CD und GitOps

Pre-commit/CI: Schema-Linter, SOPS-Checks, Verbot von „nackten“ Geheimnissen (Scanner: gitleaks/trufflehog).
Policy Gate: OPA/Conftest - Verbot von Config ohne Schema/ohne Besitzer Anmerkungen/ohne Medium-Tags.
Progressive Lieferung: Förderung von Configs als Artefakte (semver), canary auf Parameter ändern.
Anmerkungen zu den Veröffentlichungen: wer/welche config/Geheimnis verändert; schnelle Korrelation mit p95/5xx.

15) Beispiele

15. 1 OPA-Politik: Verbot offener SG im Konfig

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 Beispiel „Snap Shot“ Config (versionierbar)

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 - dynamische DB-Credits

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

16) Anti-Muster

Geheimnisse in Git im Klartext/in Helm/Ansible Variablen ohne Verschlüsselung.
Ein einziges „Mega-Geheimnis“ für alle Dienste/Umgebungen.
Langlebige Token ohne TTL/Rotation; „Unsterbliche“ Zertifikate.
Dynamische Configs ohne Schemata/Validierung und ohne Änderungsaudit.
Keine Verschlüsselung bei Rest für etcd/KMS und Netzwerk ohne mTLS.
Manuelle Bearbeitungen von Config in Proda (GitOps Bypass).
Zugriff der Entwickler auf Prod-Geheimnisse „nur für den Fall“.

17) Checkliste Umsetzung (0-60 Tage)

0-15 Tage

Schemen/Validatoren für Config einbeziehen; Starten Sie die Repos "configs' und GitOps-Stream.
Erhöhen Sie KMS und Verschlüsselung: SOPS/Versiegelte Geheimnisse/Verschlüsselung bei Rest in etcd.
Plaintext-Geheimnisse in CIs (Scannern) verbieten, owners/approvals eingeben.

16-30 Tage

Tresore teilen: öffentliche Configs vs sensible vs Geheimnisse.
Vault/Secrets Manager implementieren, Lieferpfad auswählen (Agent/CSI/SOPS).
Konfigurieren Sie die Rotation von TLS/DB/PSP Credits; Dashboards „Lebensdauer/Ablauf“.

31-60 Tage

Dynamische Configs und Flags mit SLO-Gating und Auto-Rollback.
OPA/Conftest-Richtlinien; zero-trust (namespace/label-scoped access).
Game-Day: Simulation von geheimen Lecks und höherer Rotation.

18) Reifegradkennzahlen

% der Geheimnisse unter Verschlüsselung und ohne direkten Zugriff von Git = 100%.
Die Abdeckung von Configs mit Schemata/Validierung ≥ 95%.
Die durchschnittliche Rotationszeit kritischer Geheimnisse (Ziel: Stunden, nicht Tage).
Der Anteil dynamischer Credits (DB/Cloud) ≥ 80%.
0 Vorfälle aufgrund von "Plain Secrets'/abgelaufenen Zertifikaten.
MTTR bei einem Config-Fehler mit einem Rollback <5 Minuten.

19) Teamrollen und -prozesse

Config Owner: Eigentümer der Domäne/des Schemas/der Richtlinie.
Sicherheit: Richtlinien, Schlüsselhierarchie, Zugriffsprüfung.
Plattform/SRE: GitOps, Lieferung/Injektion, Telemetrie.
App Teams: Config/Secret-Konsum, Kompatibilitätstests.

20) Schlussfolgerung

Eine zuverlässige Kontur von Konfigurationen und Geheimnissen sind Schemata + GitOps + Verschlüsselung + Rotation + Politik. Trennen Sie öffentlich und geheim, verschlüsseln Sie alles, wenden Sie Konfigs atomar und versionierbar an, minimieren Sie die Rechte und die Lebensdauer von Credits, automatisieren Sie Rotationen und Audits. Dann werden die Änderungen schnell und sicher und das Risiko von Lecks und Stürzen ist minimal.