CRD storage not recommended as API?

[shishkin]

I came across cautioning notes in the docs and other comments that CRDs should not be used directly to configure Dex. I could not find any rationale of that though. Could someone explain that please?

I think in K8s context adding clients via CRDs allows for some inversion of control and cleaner deployment automation codebase where apps can add themselves as clients. But particular quirks around metadata.name hashing make it unnecessary difficult. So I'm puzzled if CRD are not recommended just yet or will not going to be recommended, and what will be?

[nabokihms]

The doc states that it is not an expected approach. CRDs are used as internal storage that should be kept from end users. gRPC is preferable.

However, if you manually create a valid oauth2client, it will work. Consider it the same as adding an entry directly to a database of your (hypothetical) application.

[shishkin]

Yes, that's the reason I'm asking. I would expect DB schema to be internal implementation detail without any versioning and stability guarantees. So, why would not Dex on K8s want to make CRD API first-class?

[nabokihms]

Because it is already has an interface - gRPC API.
To support another API, it requires either a standard for API interfaces with different implementations, e.g. CRD API, gRPC API, HTTP API, or an adapter between CRDs and gRPC.

[shishkin]

I see. Still, I would suggest considering a more declarative API like CRDs or a Terraform provider. I'd like to be able to provision my whole setup with Terraform and it's not very obvious how to operate CRUD gRPC API from Terraform.