Ability to change caCertificateRefs ca.crt key

[gcleroux]

When creating a BackendTLSPolicy, the caCertificateRefs key is statically set to ca.crt.
When using cluster-api to bootstrap workload clusters, the created $CLUSTER-ca secret will have the following keys: tls.crt and tls.key.

Having the ability to set the CA key to tls.crt would support these resources without having to use something like kyverno to add the ca.crt field to the secret.

Similar issue on Gateway API: kubernetes-sigs/gateway-api#4196

[zirain]

Before it's fixed on upstream, should we fallback to the first key when ca.crt didn't exist.

cc @envoyproxy/gateway-maintainers

[gcleroux]

I don't think upstream would actually fix this for secrets. The core implementation only supports ConfigMap and leave other resources to be implementation specific.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[gcleroux]

upstream merged implementation specific values for CA certs kubernetes-sigs/gateway-api#4401

[dpermus-ibm]

hi @gcleroux
The capability to specify a different key than ca.crt, or to fall back to the first key in the ConfigMap, is an important enhancement we are eagerly anticipating.
Kind regards
Darek

[arkodg]

falling back to first key wont work here, since the Secret has two keys, and can be read out of order
we could add a fallback to reading tls.crt if ca.crt doesnt exist, and then fallback to first key