infra: configure envoy gateway with cert-manager support

[TineoC]

Changes

• Add cert-manager.io/cluster-issuer: letsencrypt-prod annotation to main-gateway
• This enables automatic certificate provisioning when cert-manager is configured with enableGatewayAPI: true.

Depends on: #134

[TineoC]

This implementation is not entirely correct yet,

 Option 1: The "Shared Secret" Approach (Recommended for your current setup)
  Since your Gateway already references a single secret (main-gateway-tls), the cleanest way to satisfy
  cert-manager while supporting multiple projects is to list all hostnames on the Gateway listener. 

  cert-manager will then generate a single certificate (SAN) that covers all the listed domains.

    1 # infra/envoy-gateway-manifests/gateway.yaml
    2     - name: https
    3       protocol: HTTPS
    4       port: 443
    5       hostname: "*.sandbox.k8s.phl.io" # Use a wildcard if your DNS supports it
    6       # OR list them explicitly if they are different domains:
    7       # hostname: sandbox.balancerproject.org 
    8       allowedRoutes:
    9         namespaces:
   10           from: All
   11       tls:
   12         mode: Terminate
   13         certificateRefs:
   14           - name: main-gateway-tls

  Option 2: The "Merged Listeners" Approach
  If you want each project to have its own Certificate and Secret (e.g., balancer-tls, echo-http-tls),
  you define multiple listeners on the same port (443) with different names and specific hostnames. Envoy
  Gateway will automatically merge these onto the same physical port using SNI.

    1 # infra/envoy-gateway-manifests/gateway.yaml
    2   listeners:
    3     - name: balancer-https
    4       protocol: HTTPS
    5       port: 443
    6       hostname: sandbox.balancerproject.org
    7       tls:
    8         mode: Terminate
    9         certificateRefs:
   10           - name: balancer-tls
   11     - name: echo-https
   12       protocol: HTTPS
   13       port: 443
   14       hostname: echo-http.sandbox.k8s.phl.io
   15       tls:
   16         mode: Terminate
   17         certificateRefs:
   18           - name: echo-http-tls

I would like to hear your thoughts if you prefer to have a single cert for everyone or per-project certs

[themightychris]

@TineoC thanks for your work on this! Sorry for my slow turnaround on a review, I'll keep a tight loop going forward

Ugh I hate Gateway API lol... or at least that they're forcing us into this new paradigm because it's better for enterprise use cases

My instinct is option 2 but I'm not sure what the downsides would be

Looking at cert-manager's blog post about this challenge it looks like ListenerSet landed in February and is in the v1.5 CRDs you configured—could you take a look at the support for that and how it would work in Envoy?

Also your hologit configs are a bit messed up, you can use:

npx skills add --global JarvusInnovations/hologit

to enable your agent to set up and test and debug it

[TineoC]

https://cert-manager.io/announcements/2025/11/26/ingress-nginx-eol-and-gateway-api/#listenerset-the-missing-building-block The listener set resource looks promising, it would keep the setup similar to what we do while maintaining multi-tenancy.

[TineoC]

Version 1.20 of cert-manager added support for ListenerSet. Would you like to upgrade to this one and try this out? https://cert-manager.io/docs/releases/release-notes/release-notes-1.20/#v1200

[TineoC]

CodeForPhilly/balancer-main#482 this one is ready to merge

[TineoC]

Could you help me with upgrading cert-manager to 1.20? I still don't fully grasp how those manifests are being deployed into the cluster