Secrets are stored in a dedicated secrets manager with encryption at rest

Kubernetes Secrets stored without encryption at rest are base64-encoded plaintext in etcd — any operator with etcd access, a backup file, or an etcd snapshot command can decode every database password and API key in the cluster (CWE-312, OWASP A02). NIST 800-53 SC-28 requires encryption of data at rest. Secrets checked into ConfigMaps are worse — they appear in kubectl get configmap -o yaml with no access differentiation from application configuration. A hardcoded credential in a manifest that enters git history is exposed to every developer, CI system, and repository fork for the lifetime of the repo.

Enable etcd encryption at rest and reference secrets via secretKeyRef in all manifests. Configure etcd encryption in /etc/kubernetes/encryption.yaml on the control plane:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

Then reference secrets in Deployments:

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

For stronger guarantees, use HashiCorp Vault with the Vault Agent Injector or the Secrets Store CSI driver to mount secrets at runtime without storing them in etcd.