Our latest release of Contour is 1.4, which includes support for Client Certificate authentication in your HTTPProxy objects, and also updates Contour’s Ingress support to fix some missing or incorrect behaviors. In addition Contour 1.4 upgrades Envoy to 1.14.1, to keep up with Envoy’s current supported version.
This release adds support for client authentication through the use of certificates.
So what does this mean? Well, you can now configure your HTTPProxy routes so that they require a client certificate supplied by your client (usually your browser), which allows you to use that client certificate for authentication.
To use this feature, add the new
clientValidation field to the
tls stanza of your HTTPProxy document:
apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: with-client-auth spec: virtualhost: fqdn: www.example.com tls: secretName: secret clientValidation: caSecret: client-root-ca routes: - services: - name: s1 port: 80
caSecret field is a reference to a Kubernetes Secret that holds the CA certificate used to validate the client certificate. The Secret must contain a
ca.crt key that holds a PEM-encoded bundle of the full trust chain for any CA used to validate certificates.
It’s important to note that this only provides authentication, not authorization. To put this another way, Contour and Envoy can only give you a guarantee that the supplied person is the bearer of a valid certificate, not they are allowed to do something.
Thanks very much to @tsaarni for getting this implemented!
Before this release of Contour, when configured to accept a certain
ingress.class annotation, Contour would watch objects with that annotation and also with no annotation. This caused problems in clusters with more than one ingress controller.
Starting with Contour 1.4, having an
ingress.class annotation configured means that only objects that have a matching annotation will cause changes in Contour.
Note that this logic change applies to both Ingress and HTTPProxy objects.
If you don’t give Contour an
ingress.class on its command line, then Contour will look at all objects with no
ingress.class, and objects with an
contour. This preserves the old behavior so that we don’t break you if that’s what you expect.
Contour now has the ability to write a
status.loadBalancer.addresses block to Ingress objects. This block is used by services which need to know how to reach an Ingress’ backing service from outside the cluster, like external-dns.
There are two ways for Contour to find this information:
status.loadBalancerblock from that Service into all associated Ingress objects. This is what is used in the example deployment.
--ingress-status-addressflag. The address that’s passed on the command line will be passed straight through to the Ingress status.
This also means that when you
kubectl get a Contour-owned Ingress, instead of this:
$ kubectl get ingress httpbin NAME HOSTS ADDRESS PORTS AGE httpbin httpbin.youngnick.dev 80, 443 336d
you will see this:
$ kubectl get ingress httpbin NAME HOSTS ADDRESS PORTS AGE httpbin httpbin.youngnick.dev x.x.x.x 80, 443 336d
--use-extensions-v1beta1-ingress flag was removed from the contour serve command in Contour 1.3. If you have a previous deployment that specifies this command, you must remove it or Contour will fail to start.
The Contour project is very community-driven and the team would love to hear your feedback!
If you are interested in contributing, a great place to start is to comment on one of the issues labeled with Help Wanted and work with the team on how to resolve them.
If you’re using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread
We’re immensely grateful for all the community contributions that help make Contour even better! Special thanks go out to: