Closed davecheney closed 1 month ago
I like this idea!
We’ve built a custom controller that watches IngressRoute objects and automatically requests a matching certificate from our PKI CertSrv server (it’s a Windows server thing).
We’ve first considered integrating with cert-manager by adding PKI CertSrv support to it and creating Certificate objects as proposed here. We punted on this design due to the number of moving pieces, but if Contour can do its part, it would feasible to switch.
On a related note, we do the same to manage DNS records for IngressRoute objects via that same controller.
Perhaps Contour could also have the option to emit DNSRecord objects for integration with external-dns.
Moving to the unplanned milestone to review after Contour 1.0
xref #2187
Given the wide variety of ways to configure and issue TLS certificates, integrating this into Contour is a fraught endeavor. Maybe a collaborating operator, but simply adding the support into cert-manager seems a lot more tractable to me.
@jpeach We develop a sidecar controller to create Certificate along with HTTPProxy. If interested, see https://github.com/cybozu-go/contour-plus
Hi all, I'm working on a hosting service with Contour. Users will bring their own domain names (in the 100s and perhaps 1000s), so it's important that I can automatically provision SSL certificates. Is the current best way to roll my own solution? Thanks. :slightly_smiling_face:
In my experience creating Certificate objects for the domain names directly is a good way forward as you don't necessarily want a separate TLS certificate for every domain name, but instead a single TLS certificate with multiple subjectAltName entries. For example if you have a website that needs to be available at mysite.domain.com and mysite.domain.net you'd have two HTTPProxy objects but a single Certificate object with dnsNames for mysite.domain.com and mysite.domain.net.
However, if you do have a one-to-one mapping between HTTPProxy and Certificate then @ymmt2005's contour-plus works well.
In my experience creating Certificate objects for the domain names directly is a good way forward as you don't necessarily want a separate TLS certificate for every domain name, but instead a single TLS certificate with multiple subjectAltName entries. For example if you have a website that needs to be available at mysite.domain.com and mysite.domain.net you'd have two HTTPProxy objects but a single Certificate object with dnsNames for mysite.domain.com and mysite.domain.net.
I would ty to avoid this in order to avoid HTTP/2 session re-use problems. This optimizes for the cost of certificates, but with lets encrypt, that cost can be driven to zero. There's no single policy that is right for everyone though :)
However, if you do have a one-to-one mapping between HTTPProxy and Certificate then @ymmt2005's contour-plus works well.
Maybe we can point people to this project in Contour documentation, or even integrate it deeper into the project (e.g. contour-operator could automatically install it)? @ymmt2005 what do you think?
@jpeach contour-plus depends on Contour, external-dns, and cert-manager.
Since all of these projects are moving fast and changing CRD schema, I'd suggest having contour-plus as a separate project. Adding links to contour-plus seems a good step.
I figured out I can create a Certificate resource myself as part of the deploy process. This seems better than creating an Ingress object. However, we still have the problem of the http-01 challenge. I'm thinking of proxying /.well-known/acme-challenge
in the HTTPProxy to a solver pod. This is as far as I've gotten.
In case anyone else runs into this issue in the future: I just had to install ingress-nginx to get things working after deploying a Certificate object. The advice in #2018 is pretty good. My code is here: https://gitlab.com/tribes-host/tribes/-/commit/f812443e6ba4c2ab17aec343f7be3a5564ed12fd
Hmm, that's weird, if you configure cert-manager to create Ingress objects that have an annotation matching the right ingress-class, Contour should pick them up and serve them for you. You shouldn't need ingress-nginx to do that.
The Contour project currently lacks enough contributors to adequately respond to all Issues.
This bot triages Issues according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack
The Contour project currently lacks enough contributors to adequately respond to all Issues.
This bot triages Issues according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack
Currently cert-manager integration with Contour requires either manually creating a Certificate object (a CRD describing a Let's Encrypt managed certificate) or using [annotations][1] on an Ingress resource which triggers cert-manager's ingress-shim helper.
Rather than ingress-shim learning about HTTPProxy and staying in sync as we evolve the type, Contour should learn how to emit a Certificate object -- effectively contour will grow its own version of ingress shim for our HTTPProxy objects.
1: https://github.com/jetstack/cert-manager/blob/master/docs/tasks/issuing-certificates/ingress-shim.rst