Verifying and Ensuring Secret Encryption, Switching to KMS Provider

Until the steps defined in [Ensuring all secrets are encrypted](#ensuring-all-secrets-are-encrypted) are performed, the `providers` list should end with the `identity: {}` provider to allow unencrypted data to be read. Once all resources are encrypted, the `identity` provider should be removed to prevent the API server from honoring unencrypted data. For details about the `EncryptionConfiguration` format, please check the [API server encryption API reference](/docs/reference/config-api/apiserver-config.v1/). ## Verifying that the data is encrypted When encryption at rest is correctly configured, resources are encrypted on write. After restarting your `kube-apiserver`, any newly created or updated Secret or other resource types configured in `EncryptionConfiguration` should be encrypted when stored. To verify, you can use the `etcdctl` command line program to retrieve the contents of your secret data. 1. Create a new secret called `secret1` in the `default` namespace: ```shell kubectl create secret generic secret1 -n default --from-literal=mykey=mydata ``` 1. Using the `etcdctl` command line, read that secret out of etcd: ```shell ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C ``` where `[...]` contains the additional arguments for connecting to the etcd server. 1. Verify the stored secret is prefixed with `k8s:enc:kms:v1:` for KMS v1 or prefixed with `k8s:enc:kms:v2:` for KMS v2, which indicates that the `kms` provider has encrypted the resulting data. 1. Verify that the secret is correctly decrypted when retrieved via the API: ```shell kubectl describe secret secret1 -n default ``` The Secret should contain `mykey: mydata` ## Ensuring all secrets are encrypted When encryption at rest is correctly configured, resources are encrypted on write. Thus we can perform an in-place no-op update to ensure that data is encrypted. The following command reads all secrets and then updates them to apply server side encryption. If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update. ```shell kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` ## Switching from a local encryption provider to the KMS provider To switch from a local encryption provider to the `kms` provider and re-encrypt all of the secrets: 1. Add the `kms` provider as the first entry in the configuration file as shown in the following example. ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - kms: apiVersion: v2 name : myKmsPlugin endpoint: unix:///tmp/socketfile.sock - aescbc: keys: - name: key1 secret: <BASE 64 ENCODED SECRET> ``` 1. Restart all `kube-apiserver` processes. 1. Run the following command to force all secrets to be re-encrypted using the `kms` provider. ```shell kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` ## {{% heading "whatsnext" %}}  <a id="disabling-encryption-at-rest" /> If you no longer want to use encryption for data persisted in the Kubernetes API, read [decrypt data that are already stored at rest](/docs/tasks/administer-cluster/decrypt-data/).

This section details how to verify that data is encrypted at rest using `etcdctl` and kubectl. It explains how to check for the `k8s:enc:kms:v1:` or `k8s:enc:kms:v2:` prefix in etcd and how to ensure all secrets are encrypted by performing an in-place update. It also provides instructions on switching from a local encryption provider to a KMS provider, which involves updating the encryption configuration, restarting the API servers, and re-encrypting all secrets. Finally, it points to instructions for disabling encryption if it's no longer desired.