Transparent proxy overview
This topic provides overview information about transparent proxy mode, which allows applications to communicate through the service mesh without modifying their configurations. Transparent proxy also hardens application security by preventing direct inbound connections that bypass the mesh.
When service mesh proxies are in transparent mode, Consul service mesh uses IPtables to direct all inbound and outbound traffic to the sidecar. Consul also uses information configured in service intentions to infer routes, which eliminates the need to explicitly configure upstreams.
The following diagram shows how Consul routes traffic when proxies are in transparent mode:
When transparent proxy mode is disabled, you must manually configure explicit upstreams, configure your applications to query for services at
localhost:<port>, and configure applications to only listen on the loopback interface to prevent services from bypassing the mesh.
The following diagram shows how Consul routes traffic when transparent proxy mode is disabled:
Transparent proxy is available for Kubernetes environments. As part of the integration with Kubernetes, Consul registers Kubernetes Services, injects sidecar proxies, and enables traffic redirection.
Transparent proxy mode enables several networking architectures and workflows. You can query Consul DNS to discover upstreams for single services, virtual services, and failover service instances that are in peered clusters.
Consul supports the following intra-datacenter connection types for discovering upstreams when transparent proxy mode is enabled:
- KubeDNS lookups across WAN-federated datacenters
- Consul DNS lookups across WAN-federated datacenters
- KubeDNS lookups in peered clusters and admin partitions
- Consul DNS lookups in peered clusters and admin partitions
Transparent proxy mode is enabled by default when you install Consul on Kubernetes using the Consul Helm chart. As a result, all services in the mesh must communicate through sidecar proxies, which enforce service intentions and mTLS encryption for the service mesh. While onboarding new services to service mesh, your network may have mixed mTLS and non-mTLS traffic, which can result in broken service-to-service communication.
You can temporarily enable permissive mTLS mode during the onboarding process so that existing mesh services can accept traffic from services that are not yet fully onboarded. Permissive mTLS enables sidecar proxies to access both mTLS and non-mTLS traffic. Refer to Onboard mesh services in transparent proxy mode for additional information.