Revise “Encrypting Secret Data at Rest” (#18810)

* Drop reference to old Kubernetes versions

At the time of writing, Kubernetes v1.13 is the oldest supported
version, and encryption-at-rest is no longer alpha.

* Tidy whitespace

* Add table caption

* Set metadata for required Kubernetes version

content/en/docs/tasks/administer-cluster/encrypt-data.md

@@ -3,6 +3,7 @@ reviewers:
 - smarterclayton
 title: Encrypting Secret Data at Rest
 content_template: templates/task
+min-kubernetes-server-version: 1.13
 ---
 
 {{% capture overview %}}
@@ -13,9 +14,7 @@ This page shows how to enable and configure encryption of secret data at rest.
 
 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-* Kubernetes version 1.13.0 or later is required
+* etcd v3.0 or later is required
-
-* etcd v3 or later is required
 
 {{% /capture %}}
 
@@ -27,9 +26,6 @@ The `kube-apiserver` process accepts an argument `--encryption-provider-config`
 that controls how API data is encrypted in etcd. An example configuration
 is provided below.
 
-Note:
-The alpha version of the encryption feature prior to 1.13 used the `--experimental-encryption-provider-config` flag.
-
 ## Understanding the encryption at rest configuration.
 
 ```yaml
@@ -69,10 +65,6 @@ resources from storage each provider that matches the stored data attempts to de
 order. If no provider can read the stored data due to a mismatch in format or secret key, an error 
 is returned which prevents clients from accessing that resource. 
 
-Note:
-The alpha version of the encryption feature prior to 1.13 required to be configured with
-`kind: EncryptionConfig` and `apiVersion: v1`.
-
 {{< caution >}}
 **IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed), 
 the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to 
@@ -81,6 +73,7 @@ read that resource will fail until it is deleted or a valid decryption key is pr
 
 ### Providers:
 
+{{< table caption="Providers for Kubernetes encryption at rest" >}}
 Name | Encryption | Strength | Speed | Key Length | Other Considerations
 -----|------------|----------|-------|------------|---------------------
 `identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
@@ -95,12 +88,12 @@ is the first provider, the first key is used for encryption.
 __Storing the raw encryption key in the EncryptionConfig only moderately improves your security posture, compared to no encryption.
 Please use `kms` provider for additional security.__ By default, the `identity` provider is used to protect secrets in etcd, which
 provides no encryption. `EncryptionConfiguration` was introduced to encrypt secrets locally, with a locally managed key.
+
 Encrypting secrets with a locally managed key protects against an etcd compromise, but it fails to protect against a host compromise.
 Since the encryption keys are stored on the host in the EncryptionConfig YAML file, a skilled attacker can access that file and
-extract the encryption keys. This was a stepping stone in development to the `kms` provider, introduced in 1.10, and beta since 1.12. Envelope encryption
+extract the encryption keys.
-creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the
+
-kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than
+Envelope encryption creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than locally-stored encryption keys.
-locally-stored encryption keys.
 
 ## Encrypting your data
 
@@ -217,5 +210,3 @@ and restart all `kube-apiserver` processes. Then run the command `kubectl get se
 to force all secrets to be decrypted.
 
 {{% /capture %}}
-
-