You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When connecting to a Kafka cluster using TLS, there doesn't seem to be any way to set the CA used to verify the Kafka broker's certificates. This forces the user to use insecureSkipVerify: true, which is not ideal for obvious reasons.
How could Crossplane help solve your problem?
Provide a new field under TLS configuration allowing the CA certificate to be set. It can be similar to the clientCertificate and look something like this:
Since trust bundles do not contain anything secret, I think we should load trust roots from configmaps instead of secrets. WDYT? It would allow users to use something like https://cert-manager.io/docs/trust/trust-manager/ to manage trust.
@jutley Until this feature is implemented, it is possible to inject trust on the provider level - if that suits your use case. I just made the provider trust a private CA by configuring the provider runtime:
What problem are you facing?
When connecting to a Kafka cluster using TLS, there doesn't seem to be any way to set the CA used to verify the Kafka broker's certificates. This forces the user to use
insecureSkipVerify: true
, which is not ideal for obvious reasons.How could Crossplane help solve your problem?
Provide a new field under TLS configuration allowing the CA certificate to be set. It can be similar to the clientCertificate and look something like this:
The text was updated successfully, but these errors were encountered: