Rke: Consider using secret instead of configmap for new state file

[riaan53]

RKE version:
master branch (1295f6)

Hi, I know its not yet released but I just want to bring it to your attention before it is. I see the new state refactor from https://github.com/rancher/rke/pull/1009 stores the full state in a config map, this includes ssh private keys and all other kubernetes keys. Will it be possible to use a secret instead and then later https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ ? The data size limit is the same for both (1MB in size).

Regards,
Riaan

Edit: It looks like its possible (havnt tried) to encrypt any resource with encrypted-data but using secrets might suite this use case better in terms of permissions and future enhancements to secrets.

[cristifalcas]

There is no difference between secrets and config maps as a security concern, from my point of view. Secrets are just base64.

Also encryption can be done over any resource, like you said.

[alena1108]

@cristifalcas @riaan53 Also encryption can be done over any resource, like you said. this is correct.

but using secrets might suite this use case better in terms of permissions

can't think of any advantages permission wise for secrets vs config maps. So lets keep the issue open and revise in case the below comes up in k8s

and future enhancements to secrets.

[raesene]

I got directed over here, as I noticed this behaviour in RKE at the moment.

My $0.02 on the benefit of secrets over configmaps is not in specific RBAC considerations but in clarity of messaging to cluster operators.

General advice is to avoid logging secrets and also to take care in granting access to them, as they will contain sensitive information. Also the content of secrets should not be logged by Kubernetes.

The same security advice is not generally given about configmaps as they are not expected to hold sensitive information, so it would be an improvement to use a secret object.

Ideally from a security perspective the private TLS keys (especially the CA key) would not be held anywhere in the Kubernetes API, as read access to that key provides an effective backdoor into the cluster, for the lifetime of the CA certificate.