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.
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:
- Use
apiserver.config.k8s.io/v1and kindEncryptionConfiguration. - Encrypt only the core
secretsresource. - Use
aescbcas the first provider, with one key namedkey1. - Use a random, valid 32-byte key encoded in base64.
- Include
identityonly as the final provider.
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>').LengthIn 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.