Lion Cipher Lab
Encrypt Kubernetes Secrets at rest, part 3: move to a KMS provider (envelope encryption)
- Cloud Security
- Advanced
- ~60 min
- Free · no account required
Why it matters
Parts 1 and 2 left a cluster whose Secrets are ciphertext in etcd, rotated and audited, with the key in a file on the control-plane node. The Kubernetes encryption docs describe the local providers that way, as key material accessible from the control plane host. So whoever takes the node takes the data and the key that opens it. A KMS provider fixes where the key lives. The key that protects everything, the KEK, stays inside an external key management service, and the API server has to ask that service before it can use the keys that encrypt your data. The cost is a new dependency: the KMS…
What you'll learn
- explaining why a local-key provider leaves key material on the control-plane host
- describing KMS v2's key hierarchy: single-use DEKs derived from a seed, the seed wrapped by a KEK that stays in the external KMS
- writing the documented switch from a local provider to kms: kms first, the old provider second, then a re-write
- reading the kms-providers health check on a live API server
- explaining KEK rotation through the plugin's key_id, with no API server restart
- reading a real KMS plugin (kubernetes-sigs aws-encryption-provider) and where it runs
- weighing the availability cost of a KMS dependency against the key separation it buys
Steps in this lab
- What Parts 1 and 2 left unsolved: the key sits beside the data
- Rebuild Part 2's end state, and find the health check a KMS will use
- Envelope encryption, precisely: DEKs, the seed, and the KEK
- Write the switch: kms first, the old provider second, then re-write
- Rotating the KEK: key_id, not a restart
- Read a real plugin: aws-encryption-provider
- The judgment: what the KMS costs, and what it still does not defend