3 ms·

If you want to be able to spin up CI/CD containers, don’t you kinda already need to have docker socket access? In that case, you’ve already decided that this is

If you want to be able to spin up CI/CD containers, don’t you kinda already need to have docker socket access? In that case, you’ve already decided that this isn’t a threat vector you’re concerned about. Yes, this probably makes it easier, but the ability to startup new containers for CI/CD is what makes this threat possible. So, I’m not sure this is something I’d worry much about. Perhaps they should flag this in the documentation as something to be noted, but otherwise, I’m not sure how else you get this functionality. Is there another way?

zenoprax 1y ago
Running a binary as a non-root user with scoped access to Docker commands seems more appropriate to me.
- franga2000 1y ago
  What do you mean by scoped access? A bunch of regexes checking that the app doesn't add any dangerous flags to docker run? That sounds like a fun CTF challenge to me, which is not a good thing for a security feature...
soraminazuki 1y ago
It's a multi-user Git / CI /CD / project management platform. If you introduce this in your organization, a single vulnerability can take down the entire system and any other application running on the same host. You can't just "decide that this isn’t a threat vector" without taking the use case into account. Or at least it should come with alarm bells warning users that it's unsafe.
- franga2000 1y ago
  What is "entire system" here? I'd run something like that in a VM, so the "entire system" would be nothing but the app itself. If there is a RCE vuln in the app, your users are just as unsafe if it's running as root on the host or if it's running as nobody in a container. The valuable data is all inside.