Kubernetes Configuration and Secrets

Kubernetes Configuration and Secrets are the mechanisms by which application configuration data and sensitive values, such as passwords, tokens, and certificates, are decoupled from container images and injected into running Pods at deploy time. Rather than baking configuration into an image, which would require rebuilding it for every environment or credential rotation, Kubernetes represents configuration and secret data as independent API objects that can be created, updated, and consumed separately from the application code that uses them.

ConfigMap

Purpose

A ConfigMap stores non-confidential configuration data as key-value pairs, intended for values such as feature flags, log levels, or endpoint URLs that vary between environments but carry no sensitive information.

apiVersion: v1
kind: ConfigMap
metadata:
  name: codartium-app-config
data:
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
  application.yaml: |
    server:
      port: 8080
    features:
      newDashboard: true

Consuming a ConfigMap

A ConfigMap's data can be injected into a Pod as individual environment variables, as an entire environment variable set, or as files mounted into the container's filesystem, with the choice depending on whether the consuming application expects configuration as environment variables or as a configuration file.

spec:
  containers:
    - name: app
      image: codartium/app:1.0.0
      envFrom:
        - configMapRef:
            name: codartium-app-config
      volumeMounts:
        - name: config-volume
          mountPath: /etc/codartium
  volumes:
    - name: config-volume
      configMap:
        name: codartium-app-config

Secret

Purpose and Distinction from ConfigMap

A Secret stores sensitive data, database credentials, API tokens, TLS certificates, using the same key-value structure as a ConfigMap, but with handling intended to reduce accidental exposure: values are base64-encoded in storage (not encrypted by default), access can be restricted independently through RBAC, and the API server can be configured to encrypt Secret data at rest.

apiVersion: v1
kind: Secret
metadata:
  name: codartium-db-credentials
type: Opaque
data:
  username: Y29kYXJ0aXVt
  password: c3VwZXJzZWNyZXQ=

Secret Types

Kubernetes defines several built-in Secret types beyond the generic Opaque type: kubernetes.io/tls for TLS certificate and key pairs, kubernetes.io/dockerconfigjson for container registry credentials, and kubernetes.io/service-account-token for tokens used by Pods to authenticate to the API server.

kubectl create secret generic codartium-db-credentials \
  --from-literal=username=codartium \
  --from-literal=password=supersecret

kubectl create secret tls codartium-tls-cert \
  --cert=tls.crt --key=tls.key

Consuming a Secret

Like ConfigMaps, Secrets can be exposed to a Pod as environment variables or as mounted files, with mounted files generally preferred for sensitive values since environment variables are more easily leaked through logs, process listings, or debugging tools.

spec:
  containers:
    - name: app
      image: codartium/app:1.0.0
      env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: codartium-db-credentials
              key: password

Update Propagation and Immutability

Live Updates to Mounted Volumes

When a ConfigMap or Secret is mounted as a volume, updates to the underlying object are eventually propagated to the mounted files inside running Pods without requiring a Pod restart, though the propagation delay and the application's own behavior around re-reading files determine how quickly the change takes effect. Values injected as environment variables, by contrast, are fixed at container start and require a Pod restart to reflect any change.

Immutable ConfigMaps and Secrets

Marking a ConfigMap or Secret as immutable: true prevents any further modification to its data, protecting against accidental changes and allowing the kubelet to skip watching it for updates, which reduces load on the API server for configuration that is not expected to change without a corresponding new object and rollout.

apiVersion: v1
kind: ConfigMap
metadata:
  name: codartium-app-config-v2
immutable: true
data:
  LOG_LEVEL: "warn"

Security Considerations

RBAC and Least Privilege

Because Secrets often grant access to critical systems, RBAC rules should restrict get, list, and watch access to Secrets to only the identities and controllers that genuinely require it, since read access to a Secret object is equivalent to possessing the credential it stores.

Encryption at Rest

By default, Secret data is stored in etcd only base64-encoded, which is not encryption. Enabling encryption at rest for the API server ensures Secret data is encrypted before being persisted to etcd, protecting against exposure through direct access to etcd's storage or backups.

External Secret Management

For stronger separation between secret storage and the cluster, external secret managers, such as a dedicated vault service, can be integrated through a controller that synchronizes external secrets into native Kubernetes Secret objects, or through a CSI driver that mounts secrets directly from the external store without persisting them in etcd at all.

kubectl get secrets -n codartium-team
kubectl describe secret codartium-db-credentials -n codartium-team