[Question]: What would be impacted if we turned off the need for privileged containers

[chadsly]

Is your question not already answered in the FAQ?

• [X] I made sure the question is not listed in the FAQ.

Is this a general question and not a technical issue?

• [X] I am sure my question is not about a technical issue.

Question

There are some users of this container that are trying to run in kubernetes. One of the requirements of this project is to run "privilege: true". However, I'd like to explore ways to remove this requirement for improved security and isolation. What approaches or adjustments can be made so that the container operates effectively within Kubernetes without needing or relying on host system access privileges? Any guidance would be greatly appreciated.

[kroese]

I was not even aware that this container needed "privilege: true" in Kubernetes to be honest. So what happens when you set "privileged: false"?

[chadsly]

There a few other issues that are already closed that were solved by adding the privilege access. They've shown issues with "NET_ADMIN". I'm assuming that it is because of something that you're inheriting rather than an issue that you are specifically creating. https://github.com/dockur/windows/issues/373 https://github.com/dockur/windows/issues/341

[kroese]

Ow yes, I see now they received a RTNETLINK answers: File exists error.

I am not sure what it means, so possibly there is a simple workaround for that. But the sole reason why you see the message about NET_ADMIN is because most of the time when that line fails, it will say RTNETLINK answers: permission denied when NET_ADMIN was missing. So I just wanted to provide a hint about the reason, and I just assume its the permission error, but the File exists error is very different and might have nothing to do with NET_ADMIN at all.

In any case: it fails while it tries to create a bridge. So the most easy solution would be to use DHCP mode, so that it does not try to create a bridge at all. That would be a quick fix to prevent running with privileged: true.

[chadsly]

That's awesome. I'll try DHCP mode.

[kroese]

Also, I am not really sure there is a real need to worry about running the container privileged.

If you are worried about my code doing something fishy, you can just read it as its open-source, and confirm that it does nothing bad.

If you are worried that some software in Windows is malicious, its already running inside the QEMU/KVM sandbox, which is much better isolation than Docker can ever provide (even with privileged=false).

So I cannot think of any real-world security risk of running it privileged.

[chadsly]

I'm able to get "started" in k8s, but I'm having some trouble with some settings.

As you can see in the attached image, the container is expecting /dev/net/tun (whatever that is) and NET_ADMIN

Any ideas how to turn on /dev/net/tun without NET_ADMIN?

[kroese]

There is an example Kubernetes file:

https://github.com/dockur/windows/blob/master/kubernetes.yml

which works fine.

[chadsly]

I'm really trying to solve this so other users don't have to run the privildge: true

Update... I was able to add DHCP. I had to look at the original QEMU image, then their entry.sh script, which led me to the netowrk.sh script. It's looking for the environment variable to be set. env:

• name: DHCP value: "Y"

I now have these resultant errors. We're getting closer, @kroese This is going to be even more awesomer when we solve this.

[kroese]

I already explained to you why this privileged flag is a non-issue for this container: https://github.com/dockur/windows/issues/491#issuecomment-2110836017

And I am the creator of that "original QEMU image", so that DHCP mode will create a macvtap interface which will need even more privileges than the simple bridge from the normal mode.

There might be a way to create this bridge without privileges, so if you want to spend time on a fix then thats great. But for me personally I dont think its important at all, so Im not going to look into it.

[chadsly]

Thank you.

[kroese]

@chadsly I added usermode networking in v3.12 for you. So the container can now run without NET_ADMIN permission, but usermode networking does not provide the same level of performance (it is slower). So its still not adviceable to use it, but at least it solves your issue.