62. Správa tajemství (secrets management — Vault a alternativy)

Úvod a kontext

Každá netriviální aplikace potřebuje "tajemství" (secrets) — hesla
k databázi, API klíče třetích stran, privátní klíče pro TLS, tokeny
pro přístup do cloudu. Nejčastější chyba začátečníků je uložit tato
tajemství přímo do zdrojového kódu nebo do konfiguračních souborů,
které skončí v Gitu. Jakmile je tajemství jednou v historii Gitu, je
prakticky nevymazatelné a kdokoliv s přístupem k repozitáři (i bývalý
zaměstnanec, i útočník, který repozitář ukradl) ho má. Secrets
management je disciplína, jak tajemství ukládat, distribuovat
a rotovat bezpečně, odděleně od kódu.

Teorie

Proč proměnné prostředí nestačí samy o sobě

Běžný první krok je přesunout tajemství z kódu do proměnných
prostředí (DATABASE_PASSWORD=xyz). To je lepší než hardcoding, ale
má limity: proměnné prostředí se dají snadno vypsat (docker inspect,
/proc/<pid>/environ), nejsou verzované ani auditované (kdo a kdy
tajemství četl), a typicky se nerotují automaticky. Pro jednoduché
projekty to může stačit, ale pro produkční systém s víc službami je
potřeba robustnější řešení — centralizovaný secrets manager.

Co dělá secrets manager

Nástroj jako HashiCorp Vault, AWS Secrets Manager nebo Azure Key
Vault poskytuje:

• Centralizované šifrované úložiště — tajemství jsou uložená
  šifrovaně na jednom místě, ne rozesetá po desítkách konfiguračních
  souborů a proměnných prostředí.
• Řízení přístupu (access control) — přesně definujete, která
  aplikace nebo který uživatel smí přečíst které tajemství, podle
  principu nejmenších oprávnění.
• Audit log — každé čtení tajemství je zaznamenané: kdo, kdy,
  jaké tajemství. Při podezření na únik víte přesně, co prověřit.
  Souvisí s pozdější lekcí o compliance a auditu.
• Dynamická tajemství — pokročilejší funkce: místo statického
  hesla k databázi vygeneruje Vault dočasný účet s omezenou
  platností (např. na hodinu) při každém požadavku. Pokud dočasné
  heslo unikne, samo vyprší.
• Rotace — automatická nebo snadná pravidelná výměna tajemství,
  aniž by bylo nutné měnit kód nebo restartovat všechny služby ručně.

Architektura HashiCorp Vault

Vault běží jako server se šifrovaným úložištěm (tzv. storage backend
— může to být třeba Consul nebo integrované úložiště). Ve výchozím
stavu je zapečetěný (sealed) — data jsou zašifrovaná a nepřístupná,
dokud administrátor neprovede unseal (poskytne dostatek klíčových
fragmentů z tzv. Shamirova sdílení tajemství). Klienti (aplikace,
CI pipeline, lidé) se autentizují jednou z několika metod (token,
AppRole, integrace s Kubernetes ServiceAccount, LDAP) a na základě
politik (policies) dostanou přístup jen k těm cestám v úložišti,
které skutečně potřebují.

Alternativy a kdy je zvolit

• AWS Secrets Manager / Parameter Store — pokud jste už plně
  v AWS ekosystému, integrace je jednodušší než nasazovat vlastní
  Vault, ale jste vázáni na AWS.
• Kubernetes Secrets — vestavěné do Kubernetes, ale ve výchozím
  stavu jsou jen base64 zakódované (ne šifrované) v etcd — pro
  produkci se často kombinují s Vaultem nebo šifrováním etcd v klidu.
• SOPS (Secrets OPerationS) — jednodušší nástroj pro šifrování
  tajemství přímo v souborech uložených v Gitu (šifrovaný obsah je
  bezpečné commitnout), vhodné pro menší týmy bez potřeby centrálního
  serveru.

Vault je vhodná volba, pokud potřebujete centrální řešení napříč
více cloudy/on-premise, dynamická tajemství nebo pokročilé audit
požadavky; pro jednodušší jednocloudové projekty může stačit
nativní nástroj daného poskytovatele.

Praktický příklad

Základní práce s Vaultem přes CLI — uložení a přečtení statického
tajemství (KV verze 2 engine):

# Zapsání tajemství do cesty secret/aplikace/databaze
vault kv put secret/aplikace/databaze \
  username=app_user \
  password='S1lneHeslo!'

# Přečtení tajemství
vault kv get secret/aplikace/databaze

# Přečtení jen konkrétního pole, vhodné do skriptu
vault kv get -field=password secret/aplikace/databaze

Politika (policy), která povolí jen čtení tajemství aplikace, ne
zápis ani přístup jinam — ukázka principu nejmenších oprávnění:

# soubor: aplikace-policy.hcl
path "secret/data/aplikace/*" {
  capabilities = ["read"]
}

vault policy write aplikace-only aplikace-policy.hcl

Injekce tajemství z Vaultu do Kubernetes Podu pomocí anotací Vault
Agent Injectoru — kontejner dostane tajemství jako soubor bez toho,
aby ho aplikace musela sama volat přes API:

apiVersion: v1
kind: Pod
metadata:
  name: objednavky-app
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "objednavky-app"
    vault.hashicorp.com/agent-inject-secret-db-creds: "secret/data/aplikace/databaze"
spec:
  serviceAccountName: objednavky-app
  containers:
    - name: app
      image: registry.interni/objednavky:1.4.0

Vault Agent sidecar kontejner se autentizuje pomocí Kubernetes
ServiceAccount tokenu, stáhne tajemství podle role objednavky-app
a uloží ho do souboru uvnitř Podu (typicky
/vault/secrets/db-creds) — aplikace tak nikdy neuvidí Vault token
přímo a tajemství se nikdy neobjeví v manifestu ani v proměnné
prostředí viditelné přes docker inspect.

Shrnutí

Tajemství nepatří do kódu ani natvrdo do proměnných prostředí —
patří do centralizovaného, šifrovaného a auditovaného úložiště.
Secrets manager jako Vault poskytuje řízení přístupu podle principu
nejmenších oprávnění, audit log a volitelně dynamická, časově
omezená tajemství místo statických hesel. Alternativy jako AWS
Secrets Manager nebo SOPS jsou vhodné pro jednodušší nebo
jednocloudové scénáře; Vault vyniká v komplexnějších, multi-cloud
nebo vysoce regulovaných prostředích.

Kontrolní otázky

1. Proč je i uložení hesla do proměnné prostředí nedostatečné pro
   produkční systém, přestože je to lepší než hardcoding do kódu?
2. Co znamená "dynamická tajemství" a jakou konkrétní bezpečnostní
   výhodu přinášejí oproti statickému heslu?
3. Jak Vault Agent Injector v Kubernetes zajistí, že aplikace nikdy
   neuvidí přímo Vault token ani API volání?
4. Mini cvičení: napište Vault policy, která povolí aplikaci pouze
   čtení tajemství na cestě secret/data/platby/*, ne zápis ani
   přístup k jiným cestám.