Support secretbox for Secret Data at Rest

[FischerLGLN]

Is your feature request related to a problem? Please describe.

In this article, either secretbox or kms are used to encrypt Secret Data at Rest.

However, Rancher still uses aescbc which is considered weak due to padding oracle attacks.
Describe the solution you'd like

Support of secretbox or kms. For me, secretbox is preferred due to avoiding another cloud service or selfhosted kms. Recently, Talos Linux has implemented the support too.

Describe alternatives you've considered

kms

[brandond]

cc @macedogm @cwayne18 @briandowns - do you know if we're allowed by FIPS to use secretbox? KMS is obviously an external option that users would have to configure on their own, but I'm not sure what other algs we're allowed to configure while remaining compliant.

[FischerLGLN]

@brandond Similar Issue, even mentioning RKE2 for the FIPS compliance approach, getting popular! AES-256-GCM seems fips compliant too, but how to know if the key needs to be rotated if it depends on the writes?

From the linked Issue:

NaCL Secretbox is not FIPS-compliant, even though it is widely regarded as better in every way.

More secure vs officially approved security.

[macedogm]

@brandond as mentioned by @FischerLGLN, NaCl Secretbox (XSalsa20 and Poly1305) is not FIPS compliant. The annex with FIPS approved security functions is available in https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf.

[macedogm]

More secure vs officially approved security.

Yes, there is always a trade off.

[macedogm]

do you know if we're allowed by FIPS to use secretbox?

I don't know this answer. It would be best to double check.

Just to clarify, Secretbox is not on the list of approved algorithms by FIPS. What I don't know is if we could still implement it as an optional algorithm, flag it as non FIPS compliant, and still by fine with the FIPS certification for the approved algorithms. I bet that this is not possible and would invalidate the FIPS certification, but I can be wrong here.

[FischerLGLN]

@macedogm It seems like OKD is fine with AES GCM. I used OKD for a few months and now try to achieve the same security but much easier daily use with RKE 2.

From another OKD link:

When you enable etcd encryption, encryption keys are created. These keys are rotated on a weekly basis. You must have these keys to restore from an etcd backup.

They have to be using there authentication.operator for rotation after 7 days.

[FischerLGLN]

@macedogm

Just to clarify, Secretbox is not on the list of approved algorithms by FIPS. What I don't know is if we could still implement it as an optional algorithm, flag it as non FIPS compliant, and still by fine with the FIPS certification for the approved algorithms. I bet that this is not possible and would invalidate the FIPS certification, but I can be wrong here.

Optional like the CNI solutions!

As of v1.21.2, RKE2 supports selecting a different CNI via the --cni flag and comes bundled with several CNIs including Canal (default), Calico, Cilium, and Multus. Of these, only Canal (the default) is rebuilt for FIPS compliance.

So for the secret data at Rest, this could sound like this:

As of v1.25.4, RKE2 supports selecting a different secret data at Rest algorithm via the encryption config and comes bundled with several algorithms including aescbc (default) and NaCl Secretbox. Of these, only aescbc (the default) is rebuilt for FIPS compliance. ☐

[FischerLGLN]

@macedogm Any news?

[macedogm]

Hi @FischerLGLN. Apologies the delay here. I believe that it should be fine to implement this as an optional supported algorithm. Ideally it should not interfere with the FIPS certification. However, the last call must be made by RKE2 team - @cwayne18, @brandond and @briandowns.

[Agalin]

My team is interested in this too. Ideal would be just being able to pass custom configuration if needed (so kms or future algorithms can be configured) but even just secretbox would be nice.

[brandond]

You can already pass a custom encryption config to the apiserver if you want, you just can't use the secrets-encrypt CLI subcommands to manage it if you do that.

[brandond]

@dereknola do you want to share your benchmark results?

[Agalin]

You can already pass a custom encryption config to the apiserver if you want, you just can't use the secrets-encrypt CLI subcommands to manage it if you do that.

Really? That's a great news. But it also means secrets documentation could be a bit improved - multiple people from my team concluded after reading it that AES-CBC is the ONLY encryption that RKE2 allows (either that or no encryption at all).

[brandond]

It is the only option supported by our managed secrets encryption configuration. We don't remove any functionality from Kubernetes itself, if you override the config and manage it yourself you can do whatever you want.

[dereknola]

I passed secretbox as the custom encryption config to the apiserver and got the following:

rke2:
aes-cbc: 1000 secrets create in 1m 4s
secretbox: 1000 secrets create in 1m 2s

For K3s I also got the following:

k3s:
aes-cbc: 1000 secrets create in 1m 4s, update in 3m 20s
secretbox: 1000 secrets create in 55s, update in 3m 19s

In terms of overriding an providing your own config,

# /etc/rancher/rke2/config.yaml
kube-apiserver-arg:
  - encryption-provider-config=/tmp/ec.json

And put a valid https://kubernetes.io/docs/reference/config-api/apiserver-encryption.v1/ in /tmp/ec.json You won't be able to use any of the rke2 secrets-encrypt features.

[Agalin]

Thanks for extensive answers.

Now I'm only left with upvote of the original issue - addition of secretbox as an option for RKE2 secrets-encrypt.