Documentation for version v1.11.0 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.
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.
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:
- "*"
---
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
In this example, the permission for Contour to reference the Secret example-com-wildcard
in the admin
namespace has been delegated to HTTPProxy 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 objects in the cluster.
Read our getting started documentation.