Jak radzisz sobie ze scentralizowaną konfiguracją i sekretami na wielu usługach?

Question

Accepted Answer

W przypadku dziesiątek usług nie możesz zarządzać konfiguracją i sekretami doraźnie dla każdego wdrożenia. **Scentralizowana konfiguracja** przechowuje ustawienia w jednym zarządzanym źródle, a **menedżery sekretów** bezpiecznie przechowują wrażliwe wartości.

## Eksternalizowana konfiguracja

Konfiguracja znajduje się poza artefaktem kompilacji, dzięki czemu ten sam obraz działa w dev/staging/prod z różnymi ustawieniami.

```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"
```

## Podejścia do konfiguracji

| Podejście | Przykład |
|---|---|
| Serwer konfiguracji | Spring Cloud Config, Consul |
| Natywne dla orkiestratora | Kubernetes ConfigMaps |
| Menedżer sekretów | HashiCorp Vault, AWS Secrets Manager |

## Sekrety — utrzymuj je osobno

Nigdy nie przechowuj sekretów w zwykłych ConfigMaps lub w git.

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

## Dobre praktyki

```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
```

## Dlaczego to ważne

Scentralizowana konfiguracja pozwala zmienić zachowanie (timeouty, flagi funkcji) i rotować poświadczenia między wieloma usługami bez przebudowywania i ponownego wdrażania każdej z nich.

Przechowywanie sekretów w rzeczywistym menedżerze sekretów — a nie w obrazach ani w git — jest podstawowym wymogiem bezpieczeństwa, który skaluje się wraz z liczbą usług.

Podejście	Przykład
Serwer konfiguracji	Spring Cloud Config, Consul
Natywne dla orkiestratora	Kubernetes ConfigMaps
Menedżer sekretów	HashiCorp Vault, AWS Secrets Manager