Entrypoint should be mode-aware for proxy-sidecar and waypoint modes

[huang195]

Problem

cmd/authbridge/entrypoint.sh unconditionally starts both Envoy and the authbridge binary:

/usr/local/bin/authbridge "$@" &
/usr/local/bin/envoy -c /etc/envoy/envoy.yaml ... &
wait -n

This is correct for envoy-sidecar mode but wrong for the other two modes:

• proxy-sidecar: should start only authbridge (runs its own reverse proxy + forward proxy listeners). Starting Envoy is wasteful and may conflict.
• waypoint: should start only authbridge (runs ext_authz + forward proxy). Envoy is not needed — Istio ambient mesh handles traffic routing.

Options

Option A: Mode-aware entrypoint

The entrypoint reads the mode from the config file and conditionally starts Envoy:

MODE=$(grep "^mode:" /etc/authbridge/config.yaml | awk '{print $2}')
if [ "$MODE" = "envoy-sidecar" ]; then
  /usr/local/bin/envoy ... &
fi
/usr/local/bin/authbridge "$@" &
wait -n

Option B: Operator overrides the command

The Dockerfile keeps the current entrypoint (always starts Envoy). The operator overrides it per mode:

• envoy-sidecar: use entrypoint as-is
• proxy-sidecar: command: ["/usr/local/bin/authbridge"], args: ["--config", "..."]
• waypoint: same override (standalone deployment, not operator-injected)

Recommendation

Option B is simpler — the entrypoint stays dumb, and mode routing is the operator's responsibility. The image contains both binaries regardless.

Context

• The unified authbridge binary (cmd/authbridge) supports 3 modes: envoy-sidecar, waypoint, proxy-sidecar
• The operator currently only injects envoy-sidecar mode
• proxy-sidecar operator support would also need to inject HTTP_PROXY env var into the agent container
• waypoint operator support would create a waypoint Deployment + Service per namespace instead of injecting sidecars

Ref: #279