ConfigMaps, Secrets & Configuration Management

Consumption patterns

Size and immutability

A ConfigMap cannot exceed 1 MiB total (sum of keys and values). Large configs belong in object storage, a git-sync sidecar, or a dedicated config server—not a giant ConfigMap. Set immutable: true when the ConfigMap will never change; the API server rejects updates, kubelet skips periodic relist for mounted volumes, and you avoid accidental hot-reload races.

Update behavior

When a ConfigMap changes, behavior depends on how it is consumed:

• env / envFrom — Values are injected at pod creation only. Changing the ConfigMap does not update running pods; you must roll out a new ReplicaSet (change an annotation, bump image tag, or kubectl rollout restart).
• volume mount — Kubelet syncs mounted ConfigMap files on a periodic interval (default ~60s, tunable via --sync-frequency). Files update in place via atomic symlink swap; apps must watch for changes or use Reloader. subPath mounts do not auto-update—avoid subPath for hot-reload configs.
• projected volumes — Same sync semantics as configMap volumes when ConfigMap is a source.

  ConfigMap (API)
       │
       ├── env / envFrom ──► set once at pod start ──► restart required on change
       │
       └── volume mount ──► kubelet sync (~60s) ──► files update in-place
                              (subPath = NO auto-sync)

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: payments
  labels:
    app: payment-api
data:
  LOG_LEVEL: info
  FEATURE_FLAGS: |
    enable_3ds=true
    max_retries=5
  application.yaml: |
    server:
      port: 8080
    spring:
      profiles:
        active: prod
immutable: true
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment-api
  template:
    metadata:
      labels:
        app: payment-api
    spec:
      containers:
        - name: api
          image: payment-api:2.4.1
          envFrom:
            - configMapRef:
                name: app-config
          env:
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          volumeMounts:
            - name: config-files
              mountPath: /config
              readOnly: true
          args:
            - --log-level=$(LOG_LEVEL)
      volumes:
        - name: config-files
          configMap:
            name: app-config
            items:
              - key: application.yaml
                path: application.yaml

$ kubectl create configmap app-config --from-literal=LOG_LEVEL=debug -n payments
$ kubectl create configmap nginx-conf --from-file=nginx.conf -n payments
$ kubectl get configmap app-config -o yaml
$ kubectl describe configmap app-config -n payments
$ kubectl rollout restart deployment/payment-api -n payments$ oc create configmap app-config --from-literal=LOG_LEVEL=debug -n payments
$ oc create configmap nginx-conf --from-file=nginx.conf -n payments
$ oc get configmap app-config -o yaml
$ oc describe configmap app-config -n payments
$ oc rollout restart deployment/payment-api -n payments

Built-in types

Base64 is not encryption

data values in a Secret manifest are base64-encoded for transport—anyone with kubectl get secret -o yaml or RBAC read access sees plaintext after decoding. RBAC, audit logging, and admission policy (OPA/Gatekeeper) are your first lines of defense.

Encryption at rest

Enable EncryptionConfiguration on the API server so etcd stores Secret (and optionally ConfigMap) values encrypted with AES-GCM or KMS providers (AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault transit). This protects etcd backups and disk theft—it does not decrypt values inside running pods or for users with Secret read RBAC.

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: payments
type: Opaque
stringData:
  username: app_user
  password: "change-me-in-vault-not-git"
  DATABASE_URL: postgres://app_user:change-me@db.internal:5432/payments
immutable: true
---
apiVersion: v1
kind: Secret
metadata:
  name: api-tls
  namespace: payments
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTi...  # base64 PEM
  tls.key: LS0tLS1CRUdJTi...  # base64 PEM
---
apiVersion: v1
kind: Secret
metadata:
  name: regcred
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: eyJhdXRocyI6eyJyZWdpc3RyeS5leGFtcGxlLmNvbSI6e319fQ==

Rotation and lifecycle

• Immutable Secrets — Same as ConfigMaps: no in-place updates; create db-credentials-v2, update references, roll out, delete old.
• Dual-key period — During rotation, mount both old and new keys; app accepts either until cutover completes.
• Automated rotation — Operators (External Secrets, Vault Agent) refresh Secrets on a schedule; pair with Reloader for rollouts.
• Service account tokens — Bound tokens via projected volumes rotate automatically; avoid long-lived legacy token Secrets.

Never commit Secrets to git

Plain Secrets in a Git repo are a credential leak—even private repos get forked, indexed, and breached. Use External Secrets Operator (ESO) to sync from AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, or 1Password into native Kubernetes Secrets at reconcile time. Git holds ExternalSecret CRs referencing remote keys, not the secret values themselves.

$ kubectl create secret generic db-credentials --from-literal=password='s3cr3t' -n payments
$ kubectl create secret tls api-tls --cert=tls.crt --key=tls.key -n payments
$ kubectl create secret docker-registry regcred --docker-server=registry.example.com --docker-username=user --docker-password=pass
$ kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d
$ kubectl get externalsecrets -A$ oc create secret generic db-credentials --from-literal=password='s3cr3t' -n payments
$ oc create secret tls api-tls --cert=tls.crt --key=tls.key -n payments
$ oc create secret docker-registry regcred --docker-server=registry.example.com --docker-username=user --docker-password=pass
$ oc get secret db-credentials -o jsonpath='{.data.password}' | base64 -d
$ oc get externalsecrets -A

How it works

1. Install the Sealed Secrets controller in the cluster; it generates an RSA key pair.
2. Fetch the cluster public key: kubeseal --fetch-cert.
3. Encrypt a Secret manifest offline: kubeseal --format yaml < secret.yaml > sealedsecret.yaml.
4. Commit the SealedSecret CR to git; Argo CD / Flux applies it.
5. Controller decrypts and upserts a native Secret in the target namespace.

SealedSecrets are scoped: by default, encryption is bound to namespace and name—renaming either requires re-sealing. Cluster-wide sealing exists but is discouraged. Key rotation requires re-encrypting all SealedSecrets when the controller key rotates.

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: db-credentials
  namespace: payments
spec:
  encryptedData:
    password: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEQAx...
    username: AgBXGjY0YjE3YjQzN2Y5ZWRhYzE4...
  template:
    metadata:
      labels:
        app: payment-api
    type: Opaque

$ kubectl create secret generic db-credentials --from-literal=password=dev --dry-run=client -o yaml | kubeseal -o yaml > sealed-db.yaml
$ kubeseal --fetch-cert --controller-name=sealed-secrets --controller-namespace=kube-system > pub-cert.pem
$ kubectl apply -f sealed-db.yaml
$ kubectl get sealedsecret db-credentials -n payments
$ kubectl get secret db-credentials -n payments  # materialized by controller$ oc create secret generic db-credentials --from-literal=password=dev --dry-run=client -o yaml | kubeseal -o yaml > sealed-db.yaml
$ kubeseal --fetch-cert --controller-name=sealed-secrets --controller-namespace=kube-system > pub-cert.pem
$ oc apply -f sealed-db.yaml
$ oc get sealedsecret db-credentials -n payments
$ oc get secret db-credentials -n payments

Integration patterns

Authentication methods

• Kubernetes auth — Pod's SA JWT sent to Vault; Vault validates against the cluster's TokenReview API and maps SA → Vault role/policy. No long-lived Vault tokens in manifests.
• AppRole — role_id + secret_id for CI/CD and operators; secret_id delivered via wrapped token or K8s Secret (prefer short TTL).
• Cloud IAM auth — AWS/GCP/Azure auth methods when Vault runs on the same cloud; pods assume IAM roles.

sequenceDiagram
  participant Pod as Pod (SA token)
  participant Agent as Vault Agent
  participant Vault as Vault
  participant API as K8s API

  Pod->>Agent: Start with projected SA JWT
  Agent->>Vault: login auth/kubernetes (role, jwt)
  Vault->>API: TokenReview (validate JWT)
  API-->>Vault: SA identity OK
  Vault-->>Agent: Short-lived Vault token
  Agent->>Vault: Read secret/data/payments/db
  Vault-->>Agent: username/password
  Agent->>Pod: Write /vault/secrets/db.env

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
  namespace: payments
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-credentials
    creationPolicy: Owner
  data:
    - secretKey: password
      remoteRef:
        key: secret/data/payments/db
        property: password
    - secretKey: username
      remoteRef:
        key: secret/data/payments/db
        property: username
---
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-db
  namespace: payments
spec:
  provider: vault
  parameters:
    vaultAddress: https://vault.internal:8200
    roleName: payments-app
    objects: |
      - objectName: db-password
        secretPath: secret/data/payments/db
        secretKey: password

$ kubectl get pods -n vault -l app.kubernetes.io/name=vault
$ kubectl get mutatingwebhookconfigurations | grep vault-agent-injector
$ kubectl annotate pod payment-api-xyz vault.hashicorp.com/agent-inject='true'
$ kubectl get secretproviderclass -n payments
$ kubectl describe externalsecret db-credentials -n payments$ oc get pods -n vault -l app.kubernetes.io/name=vault
$ oc get mutatingwebhookconfigurations | grep vault-agent-injector
$ oc annotate pod payment-api-xyz vault.hashicorp.com/agent-inject='true'
$ oc get secretproviderclass -n payments
$ oc describe externalsecret db-credentials -n payments

ResourceQuota

Enforced at admission time when pods are created. Counts active resources—completed Jobs may still count toward count/jobs.batch until TTL cleans them up. Common hard limits:

Pods must specify requests and limits when the quota tracks those resources (requests.cpu quota requires every container to declare CPU requests). Use scopeSelector for tiered quotas (e.g. only BestEffort pods).

LimitRange

Namespace-scoped defaults and enforcement per Pod or Container:

• default — Applied when container omits limits.
• defaultRequest — Applied when container omits requests.
• min / max — Reject pods outside bounds at admission.
• maxLimitRequestRatio — Cap burst (e.g. limit ≤ 2× request).

PriorityClass

PriorityClass objects define global priority values. Pods with higher priority evict lower-priority pods when a node is under pressure (preemption). Platform namespaces run system-cluster-critical; batch jobs use low or negative priority. Pair with PodDisruptionBudgets so preemption does not violate availability SLOs.

OpenShift Project templates

OpenShift Project is a namespace with annotations and optional template objects. Cluster admins edit the project-request template to auto-inject ResourceQuota, LimitRange, NetworkPolicy, and RBAC RoleBindings when developers run oc new-project. This is how enterprise OCP clusters standardize tenant onboarding without per-team YAML drift.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: payments
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    pods: "50"
    persistentvolumeclaims: "10"
    services.loadbalancers: "2"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: team-limits
  namespace: payments
spec:
  limits:
    - type: Container
      default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      min:
        cpu: 50m
        memory: 64Mi
      max:
        cpu: "4"
        memory: 8Gi
      maxLimitRequestRatio:
        cpu: "4"
        memory: "4"
    - type: Pod
      max:
        cpu: "8"
        memory: 16Gi
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: production-high
value: 1000000
globalDefault: false
description: Production tier workloads

$ kubectl describe resourcequota team-quota -n payments
$ kubectl get resourcequota -n payments -o wide
$ kubectl describe limitrange team-limits -n payments
$ kubectl get priorityclass
$ kubectl create quota dev-quota --hard=pods=10,requests.cpu=4,requests.memory=8Gi -n dev$ oc describe quota team-quota -n payments
$ oc get quota -n payments
$ oc describe limitrange team-limits -n payments
$ oc get priorityclass
$ oc edit projectconfig cluster  # project-request template