Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

onedev.io

Post reply on HN
Print view View original

41–50 of 67 posts

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#41

Post by mbreese »

hamdingers wrote: post #38
franga2000 wrote: post #34

Earlier quoted context omitted.

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 ever…

> 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.

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?

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#43

Post by zenoprax »

mbreese wrote: post #41
hamdingers wrote: post #38

Earlier quoted context omitted.

> 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.

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 th…

Running a binary as a non-root user with scoped access to Docker commands seems more appropriate to me.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#44

Post by n4bz0r »

odie5533 wrote: post #20
pheggs wrote: post #19

Earlier quoted context omitted.

I've been hosting a git service for quite a while now and it's maybe around half an hour per year of maintenance work. It's totally worth it in my opinion, it's so much better on almost every way ... One big reason is decentralization. Full control of data, change what you want, then things like the current npmjs attack show the downsides of having everyone using the same thing, and so much more

Backups, OS upgrades, version upgrades, firewall management, DDoS management. I just find self-hosting to be excessive to do right.

The concerns are valid, but I'd like to point out that managing all that isn't as frightening as it sounds.

If you do small scale (we're talking self-hosted git here after all), all these are either non-issue or a one-time issue.

Figuring out backups and firewall is the latter. Once figured out, you don't worry about that at all. Figuring these out isn't rocket science either.

As for the former. For minimum maintenance, I often run services in docker containers - one service (as in compose stack) per Debian VM. This makes OS upgrades very stable and, given docker is the only "3rd-party" package, they are very unlikely to break the system. That allows to set unattended-upgrades to upgrade everything.

With this approach most of the maintenance comes from managing containers' versions. It's a good practice to use fixed containers' versions which does mean there is some labor involved when it comes to upgrading them, but you don't always have to stick to the exact version. Many containers have tags for major versions and these are fairly safe to rely on for automatic upgrades. The manual part of the upgrades when a new major release comes out can be a really rare occasion.

If your services' containers don't do such versioning (GitLab and YouTrack are the examples of that), then you aren't as lucky, but bumping a version every few months or so shouldn't be too laborsome either.

Now, if DDoS is a concern, there is probably already the staff in place to deal with that. DDoS is mostly for popular public services to worry about, not for a private Gitea instance. Such pranks are costly to randomly poke around and require some actual incentive.

But why keep a private instance out in the open anyway? Put it behind a VPN and then you don't really have to account for security and upgrades as much.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#45

Post by shivasaxena »

bigfishrunning wrote: post #27
rmoriz wrote: post #24

Earlier quoted context omitted.

Microsoft/GitHub has no model training. How do you think Copilot works? Also if you provide open source, people and companies are gonna use it.

When I publish open source code, I don't mind if people or companies use it, or maybe even learn from it. What I don't like is feeding it into a giant plagiarism machine that is perpetuating the centralization of power on the internet.

[dead]

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#46

Post by supriyo-biswas »

hamdingers wrote: post #28

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…

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.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#47

Post by soraminazuki »

mbreese wrote: post #41
hamdingers wrote: post #38

Earlier quoted context omitted.

> 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.

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 th…

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.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#48

Post by soraminazuki »

soraminazuki wrote: post #39
franga2000 wrote: post #34

Earlier quoted context omitted.

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 ever…

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 no…

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.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#49

Post by supriyo-biswas »

n4bz0r wrote: post #44
odie5533 wrote: post #20

Earlier quoted context omitted.

Backups, OS upgrades, version upgrades, firewall management, DDoS management. I just find self-hosting to be excessive to do right.

The concerns are valid, but I'd like to point out that managing all that isn't as frightening as it sounds. If you do small scale (we're talking self-hosted git here after all), all these are either non-issue or a one-time issue . Figuring out backups and firewall is the latter. Once figured out, you don't worry about that at all. Figuring these out isn't rocket science either. As for the former. For minimum maintena…

For the GP's DDOS concern, you could just expose the service through a Cloudflare tunnel or something.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#50

Post by franga2000 »

hamdingers wrote: post #38
franga2000 wrote: post #34

Earlier quoted context omitted.

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 ever…

> 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.

Yes, that's exactly what I said. The container with the socket is not isolated, but all the other containers are, including the CI containers, which is the whole point.
Post reply on HN