feat(proxyfault): pass an interception CA so HTTP faults reach HTTPS dependencies

[achoimet]

Bridge half of HTTPS response injection. Depends on steadybit/transparent-proxy#4.

What

Opts.TLSInterceptCA{CertPEM, KeyPEM} hands the proxy a certificate authority so an HTTPStatus fault can apply to an HTTPS dependency instead of only a cleartext one. Nil keeps today's behaviour: TLS is never decrypted and HTTPS is spliced through untouched.

Snapshot also gains tls_intercept_rejected — connections whose client refused the minted certificate. That is the canonical "the CA is not in the target's truststore (or the client pins certificates)" signal, deliberately not counted as faulted, so a failed interception is diagnosable rather than looking like a silent no-op.

Why stdin, not a file path

I first passed --tls-ca-cert/--tls-ca-key, assuming the sidecar could read a path in the extension's filesystem. That is wrong for the runc backend, and I verified it rather than shipping it:

The bundle rootfs is created as an overlay with lowerdir=/ — the extension's root. An overlay does not carry the lower filesystem's submounts. A Kubernetes Secret is a separate mount, so inside the sidecar it appears as an empty directory. Reproduced with the exact mount options the real bundle uses:

Inside the sidecar overlay	Result
Image-layer file (how /transparent-proxy resolves)	visible
Mounted Secret at /etc/steadybit/tls-ca/	empty dir — CA unreadable

Left as-is this would have failed only at runtime, and failed misleadingly: every handshake aborting, reported as "the client rejected our certificate", sending the operator after their truststore instead of a proxy that never had a usable CA. It would also have worked for extension-host (ip netns exec shares the extension's mount namespace) and silently failed for extension-container — the worst kind of asymmetry.

So the PEM now goes over the process's stdin, with only --tls-ca-stdin on the command line. That works identically for both backends, keeps the key out of argv (visible in /proc), and never writes it to a disk the target could reach.

Notes

• startAndMonitor takes the stdin payload so both backends share one path; it is written and the pipe closed in the background, as the proxy reads stdin to EOF at startup.
• The flag is start-only: --revert reconstructs interception rules, which do not depend on the CA. Asserted against.
• The CA is the customer's: they generate it, choose its validity, install it in their truststores. Nothing here manages its lifecycle.

Tests

12 pass under -race. Covers: flags absent when unset, --tls-ca-stdin present and the PEM absent from argv when set, both halves present in the stdin payload, absent from revert args, the rejected counter surviving the stdout round-trip without inflating faulted, and startAndMonitor actually writing stdin and closing it.

Verified end to end under real iptables in minikube: CA loaded from stdin, trusted client gets the forged 503 over HTTP/2, untrusted client counted as rejected (not faulted), untargeted traffic passes through, and teardown leaves no rules.

🤖 Generated with Claude Code

https://claude.ai/code/session_019wB5XrsrNJjU9MH6yegmTA

[claude]

Claude finished @achoimet's task in 2m 20s —— View job

---

Claude's Review

• Check for previously unresolved review threads authored by Claude (none exist on this PR)
• Gather context: read diff origin/main...HEAD and changed files
• Review code quality, bugs, security, performance, race conditions
• Post findings

Note: I wasn't able to run go build/go test/go vet in this sandbox (the tool-approval step declined those commands), so this review is based on manual reading only. The PR description states 12 tests pass under -race, which I have no reason to doubt from reading the code.

Summary

This is a well-reasoned, carefully-scoped change. The stdin-handover design and the rationale in the PR description (overlay rootfs not carrying submounts) both check out against the code. I traced the pipe lifecycle in startAndMonitor (proxyfault.go:407-456) closely since that's the highest-risk part of this diff (process control + secret material):

• cmd.StdinPipe() is called before cmd.Start(), as required.
• If cmd.StdoutPipe() fails, the already-opened stdin pipe is explicitly closed (proxyfault.go:424-426) — correct, since cmd.Start() was never reached and Go's os/exec only auto-closes pipe descriptors from within Start() itself.
• If cmd.Start() fails, no explicit cleanup is needed: exec.Cmd.Start() internally closes both closeAfterStart and closeAfterWait descriptors (which includes the caller's stdin pipe handle) on failure, so nothing leaks there.
• The write-then-close goroutine only starts after a successful Start(), so it can't race with the failure paths above.
• startArgs() never includes the PEM (confirmed by TestStartArgs_tlsInterceptCA), and the CA flag/leaf-validity flag are gated on the same "both halves present" check, avoiding the half-configured state that would otherwise produce a confusing proxy-side failure.
• revertArgs() correctly excludes all TLS options, matching the stated invariant that revert doesn't depend on the CA.

No bugs, race conditions, or security issues found in the reviewed diff. One minor, non-blocking observation: the CA's raw key bytes (stdin in startAndMonitor, and TLSInterceptCA.KeyPEM) aren't zeroed after being written to the pipe, so they can linger in memory until GC. Given the deliberate effort elsewhere in this PR to keep the key out of argv/disk, that's a reasonable defense-in-depth follow-up, but not something I'd block on.

The .gitignore, test, and lifecycle changes are straightforward and consistent with the implementation.
(branch: feat/proxyfault-tls-intercept-ca)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud