Option to enable data encryption at-rest
bighiro opened this issue · comments
What would you like to be added (User Story)?
As an cluster admin, I should be able to enable the data encryption during the cluster bootstrap.
Detailed Description
Requesting for an option to create and enable the data encryption during the kubadm bootstrap in control-plane
There are some other flavors like RKE, where the option to enable the secret encryption is provided, which automatically created the encryptionproviderconfig file and enables it in the api-server.
Reference : https://rke.docs.rancher.com/config-options/secrets-encryption#enable-encryption
Expecting for the similar behaviour with clusterapi , irrespective with providers
Anything else you would like to add?
No response
Label(s) to be applied
/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.
This issue is currently awaiting triage.
If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
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.
data encryption requires configurations when layout out control plane components.
In Cluster API this is a responsibility of control plane providers; most of them are implemented outside of this repo, while we have a KCP control plane provider in tree.
Doing encryption at rest in KCP is alredy possible by doing two settings:
- set apiserver.extraArgs[encryption-provider-config] to something like /etc/kubernetes/extra-config/encryption-config.yaml
- add the /etc/kubernetes/extra-config/encryption-config.yaml file
I don't see much value in reducing two settings into one; also this will imply some opinionated decision about what to put into the encryption-config.yaml file, which a product like Rancher can do, but the community cannot unless there is agreement.
Considering this I'm personally -1 to the idea, unless we come up with some consensus about encryption-config, related certificates etc.
/priority backlog
/kind proposal
(assuming we have to write a proposal to get/document consensus)