Envoy Gateway Backend TLS Secret Management Across Namespaces

[chetan94k]

We have a use case where user applications are deployed across different k8s namespaces, with each namespace containing all application-related resources. We are terminating TLS at the gateway and then re-initiating TLS to the backend services.

The client certificate and CA required for backend TLS are common across all applications, since the client certificate contains a wildcard SAN (*.[sub-domain].[domain]).

With Envoy Gateway, backend TLS configuration requires the referenced Secrets/ConfigMaps to exist in the same namespace as the backend, as cross-namespace secret access is not allowed. Because of this, we currently need to replicate the same Secrets/ConfigMaps into every tenant namespace, which adds operational overhead.

Any thoughts on whether there is a better or more scalable way to handle this? Is there a way to globally set backend client and CA ?

[arkodg]

the project supports ClusterTrustBundle which you could define once and use it across multiple BackendTLSPolicies

[chetan94k]

Thanks @arkodg ClusterTrsutBundle can be used for CA but what about "client certificates" that is also needed to be configured in backend? Any workaround for this?