Add support --privileged when create service

[jimmyxian]

When create some container, we need privileged=True. But swarmkit does not support this. I want to implement this by the following steps:

• Add privileged field in ContainerSpec.
• Pass privileged to HostConfig when create container.

If it's the right direction, I will submit a PR. :)

Also, there so many container options in docker-engine. If all the options are supported in that way, It's a huge work.Maybe we need have a good way to support all the options?

[FZZFh]

When create some container, we need privileged=True. But swarmkit does not support this. I want to implement this by the following steps:

• Add privileged field in ContainerSpec.
• Pass privileged to HostConfig when create container.

If it's the right direction, I will submit a PR. :)

Also, there so many container options in docker-engine. If all the options are supported in that way, It's a huge work.Maybe we need have a good way to support all the options?

When create some container, we need privileged=True. But swarmkit does not support this. I want to implement this by the following steps:

• Add privileged field in ContainerSpec.
• Pass privileged to HostConfig when create container.

If it's the right direction, I will submit a PR. :)

Also, there so many container options in docker-engine. If all the options are supported in that way, It's a huge work.Maybe we need have a good way to support all the options?

hi,i meet this problem again , i don't know how to Add 'privileged' field in ContainerSpec. and Pass 'privileged' to HostConfig when create container ,in fact ,i don't know it's mean, can you just give me a guide to achieve the two things . sorry for my poor english. 老哥，这两句是要配置啥啊，我没看懂英文，可以说明一下吗，谢谢：）

[olljanat]

@FZZFh this issue is about feature request. It does not exist yet.

I'm working on it and you can see status on https://github.com/moby/moby/issues/25885#issuecomment-447657852 target is get it released as part of Docker 19.06.

[olljanat]

moby/moby#39173 was merged so this feature will ship as part of Docker 19.06 / 19.09 (not sure actual version yet).

Please, look my question about CLI side implementation on https://github.com/moby/moby/issues/24862#issuecomment-501019133

[prologic]

Very nice! I've been anxiously waiting or this feaure for years!

[couillonnade]

I am wondering if there is a safe way to use it now since neither 19.06 nor 19.09 seem to be on the the horizon. Could not find any information about the next stable release and what happened to the release cycle we use to have. Anyone has information on that?

[olljanat]

FYI https://github.com/moby/moby/issues/25885#issuecomment-557790402

[brian-finisher]

I think there is still very much a strong case for the equivalent of --privileged in Docker Swarm, particularly for the embedded, robotics, IoT and hobbyist spaces. It seems this may be the best use of Docker Swarm these days, anyways, as the rest of the world is migrating to Kubernetes and apparently has the compute resources to do so.

There was a simple solution

From what I can gather, arguments against privileged support are effectively that it is too open and finer grained allowances should be given.

1129 added this feature, but was shot down

Then there were security profiles. Shot down Then there were Entitlements. Doesn't seem to be any progress on it.

I'm very empathetic to striving for a perfect solution, particularly for cloud users (though... are there many left?). But, this request is from 2016. Here we are, 6 years later, and do not have any working solutions - but several open and unimplemented proposals. The world and Swarm's userbase seems to have changed in that time.

Inconsistent with Docker CLI & docker-compose

It is both surprising and confusing that features available in "docker run" and docker-compose yaml are not supported in swarm mode. Why, exactly, am I allowed to use --privileged in these but not in swarm? I should very much like there to be consistent behavior between these modes. As an end-user, I basically just want Swarm to be a cluster-equivalent layer over docker-compose, which is a config-file layer above 'docker run'. While I know this isn't the actual architecture, it does make sense conceptually.

Problems with forcing explicit devices in the device proposal

While I appreciate the thinking behind the device proposal for swarm, it does create a bit of a nightmare to have to explicitly list out allowed devices - particularly when those devices may be somewhat arbitrary or random, or dynamically created/destroyed.

Take, for instance, USB devices. I may have a USB device that ends up on /dev/bus/usb/001/003 or perhaps /dev/bus/usb/002/001 and whatnot. It may just depend on how somebody was feeling like plugging things in that day.

Ideally, I would like any and all USB devices available to my containers on a given node. I want the logic for enumerating those devices, finding the correct serial number, etc, to live within a container. I don't want to have to edit .yml files every time a hardware config changes.

With --privileged, it is possible to bind-mount an entire directory of devices. /dev/bus/usb. Now my containers can access any USB devices, enumerate USB devices, etc. If a USB hub is connected, disconnected, etc, it will be available in the container dynamically. This is not the case with the --devices proposal equivalent.

There are no other reasonable cluster orchestration alternatives for embedded systems

I have researched running Kubernetes on our embedded computers, and, it is a resource hog. Even microk8s has kubelite at about 540mb of RAM usage, 30-40% CPU just sitting there - not even running any containers. Taking up 1/4th the resources of a 2GB Raspberry Pi or Jetson Nano is unacceptable. Docker Swarm's unique advantage is its efficiency.

Balena doesn't support swarms/clusters.

Without privileged containers, my only current reasonable option is to give up orchestration with a single .yml config, and instead need to install and run docker-compose on every one of my nodes. I'll have to ssh into each one manually to start/stop services.

[djmaze]

@brian-finisher The workaround given by AkihiroSuda works pretty fine for me. Can also be easily specified in a stack yaml.

(I admit a clean solution would be nicer though.)

[bluepuma77]

We just started detailed monitoring of Docker Swarm with prometheus. We need to watch drives on dedicated servers, so smartmon is the tool of choice. After testing with a container in --privileged mode, I wanted to create a service to run it on all nodes - just to find that --privileged is not supported in Docker Swarm. What???

I agree with @brian-finisher that we would love to see a pragmatic solution, that is available in short term. Discussions on over-engineered solution with granular security settings that don't get implemented do net help, they just drive users away. The --privileged functionality is already in Docker, so it should be not hard to enable it in Swarm.

Please give Docker Swarm users the opportunity to use --privileged, we are aware of the security implications.

[Hobbit44]

As we roll into 2023 and coming up on 7 years that this issue has been around, any sign of this being done?

[olljanat]

Up to date pull request switch implements this exist on https://github.com/moby/swarmkit/pull/3072 but because maintainers didn't wanted to pickup it to version 23.0.0 that can happen earliest on version which comes after that (API changes are only allowed in main versions).

Afaiu maintainers are now busy to finalize that version and after that discussion can start (once again) that what would be solution which they would be ready to accept.