consul connect: Service Mesh Sidecar Proxy
consul connect is the entry point to Consuls service mesh: it runs the sidecar proxy and inspects or configures the mesh certificate authority.
In a mesh test you use consul connect proxy to front a service with mTLS, and consul connect ca get-config to confirm the CA the mesh trusts.
What it does
consul connect groups the Connect mesh subcommands. consul connect proxy runs a sidecar (or the built-in proxy) that terminates and originates mTLS between mesh services. consul connect ca get-config and set-config read and update the mesh CA configuration that issues those certificates.
Common usage
# run a sidecar proxy for a registered service
consul connect proxy -sidecar-for web
# inspect the mesh CA
consul connect ca get-config
# a raw proxy listener to an upstream
consul connect proxy -service web -upstream db:9191Options
| Subcommand / flag | What it does |
|---|---|
| proxy -sidecar-for <svc> | Run the sidecar proxy for a registered service |
| proxy -upstream <name:port> | Expose an upstream on a local port |
| ca get-config | Print the current mesh CA configuration |
| ca set-config | Update the mesh CA configuration |
| -log-level <level> | Proxy log verbosity for debugging |
In CI
For an integration test, register two services, run consul connect proxy sidecars for each, and assert traffic flows over mTLS. consul connect ca get-config verifies which CA is active before you trust the mesh identities.
Common errors in CI
"Error: -sidecar-for ... no matching services found" means the service is not registered with the local agent. "failed to get certificate: ... Connect not enabled" means Connect is disabled in the agent config (connect { enabled = true }). Connection refused from the proxy usually means the upstream is not registered or has no healthy instances.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes