Document custom resource encryption support (#38109)
* Add custom resource encryption support Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com> * Address review comments Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com> * Update reviewer list Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com> * Add wrapping Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com> * Address comments Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com> * Address comments Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com> * Address comments Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com> * Address comments Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com> Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>pull/38197/head
Rita Zhang
GitHub
parent
8001e39218
commit
765de36b1d
|
|
@ -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.
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue