Docs: recommend adding ClusterSecret resources to EncryptionConfiguration

[applejag]

Common Kubernetes hardening trick: encrypting secrets! :) Sorry for bigger issue, it just kind of grew.

---

Contrast to popular belief, Kubernetes Secrets are not protected by only basic base64 encoding. Kubernetes also has a encryption-at-rest feature.

From the Kubernetes API perspective (i.e when accessing kube-apiserver, such as via kubectl), you always get the decrypted version. Changing encryption-at-rest only changes how the objects are stored in etcd. The encryption and decryption is done by kube-apiserver only, so etcd has no knowledge by itself on how to access the encrypted resources. This does not help if an attacker gets kubectl access to your cluster, but it does help if an attacker gets access to etcd, or perhaps your etcd backups. This is solved by giving kube-apiserver a private key to encrypt and decrypt the data, either from a file or by using a KMS service to not store the sensitive encryption keys on the control-plane nodes.

Most common setups of Kubernetes either comes without encryption-at-rest, or it only encrypts a small subset of resources. Commonly only Secrets. As ClusterSecret resources store sensitive data, then they should also be included in that list.

Would be nice with a chapter in the installation docs to add ClusterSecret resources to the list of encrypted resources, if the user has encryption-at-rest enabled. Doesn't need to be super in-depth, but at least hinting to the Platform/DevOps engineers that there are some more recommended steps they might want to look into.

Docs:

• Kubernetes: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

  • For self-managed/self-hosted clusters, just tell people to update their EncryptionConfiguration and add the clustersecrets.clustersecrets.io to the list of resources

• AWS EKS: https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html

  • Would involve changing the resources part from ["secrets"] to ["secrets", "clustersecrets.clustersecrets.io"]

    aws eks associate-encryption-config \
        --cluster-name my-cluster \
        --encryption-config '[{"resources":["secrets","clustersecrets.clustersecrets.io"],"provider":{"keyArn":"arn:aws:kms:region-code:account:key/key"}}]'

• Azure AKS: https://learn.microsoft.com/en-us/azure/aks/use-kms-etcd-encryption

  • Doesn't seem configurable in AKS, so probably need to warn about this. If people want to strictly have them encrypted, then they must use data.valueFrom and store the actual sensitive data inside regular secrets. Maybe make it configurable in ClusterSecret operator to not allow the regular data field, so people can enforce this?

• GCP GKE: https://cloud.google.com/kubernetes-engine/docs/how-to/encrypting-secrets

  • Doesn't seem configurable in GKE either. Ditto the Azure AKS note above

• DigitalOcean Kubernetes:

  • Can't find anything in their documentation that suggests they even do encryption on normal secrets.

• Linode LKE:

  • Not configurable either: https://www.linode.com/community/questions/22956/is-encryption-provider-config-set-on-lke#answer-84308

---

On managed Kubernetes is kind of has less of an impact anyway, as the user of them don't even have access to etcd to begin with. It's more important if you are responsible of the etcd data storage and kube-apiserver hosting. This argument might be worth pointing out to the user as well, so they don't get freaked out that their secrets aren't encrypted at rest.