Building-permits needs HTTPS termination on a Gateway listener using a certificate already stored in the cluster. What configuration approach fits Gateway API?
Select an answer to reveal the explanation.
Short Explanation
Put the lock on the front door: terminate TLS on the Gateway listener and point it at the certificate Secret. That keeps HTTPS at the shared entrypoint instead of stuffing keys into random ConfigMaps or route annotations.
Full Explanation
Building-permits should terminate HTTPS on the Gateway listener and reference the Kubernetes Secret that already holds the certificate material. Gateway API models TLS on listeners so the shared municipal entrypoint presents HTTPS centrally—one lock on the front door—while Routes continue to match hosts and paths to Services. Referencing a TLS Secret from the listener configuration is the standard edge-termination approach for consortium-wide certificates.
Encoding the certificate as a binary annotation on every HTTPRoute path is non-portable, unmanageable, and not how Gateway API expresses listener TLS. Storing the private key in a ConfigMap mounted into CoreDNS confuses DNS configuration with certificate distribution and places secrets in an inappropriate object type. Leaving the Gateway permanently cleartext while terminating only inside each Pod may be a deliberate mTLS/app pattern in some designs, but it does not configure Gateway listener TLS with a Secret reference—the question asks for the Gateway API termination approach.
Exam caveat: Secret must be of an expected TLS type and readable by the Gateway controller’s service account; hostname on the certificate should match listener/route hosts. Passthrough versus terminate modes differ—know which your listener uses.
Operational check: create or locate the TLS Secret, set the Gateway listener protocol/TLS mode and certificateRefs, apply, confirm listener status is programmed, then openssl s_client or curl against the Gateway HTTPS port for the permits hostname.