29 lines
1.5 KiB
Plaintext
29 lines
1.5 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Service Mesh Proxy Overview
|
|
description: >-
|
|
In Consul service mesh, each service has a sidecar proxy that secures connections with other services in the mesh without modifying the underlying application code. You can use the built-in proxy, Envoy, or a custom proxy to handle communication and verify TLS connections.
|
|
---
|
|
|
|
# Service Mesh Proxy Overview
|
|
|
|
Proxies enable unmodified applications to connect to other services in the service mesh. A
|
|
per-service proxy sidecar transparently handles inbound and outbound service
|
|
connections, automatically wrapping and verifying TLS connections. Consul
|
|
ships with a built-in L4 proxy and has first class support for Envoy. You
|
|
can plug other proxies into your environment as well. This section describes how to
|
|
configure Envoy or the built-in proxy using Connect, and how to integrate the
|
|
proxy of your choice.
|
|
|
|
To ensure that services only allow external connections established through
|
|
the service mesh protocol, you should configure all services to only accept connections on a loopback address.
|
|
|
|
## Dynamic upstreams require native integration
|
|
|
|
Service mesh proxies do not support dynamic upstreams.
|
|
|
|
If an application requires dynamic dependencies that are only available
|
|
at runtime, you must [natively integrate](/consul/docs/connect/native)
|
|
the application with Consul service mesh. After natively integrating, the HTTP API or
|
|
[DNS interface](/consul/docs/services/discovery/dns-static-lookups#service-mesh-enabled-service-lookups)
|
|
can be used. |