diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index 03a28ccd60..a601c8b1ca 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -2,6 +2,7 @@ title: Encrypting Secret Data at Rest reviewers: - smarterclayton +- enj content_type: task min-kubernetes-server-version: 1.13 --- @@ -15,6 +16,9 @@ This page shows how to enable and configure encryption of secret data at rest. * etcd v3.0 or later is required +* To encrypt a custom resource, your cluster must be running Kubernetes v1.26 or newer. + + ## Configuration and determining whether encryption at rest is already enabled @@ -39,6 +43,8 @@ kind: EncryptionConfiguration resources: - resources: - secrets + - configmaps + - pandas.awesome.bears.example providers: - identity: {} - aesgcm: @@ -60,9 +66,16 @@ resources: ``` Each `resources` array item is a separate config and contains a complete configuration. The -`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group`) -that should be encrypted. The `providers` array is an ordered list of the possible encryption -providers. +`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group` +that should be encrypted like Secrets, ConfigMaps, or other resources. + +If custom resources are added to `EncryptionConfiguration` and the cluster version is 1.26 or newer, +any newly created custom resources mentioned in the `EncryptionConfiguration` will be encrypted. +Any custom resources that existed in etcd prior to that version and configuration will be unencrypted +until they are next written to storage. This is the same behavior as built-in resources. +See the [Ensure all secrets are encrypted](#ensure-all-secrets-are-encrypted) section. + +The `providers` array is an ordered list of the possible encryption providers to use for the APIs that you listed. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided, but not both in the same item). @@ -100,11 +113,11 @@ Storing the raw encryption key in the EncryptionConfig only moderately improves posture, compared to no encryption. Please use `kms` provider for additional security. {{< /caution >}} -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 +By default, the `identity` provider is used to protect secret data in etcd, which provides no +encryption. `EncryptionConfiguration` was introduced to encrypt secret data locally, with a locally managed key. -Encrypting Secrets with a locally managed key protects against an etcd compromise, but it fails to +Encrypting secret data 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 EncryptionConfiguration YAML file, a skilled attacker can access that file and extract the encryption keys. @@ -123,6 +136,8 @@ kind: EncryptionConfiguration resources: - resources: - secrets + - configmaps + - pandas.awesome.bears.example providers: - aescbc: keys: @@ -191,8 +206,9 @@ permissions on your control-plane nodes so only the user who runs the `kube-apis ## Verifying that data is encrypted Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or -updated Secret should be encrypted when stored. To check this, you can use the `etcdctl` command line -program to retrieve the contents of your Secret. +updated Secret or other resource types configured in `EncryptionConfiguration` should be encrypted +when stored. To check this, 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: diff --git a/content/en/docs/tasks/administer-cluster/kms-provider.md b/content/en/docs/tasks/administer-cluster/kms-provider.md index a2f794d3d8..74ae9000ad 100644 --- a/content/en/docs/tasks/administer-cluster/kms-provider.md +++ b/content/en/docs/tasks/administer-cluster/kms-provider.md @@ -1,6 +1,7 @@ --- reviewers: - smarterclayton +- enj title: Using a KMS provider for data encryption content_type: task --- @@ -146,7 +147,9 @@ Ensure that the KMS plugin runs on the same host(s) as the Kubernetes master(s). To encrypt the data: -1. Create a new `EncryptionConfiguration` file using the appropriate properties for the `kms` provider to encrypt resources like Secrets and ConfigMaps. +1. Create a new `EncryptionConfiguration` file using the appropriate properties for the `kms` provider +to encrypt resources like Secrets and ConfigMaps. If you want to encrypt an extension API that is +defined in a CustomResourceDefinition, your cluster must be running Kubernetes v1.26 or newer. 1. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file. @@ -160,6 +163,8 @@ To encrypt the data: resources: - resources: - secrets + - configmaps + - pandas.awesome.bears.example providers: - kms: name: myKmsPluginFoo @@ -181,6 +186,8 @@ To encrypt the data: resources: - resources: - secrets + - configmaps + - pandas.awesome.bears.example providers: - kms: apiVersion: v2 @@ -203,8 +210,8 @@ For details about the `EncryptionConfiguration` format, please check the ## Verifying that the data is encrypted 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. +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: diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md index c5e253a7ac..d864bb1d32 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -2,8 +2,7 @@ reviewers: - smarterclayton - liggitt -- ericchiang -- destijl +- enj title: Securing a Cluster content_type: task --- @@ -255,11 +254,14 @@ and may grant an attacker significant visibility into the state of your cluster. your backups using a well reviewed backup and encryption solution, and consider using full disk encryption where possible. -Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature -introduced in 1.7, v1 beta since 1.13, and v2 alpha since 1.25. This will encrypt resources like `Secret` and `ConfigMap` in etcd, preventing -parties that gain access to your etcd backups from viewing the content of those secrets. While -this feature is currently beta, it offers an additional level of defense when backups -are not encrypted or an attacker gains read access to etcd. +Kubernetes supports optional [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) for information in the Kubernetes API. +This lets you ensure that when Kubernetes stores data for objects (for example, `Secret` or +`ConfigMap` objects), the API server writes an encrypted representation of the object. +That encryption means that even someone who has access to etcd backup data is unable +to view the content of those objects. +In Kubernetes {{< skew currentVersion >}} you can also encrypt custom resources; +encryption-at-rest for extension APIs defined in CustomResourceDefinitions was added to +Kubernetes as part of the v1.26 release. ### Receiving alerts for security updates and reporting vulnerabilities