Is the Kubernetes CRD storage option considered as secure as using Secrets?

[dippynark]

The Kubernetes CRD storage option stores sensitive data (e.g. signing keys) unencrypted in etcd and Kubernetes distributions typically only offer the ability to encrypt Secrets using a user-managed KMS key (for example GKE application-layer secrets encryption).

Although convenient, this seems like it would pose an issue for organisations that require sensitive data is stored using an encryption key that they manage and breaks the assumption that sensitive data is only stored in the Kubernetes API through Secret resources.

Are there any arguments for why this storage option is as secure as using Kubernetes Secrets or is the advice that another storage option be used if a dex user wants to conform to this kind of organisational policy?

[nabokihms]

It depends on your Kubernetes settings. It is possible to encrypt any kind of object.

[dippynark]

@nabokihms yeah of course, but typically only Secrets are offered by managed distributions, which greatly limits where Dex can be run without external mitigations.

I guess the answer here is no and that without these mitigations in place a different storage backend should be used.

[nabokihms]

Dex doesn't support any
storage encryption out of the box, so the security of the data tightly depends on the storage settings.

This rule works for every storage. In your case, if it is impossible to tune
Kubernetes, trying another
storage option seems reasonable.