Jak spravujete centralizovanou konfiguraci a tajemství v rámci služeb?

Question

Accepted Answer

S desítkami služeb nemůžete spravovat konfiguraci a tajemství ad hoc pro každé nasazení. **Centralizovaná konfigurace** uchovává nastavení v jednom spravovaném zdroji a **správci tajemství** bezpečně ukládají citlivé hodnoty.

## Externalizovaná konfigurace

Konfigurace se nachází mimo artefakt buildu, takže stejný image běží v dev/staging/prod s různými nastaveními.

```yaml
# values injected at runtime, not baked into the image
DATABASE_URL: ${DB_URL}        # per-environment
FEATURE_NEW_CHECKOUT: "true"   # toggle without redeploy
PAYMENT_TIMEOUT_MS: "3000"
```

## Přístupy ke konfiguraci

| Přístup | Příklad |
|---|---|
| Config server | Spring Cloud Config, Consul |
| Nativní orchestrator | Kubernetes ConfigMaps |
| Správce tajemství | HashiCorp Vault, AWS Secrets Manager |

## Tajemství — udržujte je oddělená

Nikdy neukládejte tajemství do prostých ConfigMaps nebo do git.

```bash
# fetch a secret at startup, short-lived, audited
export DB_PASSWORD=$(vault kv get -field=password secret/orders/db)
```

## Dobré praktiky

```text
✓ Externalize config (12-factor): config in the environment
✓ Secrets in a dedicated manager with rotation + audit logs
✓ Dynamic refresh for non-secret toggles (no redeploy)
✗ Never commit secrets to source control
```

## Proč je to důležité

Centralizovaná konfigurace vám umožňuje měnit chování (timeouty, feature flags) a otáčet přihlašovací údaje v rámci mnoha služeb bez nutnosti opětovného buildu a opětovného nasazení každé jednotlivé.

Uchovávání tajemství ve skutečném správci tajemství — nikoli v image nebo v git — je základním požadavkem bezpečnosti, který se zvyšuje s počtem služeb.

Přístup	Příklad
Config server	Spring Cloud Config, Consul
Nativní orchestrator	Kubernetes ConfigMaps
Správce tajemství	HashiCorp Vault, AWS Secrets Manager