Documentation
Introduction
Configuration
- HTTPProxy Fundamentals
- Ingress v1 Support
- Virtual Hosts
- Inclusion and Delegation
- TLS Termination
- Upstream TLS
- Request Routing
- External Service Routing
- Request Rewriting
- CORS
- Websockets
- Upstream Health Checks
- Client Authorization
- TLS Delegation
- Rate Limiting
- Access logging
- Cookie Rewriting
- Overload Manager
- JWT Verification
- Annotations Reference
- Slow Start Mode
- API Reference
Deployment
- Deployment Options
- Contour Configuration
- Upgrading Contour
- Enabling TLS between Envoy and Contour
- Redeploy Envoy
Guides
- Deploying Contour on AWS with NLB
- AWS Network Load Balancer TLS Termination with Contour
- Deploying HTTPS services with Contour and cert-manager
- External Authorization Support
- FIPS 140-2 in Contour
- Using Gatekeeper with Contour
- Using Gateway API with Contour
- Global Rate Limiting
- Configuring ingress to gRPC services with Contour
- Health Checking
- How to enable structured JSON logging
- Creating a Contour-compatible kind cluster
- Collecting Metrics with Prometheus
- How to Configure PROXY Protocol v1/v2 Support
- Contour/Envoy Resource Limits
Troubleshooting
- Envoy Administration Access
- Contour Debug Logging
- Envoy Debug Logging
- Visualize the Contour Graph
- Show Contour xDS Resources
- Profiling Contour
- Contour Operator
- Envoy Container Stuck in Unready State
Resources
- Support Policy
- Compatibility Matrix
- Contour Deprecation Policy
- Release Process
- Frequently Asked Questions
- Tagging
Security
Contribute
If you deploy Contour as a Deployment or Daemonset, you will likely use a type: LoadBalancer
Service to request an
external load balancer from your hosting provider.
If you use the Elastic Load Balancer (ELB) service from Amazon’s EC2, you need to perform a couple of additional steps to enable the
PROXY protocol. Here’s why:
External load balancers typically operate in one of two modes: a layer 7 HTTP proxy, or a layer 4 TCP proxy. The former cannot be used to load balance TLS traffic, because your cloud provider attempts HTTP negotiation on port 443. So the latter must be used when Contour handles HTTP and HTTPS traffic.
However this leads to a situation where the remote IP address of the client is reported as the inside address of your cloud provider’s load balancer. To rectify the situation, you can add annotations to your service and flags to your Contour Deployment or DaemonSet to enable the PROXY protocol which forwards the original client IP details to Envoy.
Enable PROXY protocol on your service in GKE
In GKE clusters a type: LoadBalancer
Service is provisioned as a Network Load Balancer and will forward traffic to your Envoy instances with their client addresses intact.
Your services should see the addresses in the X-Forwarded-For
or X-Envoy-External-Address
headers without having to enable a PROXY protocol.
Enable PROXY protocol on your service in AWS
To instruct EC2 to place the ELB into tcp
+PROXY
mode, add the following annotations to the contour
Service:
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'
name: contour
namespace: projectcontour
spec:
type: LoadBalancer
...
NOTE: The service annotation service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'
used to toggle the PROXY protocol is found to have no effect on NLBs (Due to this open
issue). Hence, follow the steps mentioned in this AWS
documentation to manually toggle PROXY protocol on NLBs
Enable PROXY protocol support for all Envoy listening ports
...
spec:
containers:
- image: ghcr.io/projectcontour/contour:<version>
imagePullPolicy: Always
name: contour
command: ["contour"]
args: ["serve", "--incluster", "--use-proxy-protocol"]
...