Všechny postupy
Ve výstavbě · pracovní verze vyžaduje release manifest

Technický postup

Parametry, hesla a Vault

Jak oddělit běžnou konfiguraci od tajemství a změnit prostředí bez přestavby image.

Pro koho
Implementátor, provozní správce, bezpečnost, správce Vaultu
Výsledek
Image zůstávají stejné mezi prostředími, konfigurace je dohledatelná a žádné heslo neleží v repozitáři ani v dokumentaci.

01

1. Co patří do .env

  • URL služby, volba režimu, časová zóna, názvy databází a další nesekretní parametry.
  • Úplné image reference s digestem, pokud je soubor řízenou součástí release.
  • Přepínače funkcí, které release výslovně podporuje a validuje.
  • Nikdy skutečné heslo, privátní klíč, přístupový token, klientský secret ani přihlašovací údaj k registry v souboru verzovaném Gitem.

02

2. Doporučené rozložení na hostiteli

Pracovní vzorHodnoty <…> doplňte z release
/etc/sifybox/
├── env/
│   ├── release.env       # image + digest, bez hesel
│   └── site.env          # URL, režimy a nesekretní parametry
└── secrets/              # root:root, adresář 0700, soubory 0400
    ├── db_password
    └── oidc_client_secret

Pozor: Soubor .env není správce tajemství. Přihlášení k registry řeší credential helper nebo řízený docker login s deploy tokenem; samotný Compose secret stažení image neautorizuje. Citlivé hodnoty zůstávají mimo Git, s minimálními právy a popsanou rotací.

03

3. Varianta Docker secrets

Cílový standard — názvy souborů a podporu proměnných _FILE musí potvrdit manifest konkrétního release.

  1. DERS dodá seznam očekávaných secrets a potvrzený způsob jejich načtení.
  2. Správce vytvoří každý secret mimo checkout a nastaví vlastnictví a oprávnění.
  3. Compose secret připojí pouze do služby, která jej potřebuje.
  4. Aplikace nesmí hodnotu vypsat při startu ani při validační chybě.
  5. Rotace se provede podle runbooku služby a ověří se novým přihlášením nebo spojením.

04

4. Varianta HashiCorp Vault

Cílový standard — způsob autentizace, obnovy lease a reloadu musí potvrdit konkrétní služba a release.

  1. Služba nebo Vault Agent se autentizuje strojovou identitou svázanou s konkrétním prostředím; nepoužívá sdílený osobní token.
  2. Politika povolí jen konkrétní cesty a operace potřebné dané službě.
  3. Vault Agent zapíše secret do tmpfs souboru nebo jej poskytne aplikaci podporovaným mechanismem.
  4. Obnova krátkodobých údajů vyvolá podporovaný reload nebo řízený restart.
  5. Audit Vaultu, aplikační audit a provozní logy se korelují bez zapsání samotné tajné hodnoty.

05

5. Pořadí načtení a validace

  1. Načíst výchozí hodnoty zabudované v release pouze pro nesekretní volby.
  2. Načíst release.env a site.env.
  3. Převzít secrets ze souborů nebo Vaultu; tajná hodnota nikdy nemá bezpečný univerzální default.
  4. Při chybějící povinné hodnotě skončit před startem s názvem parametru, nikoli s jeho obsahem.
  5. Vypsat sanitizovaný konfigurační souhrn: režim, cílové URL, verze a zdroj secretu, ale ne secret.
  6. Spustit connectivity testy a teprve potom přijmout provozní požadavky.

06

6. Rotace bez ručního přepisování

  • Každý secret má vlastníka, zdroj, dobu platnosti a způsob obnovy.
  • Dynamické údaje z Vaultu mají lease a automatické obnovení.
  • OIDC klientské secrets se mění překryvem staré a nové hodnoty, pokud to podporuje IdP a aplikace.
  • Nouzová rotace má vlastní postup a nezávisí na člověku, který instalaci původně provedl.
  • Po rotaci se ověřuje funkce služby a audit; stará hodnota se zneplatní až po potvrzení.