We recommend using etcd encryption to provide an additional layer of data security for your cluster.
Read more about it: Kubernetes Docs: Encrypting Data at Rest
To enable it in Autopilot, one possible approach is changing the spec.topology.variables of your cluster.yaml or Cluster resource within the management cluster and add:
And create the related secret:
To generate a random value to replace <token> , you can use:
Then save the above file as etcd-encryption-secret.yaml and run:
Direct verification of encrypted Secret data in etcd (for example using etcdctl ) requires access to the control plane / etcd.
Enabling encryption does not automatically rewrite Secrets that were already stored before encryption was enabled. Existing Secrets are encrypted after their next write.
To re-encrypt one existing Secret, trigger a small write (for example by annotating it):
This updates the Secret and causes it to be written again using the currently configured encryption settings.
To re-encrypt all existing Secrets cluster-wide, run:
This command reads and rewrites all Secrets with the same data, which applies encryption at rest to objects that were previously unencrypted.
The official Kubernetes verification procedure for encryption at rest checks the raw Secret data in etcd using etcdctl . To execute those commands on a node, you need access to the control plane / etcd.
If you need to troubleshoot or prove that data is encrypted in etcd, follow the upstream Kubernetes verification steps: