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
TLS Certificate Delegation
In order to support wildcard certificates, TLS certificates for a *.somedomain.com
, which are stored in a namespace controlled by the cluster administrator, Contour supports a facility known as TLS Certificate Delegation.
This facility allows the owner of a TLS certificate to delegate, for the purposes of referencing the TLS certificate, permission to Contour to read the Secret object from another namespace.
Delegation works for both HTTPProxy and Ingress resources, however it needs an annotation to work with Ingress v1.
The
TLSCertificateDelegation
resource defines a set of delegations
in the spec
.
Each delegation references a secretName
from the namespace where the TLSCertificateDelegation
is created as well as describing a set of targetNamespaces
in which the certificate can be referenced.
If all namespaces should be able to reference the secret, then set "*"
as the value of targetNamespaces
(see example below).
apiVersion: projectcontour.io/v1
kind: TLSCertificateDelegation
metadata:
name: example-com-wildcard
namespace: www-admin
spec:
delegations:
- secretName: example-com-wildcard
targetNamespaces:
- example-com
- secretName: another-com-wildcard
targetNamespaces:
- "*"
In this example, the permission for Contour to reference the Secret example-com-wildcard
in the admin
namespace has been delegated to HTTPProxy and Ingress objects in the example-com
namespace.
Also, the permission for Contour to reference the Secret another-com-wildcard
from all namespaces has been delegated to all HTTPProxy and Ingress objects in the cluster.
To reference the secret from an HTTPProxy or Ingress v1beta1 you must use the slash syntax in the secretName
:
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: www
namespace: example-com
spec:
virtualhost:
fqdn: foo2.bar.com
tls:
secretName: www-admin/example-com-wildcard
routes:
- services:
- name: s1
port: 80
To reference the secret from an Ingress v1 you must use the projectcontour.io/tls-cert-namespace
annotation:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
projectcontour.io/tls-cert-namespace: www-admin
name: www
namespace: example-com
spec:
rules:
- host: foo2.bar.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: s1
port:
number: 80
tls:
- hosts:
- foo2.bar.com
secretName: example-com-wildcard