Update encryption-at-rest task page #33285
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
k8s-ci-robot
added
the
sig/docs
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
ae0db33
to
98312e7
Compare
k8s-ci-robot
added
the
needs-rebase
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
98312e7
to
0320672
Compare
k8s-ci-robot
removed
the
needs-rebase
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
0320672
to
98d87a4
Compare
sftim
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
@divya-mohan0209 are you happy with the changes I made here? |
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
98d87a4
to
dd1681a
Compare
| is the first provider, the first key is used for encryption. | ||
| You can configure multiple providers, and each provider (other than `identity`, which does not encrypt) supports multiple keys. | ||
| For encryption, the API server uses the first configured key from the first provider. | ||
| For decryption, the API server tries each key in order for decryption, stopping when decryption succeeds. |
There was a problem hiding this comment.
Do we intend to say sequential order? I think making that clear might help.
| For decryption, the API server tries each key in order for decryption, stopping when decryption succeeds. | |
| For decryption, the API server tries each key in order for decryption, stopping when decryption succeeds. |
There was a problem hiding this comment.
What's the different wording you're suggesting @divya-mohan0209 ?
There was a problem hiding this comment.
So, what I intended to ask was "For decryption, the API server tries each key in order for decryption, stopping when decryption succeeds." is the order sequential?
k8s-ci-robot
added
the
do-not-merge/work-in-progress
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
7944b8a
to
1e91951
Compare
|
I'll rebase this against current main. |
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
1e91951
to
700d4b5
Compare
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
700d4b5
to
e0e9537
Compare
|
|
||
| Some of the APIs in Kubernetes, such as {{< glossary_tooltip text="Secret" term_id="secret" >}}, | ||
| support at-rest encryption. This at-rest encryption is additional to any system-level | ||
| encryption for the etcd cluster or hosts where the kube-apiserver stores data persistently. |
There was a problem hiding this comment.
| encryption for the etcd cluster or hosts where the kube-apiserver stores data persistently. | |
| encryption for the etcd cluster or hosts where etcd stores data persistently. |
There was a problem hiding this comment.
@sftim we're trying to make a distinction between remote & in-house (for lack of a better word) etcd clusters here, yes?
There was a problem hiding this comment.
Actually I don't think this is about stacked etcd vs a separate cluster.
I think the point is that encryption at rest might also apply to, for example, audit logs written to the host filesystem by a static API server Pod.
If we make that change, then we're changing the meaning and would be leaving out that other scenario (logs, etc).
| Check whether the `kube-apiserver` process is running with the `--encryption-provider-config` | ||
| command line argument is set. If it is not, you do not have encryption at rest is enabled. |
There was a problem hiding this comment.
Sentences like these could be simplified?
There was a problem hiding this comment.
I think so, yes. If we can merge this as an improvement without rewriting, that's handy.
| Then the first-listed provider for a resource is something **other** than `identity`, | ||
| then any new information written to resources of that type will be encrypted as configured. | ||
|
|
||
| If you are not sure about the progress of any previous migration to encrypt data at rest, |
There was a problem hiding this comment.
This paragraph doesn't flow. I don't know why we suddenly jump to this sub-topic.
There was a problem hiding this comment.
Are you able to recommend a different place to put this advice @tengqm ? If so, I can move it there.
There was a problem hiding this comment.
Maybe this warrants a dedicated subsection, "migrating to encryption at rest".
| Consider whether you need to make a backup of that configuration. If you do, | ||
| also think about how you will ensure that your backup is secure. |
There was a problem hiding this comment.
I'd prefer reading simple clear text over this. I mean:
You may want to create a secure backup of the configuration file.
| ``` | ||
|
|
||
| …and then restart each API server in turn. This change prevents the API server | ||
| from accessing a plain-text Secret, even by accident. |
There was a problem hiding this comment.
This may and may not be a good practice. It depends.
If I'm using one provider today and I'm migrating to a different provider tomorrow, keeping identity there may be convenient. I don't know. My gut feeling is that an assertion like this should be made carefully.
There was a problem hiding this comment.
When is it not a good practice to remove the identity provider?
|
|
||
| When running a single `kube-apiserver` instance, step 2 may be skipped. | ||
| 1. Generate a new key and add it as the second key entry for the current provider on all | ||
| control plane hosts (strictly speaking: on all hosts that run a `kube-apiserver`). |
There was a problem hiding this comment.
| control plane hosts (strictly speaking: on all hosts that run a `kube-apiserver`). | |
| nodes that run a `kube-apiserver` process. |
There was a problem hiding this comment.
My wording avoids assuming that the kube-apiserver is running inside Pods. I will try to find another wording that also works for the common case where there are control plane nodes.
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
3e76938
to
6a235f3
Compare
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
6a235f3
to
5673fc1
Compare
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
5673fc1
to
d9756d9
Compare
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
d9756d9
to
b65a904
Compare
k8s-ci-robot
added
size/M
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
b65a904
to
2c40443
Compare
k8s-ci-robot
added
size/L
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
2c40443
to
1ecc17d
Compare
This comment was marked as spam.
This comment was marked as spam.
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
1ecc17d
to
734cff8
Compare
|
To move this forward, please review #44622, or suggest another part of the page that I can split out. |
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
734cff8
to
19ce31d
Compare
|
I'd be happy to see these changes land in one batch, if that's feasible; if not, please see PR #44622 |
| {{< note >}} | ||
| For cluster configurations with two or more control plane nodes, the encryption configuration | ||
| should be identical across each control plane node. |
There was a problem hiding this comment.
This is repeated as a caution block later in the file (under the heading ”Reconfigure other control plane hosts”).
I think the advice bears repeating. Get this wrong and you can really end up regretting it.
| When you are planning to update the encryption configuration of your cluster, plan this | ||
| so that the API servers in your control plane can always decrypt the stored data | ||
| (even part way through rolling out the change). |
There was a problem hiding this comment.
This advice is new as of today.
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
19ce31d
to
8bba96e
Compare
|
See #44622 which I recommend reviewing before this one. |
Co-authored-by: Divya Mohan <[email protected]> Co-authored-by: Qiming Teng <[email protected]>
sftim
force-pushed
the
20220428_revise_encryption_at_rest
branch
from
8bba96e
to
c91ebf4
Compare
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
Doubt I'll find time to finish this. /close |
|
@sftim: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Revise Encrypting Secret Data at Rest [preview]
This is an overall PR and I am splitting out smaller PRs - scroll down to see more
Use HTML table [preview] in place of harder-to-read Markdown version.Split PRs (current / recent set):
Revise callouts in encryption-at-rest task page #44622Reword advice about encryption-at-rest opt outs #44951