94332edf2e
* Initial draft of Sidecar Service and Managed Proxy deprecation docs * Service definition deprecation notices and sidecar service * gRPC and sidecar service config options; Deprecate managed proxy options * Envoy Docs: Basic envoy command; envoy getting started/intro * Remove change that snuck in * Envoy custom config example * Add agent/service API docs; deprecate proxy config endpoint * Misc grep cleanup for managed proxies; capitalize Envoy * Updates to getting started guide * Add missing link * Refactor Envoy guide into a separate guide and add bootstrap reference notes. * Add limitations to Envoy docs; Highlight no fixes for known managed proxy issues on deprecation page; clarify snake cae stuff; Sidecar Service lifecycle
2.5 KiB
| layout | page_title | sidebar_current | description |
|---|---|---|---|
| docs | Connect - Proxy Integration | docs-connect-proxies-integrate | A Connect-aware proxy enables unmodified applications to use Connect. A per-service proxy sidecar transparently handles inbound and outbound service connections, automatically wrapping and verifying TLS connections. |
Connect Custom Proxy Integration
Any proxy can be extended to support Connect. Consul ships with a built-in proxy for a good development and out of the box experience, but understand that production users will require other proxy solutions.
A proxy must serve one or both of the following two roles: it must accept inbound connections or establish outbound connections identified as a particular service. One or both of these may be implemented depending on the case, although generally both must be supported.
Accepting Inbound Connections
For inbound connections, the proxy must accept TLS connections on some port.
The certificate served should be created by the
/v1/agent/connect/ca/leaf/ API endpoint.
The client certificate should be validated against the root certificates
provided by the
/v1/agent/connect/ca/roots endpoint.
After validating the client certificate from the caller, the proxy should
call the
/v1/agent/connect/authorize endpoint to
authorize the connection.
All of these API endpoints operate on agent-local data that is updated in the background. The leaf and roots should be updated in the background by the proxy, but the authorize endpoint is expected to be called in the connection path. The endpoints introduce only microseconds of additional latency on the connection.
The leaf and root cert endpoints support blocking queries. These should be used if possible to get near-immediate updates for root cert rotations, leaf expiry, etc.
Establishing Outbound Connections
For outbound connections, the proxy should communicate to a
Connect-capable endpoint for a service and provide a client certificate
from the
/v1/agent/connect/ca/leaf/ API endpoint.
The certificate served by the remote endpoint can be verified against the
root certificates from the
/v1/agent/connect/ca/roots endpoint.
Configuration Discovery
Any proxy can discover proxy configuration registered with a local service instance using the agent/service/:service_id endpoint.