Live data from Hacker News

Traefik, Now With Native Go Plugins

traefik.io

61–65 of 65 posts

Re: Traefik, Now With Native Go Plugins

#61

I've been wanting to use Traefik for a long time but there's this security issue[0] that's almost two(!) years old now that's been keeping me from deploying it in production. As far as I can tell, there's still no out-of-the-box solution that's not overly complicated and won't come back to haunt me a year or two from now. [0] https://github.com/traefik/traefik/issues/4174 [1] https://doc.traefik.io/traefik/providers/…

This security issue is not that simple to manage as you probably know. It's mainly due to the fact that there is now way to have authorization on the the docker API. This is not the case on Kubernetes for example where you have RBAC to prevent this kind of issue. We have described this in detail in our documentation, and you have many solutions/workarounds to address this: https://doc.traefik.io/traefik/providers/doc…

> This security issue is not that simple to manage as you probably know.

I do think it's simple to manage: As I already mentioned elsewhere, it wouldn't be necessary for the network-facing part of Traefik to talk to the Docker API. There could be a second Traefik container (w/o network access) running a binary called, say, traefik-config-generator whose only task it is to talk to the Docker socket and generate a config and write that config to a shared volume.

EDIT: Oh, I just realized you're the founder of Traefik! Thank you so much for your work! I would really appreciate your opinion on my suggestion – even if you think it's complete BS. :)

Re: Traefik, Now With Native Go Plugins

#62
post #9

I've been wanting to use Traefik for a long time but there's this security issue[0] that's almost two(!) years old now that's been keeping me from deploying it in production. As far as I can tell, there's still no out-of-the-box solution that's not overly complicated and won't come back to haunt me a year or two from now. [0] https://github.com/traefik/traefik/issues/4174 [1] https://doc.traefik.io/traefik/providers/…

You've probably discounted this for some reason already, but why not use something more built for service discovery - e.g. Consul Catalog / k8s / etcd?

I was looking for a dead simple solution whose deployment wouldn't require much more than a simple `docker-compose`. :)

Re: Traefik, Now With Native Go Plugins

#63
post #31

Earlier quoted context omitted.

That so called "security issue" is silly. You don't have to deploy traefik with docker. If you want traefik to monitor new docker containers to add routes for them, of course traefik needs to talk to the docker api to do so. The docker api has no way to control access such that it's not equivalent to root access. However, there's no real vulnerability. I'm happy to provide you a url hosted by traefik with the docker…

> You don't have to deploy traefik with docker. Sure but in my case that was the whole idea. > If you want traefik to monitor new docker containers to add routes for them, of course traefik needs to talk to the docker api to do so. Yes, but it wouldn't be necessary for the network-facing part of Traefik to talk to the Docker API. There could be a second container (w/o network access) whose only task it is to talk to…

> I don't think it's up for debate that this is much worse than just running Traefik as a normal user

I'm not arguing that there's not a better option. In fact, when I say this is a "defense in depth" issue, that's exactly what I mean. It would improve security. It would be better. But there is no active vulnerability to be exploited. If the system works as intended, this doesn't cause any issues, it's only an issue if there are other real vulnerabilities.

> Do you also run your other web servers as root?

Yes, because capsh --cap-add NET_ADMIn is poorly understood and poorly used I run many other servers as root.

Admittedly, many of them are written in other languages such as C and fork workers that drop privileges because the c stdlib (libc) supports that easily.

Traefik is written in go where forking workers that drop privileges is much harder. Go doesn't use libc, and setuid doesn't actually work correctly [0], so of course it doesn't drop privileges like other software written in better languages.

> This is completely irrelevant. Once a hacker is inside the Traefik process (i.e. can execute code under Traefik's PID)

That's the entire point. It requires an attacker to exploit a real security issue, therefore this hardening you're talking about is a defense in depth.

The way you're talking about it, you make it sound like there's an active vulnerability, not just a defense in depth improvement. They're vastly different.

The developers are not ignoring a real vulnerability, and your all-or-nothing stance on this issue is un-nuanced to the point of harming your communication about it.

My previous offer is still on: $500 bucks that you can't exploit this if I link you to a traefik configured in this way you refuse to run it.

[0]: https://github.com/golang/go/issues/1435

Re: Traefik, Now With Native Go Plugins

#64
post #63

Earlier quoted context omitted.

> You don't have to deploy traefik with docker. Sure but in my case that was the whole idea. > If you want traefik to monitor new docker containers to add routes for them, of course traefik needs to talk to the docker api to do so. Yes, but it wouldn't be necessary for the network-facing part of Traefik to talk to the Docker API. There could be a second container (w/o network access) whose only task it is to talk to…

> I don't think it's up for debate that this is much worse than just running Traefik as a normal user I'm not arguing that there's not a better option. In fact, when I say this is a "defense in depth" issue, that's exactly what I mean. It would improve security. It would be better. But there is no active vulnerability to be exploited. If the system works as intended, this doesn't cause any issues, it's only an issue…

I actually think we're completely on the same page. :)

> The way you're talking about it, you make it sound like there's an active vulnerability, not just a defense in depth improvement. They're vastly different.

Please note that I never termed it a vulnerability (whether active or not). I merely called it a security issue – which it was/is because it gives users a false sense of security. I also made that point very clear in my post on Github.

> My previous offer is still on: $500 bucks that you can't exploit this if I link you to a traefik configured in this way you refuse to run it.

Being able to recognize and avoid potential security holes and being able to exploit them in practice are two different things. I think I'm fairly good at the former (in the sense that I'm able to avoid the most common pitfalls) but I have only limited experience with the latter. And while I am aware that in-depth hacking expertise would be very valuable even when examining certain security practices (it's definitely on my to-do list), I don't think it is required to point out basic flaws and potential attack vectors. So as much as I appreciate your offer, I don't think me being or not being able to hack your system implies anything with regards to how secure Traefik is.

Re: Traefik, Now With Native Go Plugins

#65

I've been wanting to use Traefik for a long time but there's this security issue[0] that's almost two(!) years old now that's been keeping me from deploying it in production. As far as I can tell, there's still no out-of-the-box solution that's not overly complicated and won't come back to haunt me a year or two from now. [0] https://github.com/traefik/traefik/issues/4174 [1] https://doc.traefik.io/traefik/providers/…

[deleted]
Post reply on HN