Feature: Support kubernetes.io/tls instead of only Opaque

[a-nldisr]

As I understand from the Kubernetes documentation the kubernetes.io/tls only difference is enforcing DER standards and that the key/cert is present. So consider this as a nice-to-have feature request.

Current code only supports Opaque Kubernetes secrets. https://github.com/DopplerHQ/kubernetes-operator/blob/98ce8ccbefada12a4fa2ebff778f311059cbec5a/controllers/dopplersecret_controller_secrets.go#L196 Having the operator create kubernetes.io/tls when a certificate is present would be nice!

[nmanoogian]

Thanks for recommending this, @a-nldisr! I'll pass this along to our product team and let you know if we have any follow-up questions or info.

[a-nldisr]

Want to extend this feature request with other types: https://kubernetes.io/docs/concepts/configuration/secret/#secret-types

[nmanoogian]

Thanks @a-nldisr 👍

[emmeowzing]

I'll second this, I want to be able to generate other secret types (particularly type kubernetes.io/tls) as well. Kind of makes this product unusable for me, unfortunately. That, as well as not having a transformer (your docs state we can only make all upper-cased env var names in the console at this time) to make the keys the correct format (i.e. transform TLS_CRT -> tls.crt).

https://kubernetes.io/docs/concepts/services-networking/ingress/#tls https://github.com/DopplerHQ/kubernetes-operator/tree/caeb2c262685f37bf7f5e3013eba70a4b1724d6d#name-transformers

[emmeowzing]

It looks like all the operator does as far as key string manipulation is make an API call and the transforms are built into the API ~

https://docs.doppler.com/docs/accessing-secrets#name-transformers

Unfortunate that a product update on that end needs to be made for something as simple as manipulating a string. We can probably work around that for now by handling this case locally after the API call.

[watsonian]

Support for this was added in https://github.com/DopplerHQ/kubernetes-operator/pull/47. You can read more about it in the docs.