ConfigMaps and Secrets in Kubernetes

Hardcoding config in container images is a maintenance trap: every environment change requires a rebuild. Kubernetes separates config from code with two objects. ConfigMaps hold non-sensitive, plain-text configuration. Secrets hold sensitive values such as passwords, tokens, and API keys. Both can be injected into pods as environment variables or mounted as files, and both update independently of the pod image.

ConfigMaps for plain config

A ConfigMap stores key/value pairs or whole files. They are good for feature flags, URLs, timeouts, and small config files.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: debug
  CACHE_TTL: "300"
  REDIS_HOST: redis

Secrets for sensitive values

Secrets look similar but hold sensitive data. In YAML, values are base64-encoded, but they are created and managed through the API at runtime. Do not commit real secrets to YAML in git — create them with kubectl create or from a file.

echo -n "s3cr3t-pass" | base64
# czNjcjN0LXBhc3M=
kubectl create secret generic db-secret   --from-literal=DB_PASSWORD=s3cr3t-pass   --from-literal=DB_USER=appuser

Injecting them into a pod

Reference both in the same Deployment spec, using env and envFrom. ConfigMap values become environment variables; Secrets do the same for values that must stay out of manifests.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
        - name: app
          image: myapp:1.2
          envFrom:
            - configMapRef:
                name: app-config
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: db-secret
                  key: DB_PASSWORD

Config as files: mounting volumes

Environment variables are convenient, but many tools prefer a config file. Mount a ConfigMap or Secret as a volume to place files into the pod filesystem.

apiVersion: v1
kind: Pod
metadata:
  name: config-pod
spec:
  containers:
    - name: app
      image: nginx:1.27
      volumeMounts:
        - name: config
          mountPath: /etc/app
  volumes:
    - name: config
      configMap:
        name: app-config

Where each should live

Reading them back for verification

Check what is mounted without disturbing the running pod.

kubectl get configmap app-config -o yaml
kubectl get secret db-secret -o jsonpath='{.data.DB_PASSWORD}' | base64 -d
kubectl exec deploy/app -- printenv LOG_LEVEL

Takeaway

ConfigMaps carry the non-sensitive config and Secrets the sensitive values; both reach pods as env vars or files, keeping code portable across environments. For real deployments, create Secrets via kubectl create and keep them out of git. Set up a sample app with both objects on a Netbay VPS and the pattern will feel automatic — netbayhosts.in.