5 ms·

The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to pr

The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to provide. I see no attempt to explain why this level of access is necessary. I can guess why you think you need it, but whatever the reason it's not good enough. If you need job workers or some other kind of container, tell me how to run those with docker compose.

franga2000 1y ago
It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose. I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically everything does it this way and there isn't really a good alternative without a ton of additional complexity the vast majority of people won't need.
- worldsayshi 1y ago
  Isn't kaniko designed to solve this?
  - franga2000 1y ago
    As far as I know kaniko handles the "I'm a CI job inside a container and I want to build a container image" part. The reason CI/CD runners need socket access is to create those job containers in the first place. Using Podman to create job containers inside the app Docker container would be a solution, but Podman containers have many subtle incompatibilities with Docker and its ecosystem, so it makes sense they wouldn't want to use that, at least by default.
- hamdingers 1y ago
  > It breaks the isolation for that one container, the rest are just fine. Wrong. A container with access to the socket can compromise any other container, and start new containers with privileged access to the host system. It compromises everything. This is a risk worth flagging.
  - mbreese 1y ago
    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.
- soraminazuki 1y ago
  It's poor security practice that shouldn't be overlooked. Mounting the Docker socket effectively allows the entire application to run with root privileges on the host. Given that this seems to be a multi-tenant application, the implications are even more concerning. The component responsible for spinning up CI/CD containers shouldn't operate within the security boundary of the rest of the application. On a related note, I believe Docker's design contributes to this issue. Its inflexible sandboxing model encourages such risky practices.
  - soraminazuki 1y ago
    Apparently multiple people were triggered by the idea that their organization's Git forge, CI / CD, and project management shouldn't be a single system running as root. I can't fathom why.
  - franga2000 1y ago
    No shit, I don't know why everyone is trying to explain Docker basics to me. All I'm saying is that socket access is required to spin up containers and it's nothing out of the ordinary for this use case. Of course it's an issue if you're using Docker to isolate OneDev from the rest of the apps running on your systems. But that's not everyone's use-case. Anything that intentionally spins up user-controlled containers should be isolated in a VM. That's how every sane person runs GitLab runners, for example.
supriyo-biswas 1y ago
I guess one way of doing it would be to have two instances of rootless docker running, one with this project meant to run all containers, and the one exposed to the container being the other docker engine instance for CI/CD jobs.
ranguna 1y ago
Iirc that's how gitlab runners does this as well. Not saying that just because someone else does, it makes it ok, but just putting it out there.

franga2000 1y ago

It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose. I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically everything does it this way and there isn't really a good alternative without a ton of additional complexity the vast majority of people won't need.

worldsayshi 1y ago
Isn't kaniko designed to solve this?
- franga2000 1y ago
  As far as I know kaniko handles the "I'm a CI job inside a container and I want to build a container image" part. The reason CI/CD runners need socket access is to create those job containers in the first place. Using Podman to create job containers inside the app Docker container would be a solution, but Podman containers have many subtle incompatibilities with Docker and its ecosystem, so it makes sense they wouldn't want to use that, at least by default.
hamdingers 1y ago
> It breaks the isolation for that one container, the rest are just fine. Wrong. A container with access to the socket can compromise any other container, and start new containers with privileged access to the host system. It compromises everything. This is a risk worth flagging.
- mbreese 1y ago
  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.
soraminazuki 1y ago
It's poor security practice that shouldn't be overlooked. Mounting the Docker socket effectively allows the entire application to run with root privileges on the host. Given that this seems to be a multi-tenant application, the implications are even more concerning. The component responsible for spinning up CI/CD containers shouldn't operate within the security boundary of the rest of the application. On a related note, I believe Docker's design contributes to this issue. Its inflexible sandboxing model encourages such risky practices.
- soraminazuki 1y ago
  Apparently multiple people were triggered by the idea that their organization's Git forge, CI / CD, and project management shouldn't be a single system running as root. I can't fathom why.
- franga2000 1y ago
  No shit, I don't know why everyone is trying to explain Docker basics to me. All I'm saying is that socket access is required to spin up containers and it's nothing out of the ordinary for this use case. Of course it's an issue if you're using Docker to isolate OneDev from the rest of the apps running on your systems. But that's not everyone's use-case. Anything that intentionally spins up user-controlled containers should be isolated in a VM. That's how every sane person runs GitLab runners, for example.

supriyo-biswas 1y ago

I guess one way of doing it would be to have two instances of rootless docker running, one with this project meant to run all containers, and the one exposed to the container being the other docker engine instance for CI/CD jobs.

ranguna 1y ago

Iirc that's how gitlab runners does this as well. Not saying that just because someone else does, it makes it ok, but just putting it out there.