Lesson 0018 · 40 minutes · Cluster Hardening

Configure encryption before data reaches etcd

Kubernetes Secrets are base64-encoded in API responses, not encrypted by default in etcd. Encryption at rest is controlled by an API-server configuration file and provider order matters.

Exam reflex: this is an API-server configuration, not a Kubernetes object. Do not use kubectl apply for the encryption configuration. First providers encrypt new writes; identity is a fallback and belongs last.

Timed task: 30 minutes

Apply lab/lesson-18-fixture.yaml only to create the sample Secret. Then write lab/lesson-18-encryption-config.yaml from scratch.

Your configuration must:

Do not place identity first, do not use a plaintext key, and do not add an etcd object or Secret to store this configuration.

Verification

kubectl --context kind-cks-lab apply -f .\lab\lesson-18-fixture.yaml

# Generate a valid 32-byte base64 key in PowerShell:
$bytes = [byte[]]::new(32)
[System.Security.Cryptography.RandomNumberGenerator]::Fill($bytes)
[Convert]::ToBase64String($bytes)

# Check your generated key decodes to 32 bytes:
[Convert]::FromBase64String('<your-key>').Length

In a production control plane, place the completed file securely on every API-server node, configure --encryption-provider-config, restart one API server at a time, then rewrite existing Secrets so they are stored with the new provider.

Retrieval check

Question

Why must identity be last in the provider list?

Documentation target

Use the official Kubernetes Encrypting Confidential Data at Rest guide. Review the operational steps for rotating keys and rewriting already-stored objects.

What to send me

Paste the configuration only—not the actual production key. I’ll validate provider order, resource scope, and base64 key length in this local training file.