Kubernetes Patterns: Configuration and Secret Management

Kubernetes configuration and secret management has evolved from basic ConfigMaps and Secrets to a rich ecosystem of external secret stores, GitOps-compatible encrypted secrets, and dynamic secret injection.

ConfigMaps and the file system

ConfigMaps can be mounted as environment variables or as files in a volume. The file system mount pattern allows configuration to be updated without restarting pods: the mounted ConfigMap files update when the ConfigMap changes, and applications that watch the file system for config changes can reload without restart. Spring Cloud Kubernetes and ASP.NET Core's FileSystemWatcher-based config reload support this pattern.

External Secrets Operator

The External Secrets Operator (ESO) synchronises secrets from external secret stores (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) into Kubernetes Secrets. The application reads from Kubernetes Secrets (the standard mechanism) without knowing the secret source. The ESO handles authentication to the external store, secret retrieval, and automatic rotation when the external secret changes.

Sealed Secrets for GitOps

Bitnami Sealed Secrets allows Kubernetes Secrets to be encrypted (using the cluster's public key) and stored in Git. The SealedSecret custom resource contains the encrypted secret; only the Sealed Secrets controller (which has the private key) can decrypt it. This enables GitOps workflows where all Kubernetes configuration including secrets can be stored in Git repositories without exposing secret values.

Immutable configuration patterns

ConfigMaps and Secrets in Kubernetes are mutable by default. The risk: a ConfigMap change takes effect immediately in mounted volumes, which can cause unexpected configuration updates in production. The immutable pattern: create new ConfigMap versions instead of editing existing ones, update Deployment annotations to trigger a rolling update when the ConfigMap changes. The downward API (injecting pod metadata as environment variables) provides dynamic configuration that does not require ConfigMap changes.