- HTTPProxy Fundamentals
- 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
- Annotations Reference
- Slow Start Mode
- 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
- 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
- Envoy Administration Access
- Contour Debug Logging
- Envoy Debug Logging
- Visualize the Contour Graph
- Show Contour xDS Resources
- Profiling Contour
- Contour Operator
- Support Policy
- Compatibility Matrix
- Contour Deprecation Policy
- Release Process
- Frequently Asked Questions
Similar to Ingress, HTTPProxy support name-based virtual hosting. Name-based virtual hosts use multiple host names with the same IP address.
foo.bar.com --| |-> foo.bar.com s1:80 | 18.104.22.168 | bar.foo.com --| |-> bar.foo.com s2:80
Unlike Ingress however, HTTPProxy only support a single root domain per HTTPProxy object. As an example, this Ingress object:
# ingress-name.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: name-example spec: rules: - host: foo1.bar.com http: paths: - backend: service: name: s1 port: number: 80 pathType: Prefix - host: bar1.bar.com http: paths: - backend: service: name: s2 port: number: 80 pathType: Prefix
must be represented by two different HTTPProxy objects:
# httpproxy-name.yaml apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: name-example-foo namespace: default spec: virtualhost: fqdn: foo1.bar.com routes: - services: - name: s1 port: 80 --- apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: name-example-bar namespace: default spec: virtualhost: fqdn: bar1.bar.com routes: - services: - name: s2 port: 80
A HTTPProxy object that contains a
virtualhost field is known as a “root proxy”.
To present the same set of routes under multiple DNS entries (e.g.
example.com), including a service with a
prefix condition of
/ can be used.
# httpproxy-inclusion-multipleroots.yaml --- apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: multiple-root namespace: default spec: virtualhost: fqdn: bar.com includes: - name: main namespace: default --- apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: multiple-root-www namespace: default spec: virtualhost: fqdn: www.bar.com includes: - name: main namespace: default --- apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: main namespace: default spec: routes: - services: - name: s2 port: 80
Restricted root namespaces
HTTPProxy inclusion allows Administrators to limit which users/namespaces may configure routes for a given domain, but it does not restrict where root HTTPProxies may be created.
Contour has an enforcing mode which accepts a list of namespaces where root HTTPProxy are valid.
Only users permitted to operate in those namespaces can therefore create HTTPProxy with the [
virtualhost] field (
see API docs).
This restricted mode is enabled in Contour by specifying a command line flag,
--root-namespaces, which will restrict Contour to only searching the defined namespaces for root HTTPProxy. This CLI flag accepts a comma separated list of namespaces where HTTPProxy are valid (e.g.
HTTPProxy with a defined
virtualhost field that are not in one of the allowed root namespaces will be flagged as
invalid and will be ignored by Contour.
Additionally, when defined, Contour will only watch for Kubernetes secrets in these namespaces ignoring changes in all other namespaces.
Proper RBAC rules should also be created to restrict what namespaces Contour has access matching the namespaces passed to the command line flag.
An example of this is included in the
examples directory and shows how you might create a namespace called
Note: The restricted root namespace feature is only supported for HTTPProxy CRDs.
--root-namespaces does not affect the operation of Ingress objects.