ConfigMaps and Secrets: Spring Boot Config Management in Kubernetes

Q: ConfigMaps and Secrets: Spring Boot Config Management in Kubernetes

ConfigMaps hold non-sensitive config injected as env (`envFrom`) or mounted as files; Secrets hold credentials, base64-encoded at rest and gated by RBAC + etcd encryption. Spring Boot picks them up automatically via relaxed binding (`SPRING_DATASOURCE_URL` → `spring.datasource.url`) — same image runs in dev/stage/prod. Updating a ConfigMap does **not** restart pods; use Reloader, checksum annotations, or Spring Cloud Kubernetes for reloads. For production credentials prefer External Secrets Operator syncing from Vault or cloud secret managers.

Intermediate·3 min read·

KubernetesHashicorpPivotalAmazon

Fast recall

Quick revision

Core answer

ConfigMaps hold non-sensitive config injected as env (envFrom) or mounted as files; Secrets hold credentials, base64-encoded at rest and gated by RBAC + etcd encryption. Spring Boot picks them up automatically via relaxed binding (SPRING_DATASOURCE_URL → spring.datasource.url) — same image runs in dev/stage/prod. Updating a ConfigMap does not restart pods; use Reloader, checksum annotations, or Spring Cloud Kubernetes for reloads. For production credentials prefer External Secrets Operator syncing from Vault or cloud secret managers.

Interview Answer3 min

ConfigMaps and Secrets both inject configuration into Pods, but they exist for different reasons: ConfigMaps for non-sensitive config, Secrets for credentials. Kubernetes handles their access control and audit differently.

ConfigMap — non-sensitive configuration

Stores key-value pairs or entire files; Spring Boot reads them as env vars (envFrom.configMapRef) or as mounted property files via spring.config.import=optional:configtree:/config/.
The configtree import mounts the ConfigMap as a directory where each key becomes a file; Spring reads nested properties from file paths — database.url in the ConfigMap becomes database.url in the Spring environment.
Critical behavior: updating a ConfigMap does not restart running pods — env vars are frozen at container start; mounted files update eventually (within ~60s kubelet sync) but the app must watch for changes; the safest approach is a rolling restart triggered by a Helm checksum annotation or Reloader.

Secrets — credential injection

Kubernetes Secrets are base64-encoded by default, not encrypted — any user with get secret permission can read them; base64 is encoding, not security; enable etcd encryption-at-rest and RBAC restriction to make Secrets meaningful.
Spring Boot reads Secrets like ConfigMaps — as env vars or mounted files; prefer mounted files because env vars appear in kubectl describe pod and process listings.
In production, Kubernetes-native Secrets are often insufficient — use External Secrets Operator to sync from AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager; ESO fetches and rotates without relying solely on Kubernetes RBAC.

The environment variable reload problem

Neither ConfigMap nor Secret updates propagate to running containers as env vars — the container must restart to see new values.
Reloader (stakater/Reloader) watches ConfigMap and Secret changes and triggers rolling restarts automatically — annotate the Deployment with reloader.stakater.com/auto: "true" and Reloader handles the rest.
For config that can be hot-reloaded at the Spring level, use Spring Cloud Kubernetes Config with @RefreshScope beans — but note startup-time config (DB pool size, Tomcat connector) cannot hot-reload and still needs a pod restart.

Interview-ready guide

Interview answer

ConfigMap — non-sensitive configuration

Stores key-value pairs or entire files; Spring Boot reads them as env vars (envFrom.configMapRef) or as mounted property files via spring.config.import=optional:configtree:/config/.
The configtree import mounts the ConfigMap as a directory where each key becomes a file; Spring reads nested properties from file paths — database.url in the ConfigMap becomes database.url in the Spring environment.
Critical behavior: updating a ConfigMap does not restart running pods — env vars are frozen at container start; mounted files update eventually (within ~60s kubelet sync) but the app must watch for changes; the safest approach is a rolling restart triggered by a Helm checksum annotation or Reloader.

Secrets — credential injection

Kubernetes Secrets are base64-encoded by default, not encrypted — any user with get secret permission can read them; base64 is encoding, not security; enable etcd encryption-at-rest and RBAC restriction to make Secrets meaningful.
Spring Boot reads Secrets like ConfigMaps — as env vars or mounted files; prefer mounted files because env vars appear in kubectl describe pod and process listings.
In production, Kubernetes-native Secrets are often insufficient — use External Secrets Operator to sync from AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager; ESO fetches and rotates without relying solely on Kubernetes RBAC.

The environment variable reload problem

Neither ConfigMap nor Secret updates propagate to running containers as env vars — the container must restart to see new values.
Reloader (stakater/Reloader) watches ConfigMap and Secret changes and triggers rolling restarts automatically — annotate the Deployment with reloader.stakater.com/auto: "true" and Reloader handles the rest.
For config that can be hot-reloaded at the Spring level, use Spring Cloud Kubernetes Config with @RefreshScope beans — but note startup-time config (DB pool size, Tomcat connector) cannot hot-reload and still needs a pod restart.

03 · Deep dive