- HTTPProxy Fundamentals
- Gateway API Support
- Ingress v1 Support
- Virtual Hosts
- Inclusion and Delegation
- TLS Termination
- Upstream TLS
- Request Routing
- External Service Routing
- Request Rewriting
- Upstream Health Checks
- Client Authorization
- TLS Delegation
- Rate Limiting
- Access logging
- Cookie Rewriting
- Overload Manager
- JWT Verification
- IP Filtering
- Annotations Reference
- Slow Start Mode
- Tracing Support
- API Reference
- Deployment Options
- Contour Configuration
- Upgrading Contour
- Enabling TLS between Envoy and Contour
- Redeploy Envoy
- 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
- Creating a Contour-compatible kind cluster
- Collecting Metrics with Prometheus
- How to Configure PROXY Protocol v1/v2 Support
- Contour/Envoy Resource Limits
- Envoy Administration Access
- Contour Debug Logging
- Envoy Debug Logging
- Visualize the Contour Graph
- Show Contour xDS Resources
- Profiling Contour
- Envoy Container Stuck in Unready State
- Support Policy
- Compatibility Matrix
- Contour Deprecation Policy
- Release Process
- Frequently Asked Questions
External Service Routing
HTTPProxy supports routing traffic to
ExternalName service types, but this is disabled by default, as it can lead
to inadvertent exposure of the Envoy Admin UI, allowing remote shutdown and restart of Envoy.
this security advisory for all the details.
It can also be used to expose services in namespaces a user does not have access to, using an ExternalName of
this Kubernetes security advisory for more details.
We do not recommend enabling ExternalName Services without a strong use case, and understanding of the security implications.
However, To enable ExternalName processing, you must set the
enableExternalNameService configuration file setting to
This will allow the following configuration to be valid.
Contour looks at the
spec.externalName field of the service and configures the route to use that DNS name instead of utilizing EDS.
Note that hostnames of
localhost or some other synonyms will be rejected (because of the aforementioned security issues).
There’s nothing specific in the HTTPProxy object that needs to be configured other than referencing a service of type
HTTPProxy supports the
requestHeadersPolicy field to rewrite the
Host header after first handling a request and before proxying to an upstream service.
This field can be used to ensure that the forwarded HTTP request contains the hostname that the external resource is expecting.
Note: The ports are required to be specified.
# httpproxy-externalname.yaml apiVersion: v1 kind: Service metadata: labels: run: externaldns name: externaldns namespace: default spec: externalName: foo-basic.bar.com ports: - name: http port: 80 protocol: TCP targetPort: 80 type: ExternalName
To proxy to another resource outside the cluster (e.g. A hosted object store bucket for example), configure that external resource in a service type
Then define a
requestHeadersPolicy which replaces the
Host header with the value of the external name service defined previously.
Finally, if the upstream service is served over TLS, set the
protocol field on the service to
tls or annotate the external name service with:
projectcontour.io/upstream-protocol.tls: 443,https, assuming your service had a port 443 and name