: Guidance Needed: Production Migration from Ingress + Vault cert-manager to Envoy Gateway with BackendTLSPolicy

[BhaskarareddyS]

Hi team,

I’m migrating an existing Kubernetes Ingress setup to Envoy Gateway and would like guidance on the recommended production approach.

Current setup:

• Public host: bas.example.com
• TLS is currently managed through cert-manager with a Vault issuer.
• The certificate SAN for the current ingress secret includes bas.example.com.
• The backend Service listens on port 443.
• We currently use a sidecar-based process to create or mount the TLS secret for ingress.

What I want to understand:

• What is the best practice for migrating this setup to Envoy Gateway?

• Should the public TLS certificate be managed directly on the Gateway using cert-manager and the Vault issuer?

• For the backend Service on port 443, should we use BackendTLSPolicy with a backend CA ConfigMap?

• What should BackendTLSPolicy.hostname be set to in production: the public hostname bas.example.com, or the backend service DNS name / backend certificate SAN?

• Is there a recommended way to preserve the current certificate lifecycle without the sidecar-based secret creation flow?

• Are there any production examples or reference manifests you recommend for this pattern?

If helpful, I can share the current Ingress YAML, cert-manager annotations, Vault issuer config, and backend Service details.

Thanks.

[arkodg]

Should the public TLS certificate be managed directly on the Gateway using cert-manager and the Vault issuer?

https://cert-manager.io/docs/usage/gateway/ highlights the cert-manager GW API integration

For the backend Service on port 443, should we use BackendTLSPolicy with a backend CA ConfigMap?

yeah this is the right approach

What should BackendTLSPolicy.hostname be set to in production: the public hostname bas.example.com, or the backend service DNS name / backend certificate SAN?

Backend Cert SAN

Is there a recommended way to preserve the current certificate lifecycle without the sidecar-based secret creation flow?

you should be able to create this in parallel with your current infra, and use a lever in front of the 2 Ingresses (DNS or another Proxy) to incrementally steer traffic to the new Ingress

Are there any production examples or reference manifests you recommend for this pattern?
@apkatsikas recently wrote one that leverages ExternalDNS https://www.cncf.io/blog/2026/05/25/zero-downtime-migration-from-ingress-nginx-to-envoy-gateway/ !
https://gateway.envoyproxy.io/docs/install/migrating-to-envoy/#example-migration doesnt have any operational details unfortunately
hoping you can enhance them post migration

[BhaskarareddyS]

Thank you for your response.

Regarding BackendTLSPolicy and HTTPRoute:

Let’s say the HTTPRoute is configured with the hostname bas.example.com. Would it be appropriate to use the same hostname (bas.example.com) as the SAN for hostname validation in BackendTLSPolicy in a production environment?

Could you kindly suggest whether this is the recommended approach?