feat: wire tls.peer into the listener — mtls for inbound - #441
Merged
Conversation
threads the manifest's tls.peer setting through the backend registry to the L7 listener: - Backend gains a peer_mode field (default .off) - BackendRegistry.register takes a peer_mode parameter - startup_runtime passes svc.tls.peer when registering each domain - handleTlsSession takes an optional MtlsOpts; the listener builds one from cluster CA + backend.peer_mode and passes it through - listener loads the cluster CA on demand; missing CA on a tls.peer service is a misconfiguration — logs and downgrades to plain TLS two new tests on BackendRegistry confirm peer_mode round-trips through register/lookup and is overwritten correctly. the end-to-end mTLS protocol is already covered by the socketpair tests in session_runtime (PR #439); this PR's contract is just "the listener picks up tls.peer and reaches acceptServerHandshake with the right MtlsOpts", which the type-level wiring proves.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
summary
second PR-5 chunk (after #440). wires the manifest's
tls.peersettingthrough to the L7 listener so an accepted TLS connection actually
becomes mTLS when the matching service has
tls.peer = "warn"or"require".what's in here
tls/backend.zig:Backendgains apeer_mode: TlsConfig.PeerModefield (default
.off).BackendRegistry.registertakes it as aparameter;
lookup/lookupOwnedcarry it through.manifest/orchestrator/startup_runtime.zig: bothregistercallsites now pass
tls.peerfrom the service spec.tls/proxy/session_runtime.zig:handleTlsSessiontakes anoptional
MtlsOptsparameter. when present, it's threaded intoacceptServerHandshakeexactly the same way the mTLS round-triptests already exercise.
tls/proxy.zig: the listener dispatch buildsMtlsOptsfrombackend.peer_modeand the cluster CA loaded viastore.getClusterCa.a missing CA on an mTLS-enabled service logs and downgrades to plain
TLS rather than reject — this is a startup-ordering edge that should
self-heal once the CA bootstrap thread (feat: cluster mtls trust root (raft-distributed ca) #432) seeds the row.
BackendRegistryconfirmpeer_modesurvivesregister/lookup and overwrite.
verification
socketpair tests in
session_runtime.zig(feat: server-side mtls — certificaterequest + client-cert verify #439). this PR is thetype-level wiring that gets
MtlsOptsfrom a service spec to thosecall sites
TlsProxy+ a real DB; the unit coverage on each link in the chain(registry test, manifest loader test from feat: tls.peer manifest field for service-to-service mtls posture #440, session runtime
mTLS test from feat: server-side mtls — certificaterequest + client-cert verify #439) is the practical equivalent
what's next
yoq cert service <name>CLIstill no auto-merge — security-sensitive wiring.