fix(injector): Mount spire-agent-socket into authbridge containers

[huang195]

Summary

The webhook creates the spire-agent-socket POD-level volume (CSI driver csi.spiffe.io) when spire-enabled is true, but never mounts it into either authbridge container. The bundled spiffe-helper inside the combined authbridge images dials unix:///spiffe-workload-api/spire-agent.sock (per internal/webhook/config/defaults.go:73's SocketPath) and sits in a silent dial-loop forever because the directory doesn't exist in the container.

This PR completes the bundled-spiffe-helper migration alluded to in injection_decision.go:22's TODO — when the standalone spiffe-helper sidecar was removed and the helper moved into the combined authbridge images, the volume mount got lost.

Why this was hidden

No in-production workload actually consumes SPIRE-issued material today:

• token-exchange uses /shared/client-secret.txt (Keycloak client_credentials from a Secret the operator provisions), not JWT-SVIDs.
• jwt-validation uses JWKS over HTTP, not SPIRE.
• /opt/svid*.pem and /opt/jwt_svid.token sit empty in every spire-enabled pod. Verified: weather-agent has been running 3+ days with kagenti.io/spire: enabled and /opt/ empty the whole time.

kagenti-extensions PR #424 (mTLS between authbridge sidecars via SPIRE X.509 SVIDs) is the first workload that actually consumes SPIRE material. Without this fix, the mTLS feature can't function — tls.ServerConfig errors at construction when /opt/svid.pem is missing.

Change

Two locations in internal/webhook/injector/container_builder.go:

1. BuildEnvoyProxyContainerWithSpireOption (envoy-sidecar mode)
2. BuildProxySidecarContainerWithPorts (proxy-sidecar / lite modes)

Both append spire-agent-socket → /spiffe-workload-api (ReadOnly) inside the existing if spireEnabled block.

The mount path /spiffe-workload-api matches the SocketPath in defaults.go. ReadOnly is correct — the CSI volume itself is already declared read-only at the Pod level (volume_builder.go:170).

Test plan

• go test -race -count=1 ./internal/webhook/injector/... — all pass, including new tests:
  • TestBuildEnvoyProxyContainer_SpireEnabled_HasSocketMount — locks mount presence + path + ReadOnly when SPIRE is on
  • TestBuildEnvoyProxyContainer_SpireDisabled_NoSocketMount — asserts absent when SPIRE is off
  • TestBuildProxySidecarContainer_SpireEnabled_HasSocketMount — same shape for proxy-sidecar
  • TestBuildProxySidecarContainer_SpireDisabled_NoSocketMount — proxy-sidecar negative case
• go vet ./..., gofmt -l clean
• Built operator image, kind-loaded, restarted controller-manager. Mtls demo pods now render with the new mount in their spec; kubelet correctly attempts to mount (proves the operator change is live).
• CI passes
• Full e2e mTLS demo verification deferred to PR Fix: harden controllers against stale objects, orphaned resources, an… #424's reviewer once the SPIRE agent + CSI driver are restored on the test cluster — they were absent during local verification, blocking the mount-success path but not the operator's correctness.

Files

• internal/webhook/injector/container_builder.go — 2 mount additions, ~24 LOC including comments
• internal/webhook/injector/container_builder_test.go — 4 new test functions, ~80 LOC

Net: +106 / 0.

Out of scope

• MTLSMode resolution chain (AgentRuntime CR spec + namespace ConfigMap + per-agent ConfigMap merge). Deferred to a follow-up operator PR. Keeps the demo's namespace-ConfigMap patch as the interim until that lands.
• Renaming the deprecated kagenti.io/spiffe-helper-inject label to kagenti.io/spire-enabled (TODO at injection_decision.go:22). Separate breaking-label PR.

Release coordination

This fix should be released alongside kagenti-extensions PR #424 (or before it). Without this operator fix landing first, the authbridge mTLS feature can't function in any deployment.

Assisted-By: Claude (Anthropic AI) noreply@anthropic.com

[pdettori]

Clean, well-scoped fix that adds the missing spire-agent-socket volume mount to both authbridge container variants when SPIRE is enabled. The spireSocketDir helper correctly derives the mount path from the canonical SpiffeConfig.SocketPath in defaults.go, eliminating drift risk. Tests are symmetric and properly derive expected values from the same source of truth.

Areas reviewed: Go (production + test), commit conventions, security
Commits: 2 commits, both signed-off ✓
CI: all 15 checks passing (Unit, Integration, E2E, Lint, CodeQL, Trivy)

[pdettori]

nit: The comment says path.Dir would "import path" as if that's costly — but path is stdlib (no binary bloat, no vendor impact). Not wrong to use strings, but the justification overstates the cost. Consider either using path.Dir for clarity or dropping the comment since the code is self-explanatory.

[huang195]

Fair point — switched to path.Dir and dropped the misleading "stdlib import would be costly" comment. a644731.

[pdettori]

nit: The 11-line comment block is thorough but could be trimmed to ~3 lines — the PR description and commit message already document the full rationale (why it was hidden, what consumes it). Long inline comments inside functions tend to go stale. The key info for a reader is: "Mount the CSI socket volume so the bundled spiffe-helper can reach the workload API. Path derived from SpiffeConfig.SocketPath."

[huang195]

Trimmed both mount sites to two lines stating what the mount is for. Same trim applied to the proxy-sidecar variant for symmetry. a644731.