Tracking items surfaced during the Coral cross-review of PR (TBD — sidecar trusted-header authn).
1. Plumb X-Remote-User through ctx for audit logging
The trustedHeaderMiddleware currently checks presence/uniqueness of X-Remote-User but drops the value on the floor. For audit ("who voted yes on prop 42?") this is the only identity signal available.
Action: add `WithRemoteUser(ctx, value)` and `RemoteUserFromContext(ctx) string` helpers in `sidecar/server`. Have the middleware stamp the value into ctx. Sign-tx handlers (gov_vote.go, gov_software_upgrade.go) include the value in their structured log lines alongside taskId.
Also plumb into TaskResult if/when the engine grows a structured output field (deferred per #174).
2. Startup WARN on unauthenticated mode
When `SEI_SIDECAR_AUTHN_MODE` is unset (backward-compat default), the sidecar accepts unauthenticated requests on all interfaces. Operators upgrading to a binary with #165 support but forgetting to set the env var stay open silently.
Action: at startup in serve.go, log a one-line WARN when AuthnMode==unauthenticated: "sidecar accepting unauthenticated requests on all interfaces — set SEI_SIDECAR_AUTHN_MODE=trusted-header for production." Cheap; provides telemetry on who hasn't migrated.
3. Refuse-to-start on hostNetwork: true
Loopback bind in trusted-header mode collapses if the pod uses `hostNetwork: true` — 127.0.0.1 is shared with the host and every other hostNetwork pod on the node. Currently documented in auth.go but not enforced.
Action: at startup, heuristically detect hostNetwork (compare pod IP from `/etc/hostname` resolution to node IP from downwardAPI). If trusted-header mode AND hostNetwork detected, refuse to start with a clear error. Realistic ask: the controller-side PR in sei-k8s-controller is the load-bearing place to forbid hostNetwork on these pods; this sidecar-side check is belt-and-suspenders.
4. mTLS or shared-secret between proxy and sidecar
Today an attacker who lands code execution in any container in the pod (e.g., the seid container) can `curl 127.0.0.1:7777` directly bypassing the proxy and forge X-Remote-User. The trust boundary is the pod, not the loopback interface.
Action: when/if we move to multi-tenant per-namespace sidecar deployments, consider client certs from proxy to sidecar (proxy presents a cert that the sidecar verifies; sidecar refuses connections without it). Out of scope for current single-tenant validator pods.
References
Tracking items surfaced during the Coral cross-review of PR (TBD — sidecar trusted-header authn).
1. Plumb X-Remote-User through ctx for audit logging
The trustedHeaderMiddleware currently checks presence/uniqueness of X-Remote-User but drops the value on the floor. For audit ("who voted yes on prop 42?") this is the only identity signal available.
Action: add `WithRemoteUser(ctx, value)` and `RemoteUserFromContext(ctx) string` helpers in `sidecar/server`. Have the middleware stamp the value into ctx. Sign-tx handlers (gov_vote.go, gov_software_upgrade.go) include the value in their structured log lines alongside taskId.
Also plumb into TaskResult if/when the engine grows a structured output field (deferred per #174).
2. Startup WARN on unauthenticated mode
When `SEI_SIDECAR_AUTHN_MODE` is unset (backward-compat default), the sidecar accepts unauthenticated requests on all interfaces. Operators upgrading to a binary with #165 support but forgetting to set the env var stay open silently.
Action: at startup in serve.go, log a one-line WARN when AuthnMode==unauthenticated: "sidecar accepting unauthenticated requests on all interfaces — set SEI_SIDECAR_AUTHN_MODE=trusted-header for production." Cheap; provides telemetry on who hasn't migrated.
3. Refuse-to-start on hostNetwork: true
Loopback bind in trusted-header mode collapses if the pod uses `hostNetwork: true` — 127.0.0.1 is shared with the host and every other hostNetwork pod on the node. Currently documented in auth.go but not enforced.
Action: at startup, heuristically detect hostNetwork (compare pod IP from `/etc/hostname` resolution to node IP from downwardAPI). If trusted-header mode AND hostNetwork detected, refuse to start with a clear error. Realistic ask: the controller-side PR in sei-k8s-controller is the load-bearing place to forbid hostNetwork on these pods; this sidecar-side check is belt-and-suspenders.
4. mTLS or shared-secret between proxy and sidecar
Today an attacker who lands code execution in any container in the pod (e.g., the seid container) can `curl 127.0.0.1:7777` directly bypassing the proxy and forge X-Remote-User. The trust boundary is the pod, not the loopback interface.
Action: when/if we move to multi-tenant per-namespace sidecar deployments, consider client certs from proxy to sidecar (proxy presents a cert that the sidecar verifies; sidecar refuses connections without it). Out of scope for current single-tenant validator pods.
References