Secret Encryption at Rest

K8s Secrets can be encrypted at rest. The setup.

Config

Secret encryption at rest is the discipline of encrypting Kubernetes Secret objects in etcd. Without it, secrets are stored in plain text inside etcd; etcd compromise produces secret compromise. With it, secrets are encrypted; etcd compromise alone is not enough to access secrets.

What configuration provides:

• EncryptionConfiguration in api-server.: The API server is configured with an EncryptionConfiguration resource. The configuration specifies which resources are encrypted and which providers are used. The API server applies encryption transparently to authorized clients.
• KMS provider for key management.: The encryption keys live in a KMS (AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault). The cluster delegates key management to the KMS; the keys are not in etcd.
• Symmetric encryption.: The actual data encryption uses a symmetric key (AES-CBC or AES-GCM). The KMS holds the key-encryption-key; the data encryption is fast.
• Configured per resource type.: Different resource types can have different encryption. Secrets typically encrypt; ConfigMaps may or may not; the configuration is per-type.
• Verify on cluster restart.: The encryption is applied at write time. Existing data is not automatically re-encrypted; the team's procedure includes re-encrypting existing secrets after enabling.

The configuration is the foundation. Without it, encryption at rest is unconfigured; secrets sit in plain text.

Verify

The configuration must be verified. Configurations that look right may not be applied; verification confirms the encryption is actually working.

• etcdctl get secrets/foo shows encrypted blob.: The team queries etcd directly. The secret's stored value is the encrypted blob, not the plain-text content. The verification is direct.
• Direct verification.: No assumptions; the team sees the actual stored content. If the secret is encrypted, the verification confirms the configuration is working; if not, the configuration has issues.
• Test after every change.: Configuration changes warrant re-verification. The team confirms encryption is still working after each change; regressions are caught quickly.
• Document the verification procedure.: The procedure is documented. New team members can verify; the institutional knowledge is preserved.
• Auditor-ready evidence.: The verification produces audit-ready evidence. Compliance discussions reference the verification; the team's claim is backed by direct observation.

Verification is the assurance. Without it, the team trusts configuration claims; with it, the team has demonstrated facts.

Rotation

The encryption keys need rotation. Static keys are a long-term risk; rotated keys limit the window of exposure if a key is compromised.

• Quarterly key rotation.: The keys rotate quarterly. The KMS supports rotation natively; the cluster picks up the new key; the rotation is operationally bounded.
• Re-encrypt existing.: After rotation, existing secrets are re-encrypted with the new key. Without re-encryption, the old key is still required to decrypt old secrets; the rotation is incomplete.
• Documented procedure.: The rotation procedure is documented. The team has practiced the steps; the rotation is routine; mistakes are bounded.
• Coordinate with KMS rotation policy.: The KMS may have its own rotation policy. The cluster's rotation aligns with the KMS; the two are coordinated rather than overlapping.
• Verify after rotation.: Each rotation is verified. The new key is in use; existing secrets are accessible; the system is healthy. The verification is the safety net.

Secret encryption at rest is one of those security disciplines that pays off in the rare cases where it matters. Nova AI Ops integrates with cluster security configuration, surfaces encryption status, and produces the verification reports that compliance discussions reference.