Add support for privileged mode

[olljanat]

- What I did
#1129 was closed with #1129 (comment)

I think this was a pull request before its time. There will come a day when we add --privileged to swarmkit, but today is not that day.

Closing. Feel free to reopen later on (or right now), if you disagree.

Opening this one for checking if now six seven years later is right time to go forward with this one.

First step to implement #1030 / moby/moby#24862

- How I did it

1. Added new option to ContainerSpec
2. Generated protos
3. Copied relevant parts from Add support privilege when create service #1129
4. Added test case.

- How to test it
swarmctl service create --privileged

- Description for the changelog

[olljanat]

@dperny PTAL

[s4ke]

I think this might be useful as a stopgap for people waiting for apparmor support, see moby/moby#41371

[s4ke]

Having this in the next release of moby/moby would be really helpful and to me this looks simple enough to be merged.

[bluepuma77]

What will it take to get this pull request from 2016 finally merged? @olljanat @dperny

[spencerhughes]

Adding my voice to those who want this merged

[s4ke]

@thaJeztah PTAL

[s4ke]

Judging from the am amount of upvotes, this feels like something to be addressed. Does this PR make sense for the project?

[neersighted]

I think it's worth considering; there are a number of things I personally have been looking into plumbing recently:

• --userns=host
• --priviledged
• seccomp-related options
• tmpfs without noexec

As the keen-eyed may have noticed, the road to 23.0.0 has been painful and has sucked up most of the bandwidth of the project. I hope that we'll have a lot more energy to focus on Swarm in general once the release hangover and follow-up patch releases are over, myself.

[olljanat]

@neersighted I created this PR with hope that it would be early enough for 23.0.0 (as it would a lot of people happy) but because that was not the case we most probably should set as a target to get whole lost mentioned on moby/moby#25303 to be implemented on swarm mode on next major version as after all it is not that much code which is missing.

[s4ke]

@neersighted i must say your comment makes me really happy. Take your time. Such a huge Release after such a long time must be really painful.

I think I speak for everyone interested in swarm when I say that we really appreciate the new energy around swarm. The last thing we want is you guys burning out on this. Let us know how we, the community, can help.

[gabrielmocan]

I'm really happy with all this swarm come back! Looking forward to the coming features.

[bluepuma77]

@olljanat mentioned maintainers. #1030

@thaJeztah mentioned he is not a maintainer. #3036

Who is a maintainer? Who is responsible? Who is controlling the fate of Docker Swarm?

It doesn't look like Mirantis is doing much besides blog posts for their paid service.

How to get this seemingly ready pull request merged? What is blocking?

[s4ke]

@bluepuma77 people in this thread (@neersighted ) are from Mirantis - so they are on our (the community's) side :)

As mentioned above, this was a huge release. Let's not stress people out by asking too much right out of the start.

Also, there is a lot of work being done on the technical side for swarm (CI pipelines have been modernized, networking fixes over at moby/moby, PRs are starting to get merged) which no one in their right mind would do if they were to abandon the project.

Also, @thaJeztah is now a maintainer of swarmkit as well according to the MAINTAINERS file. The comment you linked is out of date.

[neersighted]

@thaJeztah and I briefly discussed this PR a bit the other day. There are still some concerns about merging it (everything from design principles to practical -- Swarm was built to be least privilege and to try to abstract away the coupled-to-the-implementation sins of the CLI).

I hope to discuss this in general with the Moby maintainers in a week or two -- step one is getting the (Mirantis-internal) SwarmKit backlog formally triaged which I am working on. Step two is getting out of the 23.0.0 release hangover which will require at least one point release, maybe two. Step three is compiling the knowledge we have of the lay of the land and historical context of some of the FRs/PRs so we can have a coherent discussion with the other maintainers and not waste people's time.

In any case, asking for updates/pinging here won't make things move faster, and we'll post back here (you might see we do that a lot in moby/moby) with a summary of what we discuss in the maintainer's call.

There's no guarantees this is merged yet (and that is not up to any one person), but time/nothing better becoming available is a strong argument (if weak technically), and it does deserve to be discussed & addressed at the very least.

[bluepuma77]

@neersighted For me it's also about security.

For services that need to access the Docker socket (like reverse proxy Traefik) it makes sense to use something like docker-socket-proxy to make the access more secure, but that needs --privileged to be able to run.

Therefore it would be great to provide --privileged as a Docker Swarm option that can manually be enabled, to improve the overall security of Docker Swarm.

[mhemrg]

PTAL @neersighted

[bluepuma77]

Many more months gone by. Pull request is waiting, why can't it be merged and be included in the next release?

Who is responsible for this decision? Who owns moby/swarmkit?

[olljanat]

FYI, I see that #3152 was merged so looks that those who are making decisions want to implement it first.

I know that it is not same than privileged mode but together with cap-add which was added couple of versions ago you can already solve many use cases.

[neersighted]

Indeed, that is the intent (to allow more workloads without the sledgehammer). We also discussed this recently in a Moby maintainer's call, but honestly not a lot moved -- we're generally okay with it, but it's against the historic design intent of Swarm, and so none of us want to proscribe this change to Swarm.

@dperny do you want to weigh in on if it's time to drop the 'purity' of SwarmKit and stop waiting for capabilities, and potentially allow this?

[olljanat]

@dperny do you want to weigh in on if it's time to drop the 'purity' of SwarmKit and stop waiting for capabilities, and potentially allow this?

FYI, this PR have been here for a while so I did close + reopen to trigger CI again. Looks to be still 🟢 so even that is not blocker...

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (master@48dd893). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #3072   +/-   ##
=========================================
  Coverage          ?   61.86%           
=========================================
  Files             ?      155           
  Lines             ?    31140           
  Branches          ?        0           
=========================================
  Hits              ?    19264           
  Misses            ?    10331           
  Partials          ?     1545           

[olljanat]

@thaJeztah and I briefly discussed this PR a bit the other day. There are still some concerns about merging it (everything from design principles to practical -- Swarm was built to be least privilege and to try to abstract away the coupled-to-the-implementation sins of the CLI).

@neersighted @thaJeztah @dperny compromise proposal. What it if we add new --swarm-privileged-enabled flag to Docker daemon which defaults to false and allow this only on nodes where it have been purposely enabled?

[ojaswa1942]

Knock knock!

[guilh22]

Any news on this? I think that a lot of swarm user are waiting for such feature. Without it some application are just not implementable in swarm. If it is not planned, maybe we could create a fork for a version with privileged enabled?