Change:
1. Create a new encryption configuration file using the appropriate properties for the `kms` provider: <del> ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - kms: name: myKmsPlugin endpoint: unix:///tmp/socketfile.sock cachesize: 100 timeout: 3s - identity: {} ``` 2. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file. 3. Restart your API server. Note: The alpha version of the encryption feature prior to 1.13 required a config file with `kind: EncryptionConfig` and `apiVersion: v1`, and used the `--experimental-encryption-provider-config` flag. </del> <ins> ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - kms: name: myKmsPlugin endpoint: unix:///tmp/socketfile.sock cachesize: 100 timeout: 3s - identity: {} ``` 1. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file. 1. Restart your API server. </ins> ## Verifying that the data is encrypted <del> Data is encrypted when written to etcd. After restarting your kube-apiserver, any newly created or updated secret should be encrypted when stored. To verify, you can use the etcdctl command line program to retrieve the contents of your secret. 1. Create a new secret called secret1 in the default namespace: ``` kubectl create secret generic secret1 -n default --from-literal=mykey=mydata ``` 2. Using the etcdctl command line, read that secret out of etcd: ``` ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C ``` where `[...]` must be the additional arguments for connecting to the etcd server. 3. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data. </del> <ins> Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or updated secret should be encrypted when stored. To verify, you can use the `etcdctl` command line program to retrieve the contents of your secret. </ins> <del> 4. Verify that the secret is correctly decrypted when retrieved via the API: ``` kubectl describe secret secret1 -n default ``` should match `mykey: mydata` </del> <ins> 1. Create a new secret called secret1 in the default namespace: ``` kubectl create secret generic secret1 -n default --from-literal=mykey=mydata ``` 1. Using the etcdctl command line, read that secret out of etcd: ``` ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C ``` where `[...]` must be the additional arguments for connecting to the etcd server. 1. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data. 1. Verify that the secret is correctly decrypted when retrieved via the API: ``` kubectl describe secret secret1 -n default ``` should match `mykey: mydata` </ins> ## Ensuring all secrets are encrypted Because secrets are encrypted on write, performing an update on a secret encrypts that content. <del> 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. </del> <ins> 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. </ins> ``` 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. <del> ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - kms: name : myKmsPlugin endpoint: unix:///tmp/socketfile.sock cachesize: 100 - aescbc: keys: - name: key1 secret: <BASE 64 ENCODED SECRET> ``` 2. Restart all kube-apiserver processes. 3. Run the following command to force all secrets to be re-encrypted using the `kms` provider. ``` kubectl get secrets --all-namespaces -o json| kubectl replace -f - ``` </del> <ins> ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - kms: name : myKmsPlugin endpoint: unix:///tmp/socketfile.sock cachesize: 100 - 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. ``` kubectl get secrets --all-namespaces -o json| kubectl replace -f - ``` </ins> ## Disabling encryption at rest To disable encryption at rest: 1. Place the `identity` provider as the first entry in the configuration file: <del> ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - identity: {} - kms: name : myKmsPlugin endpoint: unix:///tmp/socketfile.sock cachesize: 100 ``` 2.  Restart all kube-apiserver processes. 3. Run the following command to force all secrets to be decrypted. ``` kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` </del> <ins> ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - identity: {} - kms: name : myKmsPlugin endpoint: unix:///tmp/socketfile.sock cachesize: 100 ``` 1. Restart all kube-apiserver processes. 1. Run the following command to force all secrets to be decrypted. ``` kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` </ins>

Discussion:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: There are indentation errors in the yaml files of EncryptionConfiguration. For example in the following yaml, lines after "- secrets" should indent two to the right. ! Proposed Solution: Correct the indentation errors. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Is it right to have in the fixed page?
I checked the preview page, and it's still wrong. I've close my PR.
It should looks like this or "secrets" is the subcontent of the second "resources", and "providers" is with the same level of the second "resources". Although I modified the markdown, the rendered webpage is still wrong.
/priority backlog /language en /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /priority backlog /language en /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten /assign