Envoy: ACME support

[vixns]

Automated letsencrypt certificates creation / renewal would be great.

[ldemailly]

it would be great to get envoy listed on https://certbot.eff.org/

[thekalinga]

I have created an issue as part of cert-manager.

Since cert-manager has integration for nginx & haproxy, anyone with back sufficient background (I dont have) should be able to add support for envoy aswell

https://github.com/jetstack/cert-manager/issues/238

[thekalinga]

As per the this comment by the author of cert-manager, acme integration with any ingress controller(incl envoy) should work out of the box.

Unfortunately, I currently don't have any external facing hosting I can point to test acme integration right now. Can anyone test this & confirm?

[ldemailly]

I'll give it a try

[ldemailly]

got it to work in a maybe not simple enough way (but it's a start)

https://github.com/istio/istio/issues/2310#issuecomment-357122715

even if this solves the kubernetes/istio case, it would be nice to have envoy out of the box on https://certbot.eff.org/

[kkimdev]

Traefik for example makes the acme integration very seamless. This is all user has to do:

https://docs.traefik.io/user-guide/docker-and-lets-encrypt/

[acme]
email = "[email protected]"
storage = "acme.json"
entryPoint = "https"
onHostRule = true
[acme.httpChallenge]
entryPoint = "http"

I think it greatly improves user experience, and it will be awesome to have a similar support in Istio.

[lizan]

Now we have secret discovery service ready, it should be straight forward to implement an envoy plugin in certbot.

[blaggacao]

Is there any hard design argument for NOT dis-intermediating cert-manager?

[bbigras]

Any progress on this?

[saksmt]

3 years, guys, seriously...

[cetanu]

If anyone can point me to an example where they've actually used certbot in conjunction with Envoy, I can probably try to write up a basic document explaining how this could be implemented... and then leave the cpp experts to do the impl.

Personally I'm interested in doing this on my control plane, and having it just hand the certs to envoy, but I just don't grok ACME+Envoy enough yet.
Presumably if DNS for a domain is already pointed at my proxies, then I can configure a listener on port 80 to send a direct response for the verification bit... that should yield a cert which I can then send through SDS or add to the transport socket of a HTTPS listener. That's the theory, right?

[mattklein123]

If anyone can point me to an example where they've actually used certbot in conjunction with Envoy, I can probably try to write up a basic document explaining how this could be implemented... and then leave the cpp experts to do the impl.

I think most (all?) Envoy ingress controllers implement this, so I would look at Amabassador/Contour/Gloo/etc.

That's the theory, right?

The TLS cert providers are actually pluggable at this point, so I think we can theoretically build an ACME cert provider and have it all be built-in. I would love to see this happen, but the reason it hasn't happened yet is that everyone just does it with a sidecar and it's not a burning need.

[micheas]

Ambassador relies on certmanager to deal with the certificate management
and takes a reload cue from certmanager.

Probably the path you want to take here.

It insulates envoy from a potentially hostile input from the certificate
renewal process.

On Sun, Oct 11, 2020, 10:14 AM Matt Klein [e-mail] wrote:

If anyone can point me to an example where they've actually used certbot
in conjunction with Envoy, I can probably try to write up a basic document
explaining how this could be implemented... and then leave the cpp experts
to do the impl.

I think most (all?) Envoy ingress controllers implement this, so I would
look at Amabassador/Contour/Gloo/etc.

That's the theory, right?

The TLS cert providers are actually pluggable at this point, so I think we
can theoretically build an ACME cert provider and have it all be built-in.
I would love to see this happen, but the reason it hasn't happened yet is
that everyone just does it with a sidecar and it's not a burning need.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/envoyproxy/envoy/issues/96#issuecomment-706736719,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABWEL7DMXRUYABG2UTZXZLSKHRVXANCNFSM4CQTEFAA
.

[phlax]

Probably the path you want to take here.

from my understanding cert-manager depends on kubernetes.

i think ideally we want something that can work outside of kubernetes