<:robot:> `Listener` is `{port, protocol}` ([`assembly.proto#L39`](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3205a6946ca01ceeba7124188f8e18c52c6ce578/config/gitlab/bench/v1/assembly.proto#L39)). There's nowhere to put a certificate, a key, a client CA, or a verification stance. Two examples hit this from opposite directions: - GKG declared `mtlsEnabled: false`, accurate only by coincidence. The app process does serve plaintext, but its real posture is mesh-terminated mTLS via Istio and cert-manager, and the spec has no way to say so (gap 13 in the [GKG example gap table](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3205a6946ca01ceeba7124188f8e18c52c6ce578/examples/gkg/README.md#gaps-found)). - GATE/IAM claimed "mTLS certificates for all gRPC endpoints." That got demoted to an inference during review, because the STS-to-lookup path actually uses `insecure.NewCredentials()` and there was no field to hold cert material anyway (gap 4 in the [gate-iam example gap table](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3205a6946ca01ceeba7124188f8e18c52c6ce578/examples/gate-iam/README.md#gaps-found)). A schema that can't distinguish "plaintext" from "mTLS terminated one hop earlier" makes every security claim in a spec unverifiable. ## Context LB-D4 is settled: the chassis composes LabKit's [`v2/tls`](https://gitlab.com/gitlab-org/labkit/-/tree/df307e038980743f2e50a83cf718b1de2b50f352/v2/tls) rather than picking a transport-security model of its own. [gitlab-org/labkit#143](https://gitlab.com/gitlab-org/labkit/-/work_items/143) added the package plus `TLS`, `ProbeTLS`, and `TLSManager` on `httpserver.Config`. It serves TLS from a `kubernetes.io/tls` secret, hot-reloads on cert-manager rotation without dropping connections, and verifies client certificates in any of the four nginx `ssl_verify_client` modes. Certificate and key are string paths and the modes are string enums, so a consumer never imports `crypto/tls`. That collapses the design question on the Go side. The work here is surfacing the knobs in `bench.yaml` and wiring LabKit's config struct in the generated entrypoint, not designing inbound TLS. Full scope was worked out in the [2026-08-28 comment on this epic](https://gitlab.com/groups/gitlab-org/lab-bench/-/epics/4#note_3926390265), including the proposed message shape. ## Proposed approach TLS is a property of the socket rather than the route layer, so it belongs on `Listener`: ```protobuf message Listener { uint32 port = 1; Protocol protocol = 2; ListenerTLS tls = 3; // absent = plaintext } message ListenerTLS { bool enabled = 1; // tls.enabled string cert_file = 2; // mounted tls.crt string key_file = 3; // mounted tls.key repeated string client_ca_files = 4; // tls.clientCAs ClientAuth client_auth = 5; // off | optional_no_ca | optional | on } ``` Field names mirror gitlab-org/labkit#143 for a one-to-one manifest-to-config mapping. Additive, so `buf breaking` stays green. Two validator defaults come from gitlab-org/labkit#143 and are deliberately not the registry Helm chart's behavior: - A client CA present with no explicit mode defaults to `optional`, not `on`. The chart enforces on CA presence; gitlab-org/labkit#143 doesn't, so an operator can stage a CA before a hop is ready to require mTLS. bench matches LabKit here. - The probe listener stays plaintext unless `ProbeTLS` is set explicitly. It doesn't inherit the serving listener's config, because a Kubernetes gRPC probe can't speak TLS. ## Acceptance criteria - [ ] `ListenerTLS` is in the schema and `buf breaking` is green - [ ] A client CA with no explicit mode validates to `optional` - [ ] The probe listener stays plaintext unless explicitly configured - [ ] The Go entrypoint generator builds `httpserver.Config{TLS: ...}` from the manifest, with no `crypto/tls` import in generated code - [ ] The Rust generator wires `cert_file`, `key_file`, and `enabled` via labkit-rs `ServerTls` - [ ] A Rust assembly declaring `client_auth` or `client_ca_files` fails validation with a message naming the labkit-rs gap, rather than building and silently ignoring it - [ ] GKG's spec expresses mesh-terminated mTLS, and gap 13 is retired - [ ] GATE/IAM's transport claim becomes checkable rather than an inference, and gap 4's inbound half is retired - [ ] An upstream issue exists against labkit-rs for client-CA support on `ServerTls` ## Rust is partly blocked, and the blocker is narrower than "no TLS" [labkit-rs](https://gitlab.com/gitlab-org/rust/labkit-rs) does have a TLS module. [`labkit/src/tls.rs`](https://gitlab.com/gitlab-org/rust/labkit-rs/-/blob/main/labkit/src/tls.rs) provides `ServerTls` with cert and key paths plus a `min_version` knob, and its own doc comment says it mirrors the Go split: "`v2/tls` holds the policy and `v2/httpserver` runs the listener." So `enabled`, `cert_file`, and `key_file` are wireable in Rust today. What's missing is client verification. [`tls.rs`](https://gitlab.com/gitlab-org/rust/labkit-rs/-/blob/main/labkit/src/tls.rs) builds its `rustls::ServerConfig` with `with_no_client_auth()` hardcoded, and the `ServerTls` builder exposes only `builder(cert_path, key_path)`, `min_version`, and `build`. There's no client-CA input and no equivalent of the four nginx `ssl_verify_client` modes. So the accurate split is: - `cert_file`, `key_file`, and `enabled` wire in both languages. - `client_ca_files` and `client_auth` wire in Go only, and need a labkit-rs change (client-CA support on `ServerTls`) before Rust can honor them. That's a smaller, more filable upstream ask than "add a TLS module," and the validator should reject a Rust assembly declaring `client_auth` until it lands rather than silently ignoring it. Part of [DM-4: Phase 1 Inbound](https://gitlab.com/groups/gitlab-org/lab-bench/-/epics/4). </:robot:>