Use off-the-shelf components for proxy, certificate management?

[infogulch]

Hi!

After looking over the architecture I noticed that teleport develops several components in-house for which there are pretty decent open source off-the-shelf alternatives. In particular, Caddy is a great l4/l7 proxy with some very useful and well-tested features like automatic certificate retrieval and renewal via ACME and a programmable API for proxy configuration, and step-ca is an online certificate authority service that does automated certificate management.

There are various reasonable business justifications to build your own instead of using third-party solutions, for example to have the agency to tailor their development to your specific use-case. But there are symmetric reasons to build on top of external projects, like being able to focus development on your core competency.

Have you considered using external projects to deliver some services? And have you considered using Caddy and step-ca in particular?

Related:

#8805 (comment)
#9799
https://github.com/caddyserver/caddy
https://github.com/mholt/caddy-l4
https://github.com/smallstep/certificates

[webvictim]

I think we leave these as exercises up to the reader. I personally use Caddy in front of Teleport in my home lab (so I can run various different HTTPS services on the same port) and agree that it's an excellent reverse proxy with some great functionality, but bundling it into Teleport as a requirement for deployments still wouldn't be something I'd encourage.

[infogulch]

Given the prevalence of using a reverse proxy in front of teleport (as evidenced by your comment and many issues), and the fact that this first proxy is capable of serving the same functionality as teleport's custom implementation, I'm still left wondering why I need a second proxy (and associated downsides) when the complete functionality could be implemented as configuration on the first proxy.

Downsides of using two proxies that I'm concerned about are: increased latency, increased deployment complexity, increased chance of misconfiguration, increased compute and network consumption, increased vulnerability surface area.

My suggestion is less to add Caddy as another component of the standard deployment, but to replace the current proxy entirely with Caddy, resulting in the same number of components needed for a standard teleport deployment, but reducing the number of running services and network hops in common installations because implementers can reuse the one reverse proxy.

[klizhentas]

We have no problem with folks using Caddy in front of Teleport, or external CAs. However due to the security and compliance nature of our business we are wary of bringing critical external default dependencies in scope because we have have to have in-house solution that we regularly audit and can patch quickly.

[infogulch]

Retaining agency over your full product solution for auditing and patching to meet security and compliance requirements seems reasonable. A symmetric counter-argument could be that using a third-party product that serves a larger customer base may have better security and auditing capabilities in practice due to its wider use and dedicated staff.

I'm not familiar enough with Teleport (or Caddy or step-ca for that matter) to come to a conclusive determination when weighing these arguments, but I think they are worth considering together.

[ancona]

I would be happy if there were a way to configure acme endpoints to make use of step-ca in non-public environments (I have not found any hints on this in the documentation). Is this on your roadmap?

Thanks

[webvictim]

Is this on your roadmap?

Not currrently.