ConfigMaps & Secrets

Kubernetes lets you separate your app’s configuration from your container images using two special resources:

ConfigMaps for non-sensitive data (like settings, URLs, etc.)
Secrets for sensitive data (like passwords, tokens, certificates)

This makes your apps more secure, portable, and easier to manage.

ConfigMaps (Non-Sensitive Configuration)

A ConfigMap is a key-value store for plain-text configuration. Use it for:

Environment settings (like LOG_LEVEL, API_BASE_URL)
Hostnames, ports, feature flags
Complete config files or CLI arguments

Example

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: debug
  DB_HOST: db.default.svc.cluster.local

Secrets (Sensitive Data)

Secrets are also key-value stores - but for private data:

Passwords, tokens, API keys
SSH keys or TLS certs
Docker registry credentials

Kubernetes encodes all Secret values in base64 (for transport, not real security).

Example

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  DB_PASSWORD: c3VwZXJzZWNyZXQ=

Tip

Decode with echo c3VwZXJzZWNyZXQ= | base64 -d. Use stringData: if you want Kubernetes to handle encoding for you.

Ways to Use ConfigMaps and Secrets

There are three main ways to expose values inside your Pods:

1. Environment Variables

Inject all key-value pairs from a ConfigMap or Secret:

envFrom:
  - configMapRef:
      name: app-config
  - secretRef:
      name: db-secret

Or reference individual keys:

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: DB_PASSWORD

2. Mounted Volumes

Map each key to a file inside the container:

volumes:
  - name: config-vol
    configMap:
      name: app-config
containers:
  - name: app
    volumeMounts:
      - name: config-vol
        mountPath: /etc/config

In the container, this results in:

/etc/config/LOG_LEVEL
/etc/config/DB_HOST

You can do the same for Secrets:

volumes:
  - name: creds
    secret:
      secretName: db-secret

⚠️ Secrets mounted as files on disk are only base64-decoded. They are not encrypted unless you've enabled encryption at rest.

3. CLI Arguments or Command Overrides

containers:
  - name: app
    image: myapp
    args:
      - "--log-level=$(LOG_LEVEL)"
    env:
      - name: LOG_LEVEL
        valueFrom:
          configMapKeyRef:
            name: app-config
            key: LOG_LEVEL

Kubernetes allows you to configure runtime behavior of containers using environment variables, and to monitor their health using liveness and readiness probes. These features are essential for building reliable, configurable, and observable applications in the cluster.

Environment Variables

You can pass key-value pairs into containers using environment variables. These can be hardcoded, referenced from ConfigMaps, Secrets, or even dynamically derived from field references.

Static Environment Variables

env:
  - name: LOG_LEVEL
    value: "debug"

From ConfigMap

envFrom:
  - configMapRef:
      name: app-config

Or individual keys:

env:
  - name: APP_PORT
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: port

From Secret

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

From Pod Metadata

env:
  - name: POD_NAME
    valueFrom:
      fieldRef:
        fieldPath: metadata.name

Using ConfigMaps & Secrets

You can mount ConfigMaps and Secrets as environment variables or files inside your Pods. This keeps your app configuration flexible and secure.

Best Practices

Never store sensitive data in ConfigMaps. Use Secrets for anything private.
Restrict access to Secrets using RBAC.
Avoid hardcoding values in your manifests. Reference ConfigMaps and Secrets instead.
Use external secret managers (like AWS Secrets Manager, HashiCorp Vault) for extra-sensitive data.

Summary

ConfigMaps: For non-sensitive, environment-specific configuration.
Secrets: For sensitive data, encoded for transport.
Both improve security, portability, and flexibility in your Kubernetes apps.