Add --cap-add as and --cap-drop to swarm services #26849
Conversation
Fixes moby#25885 Having this in place we can now use capabilities in the following CLI calls respectively in the corresponding API calls. - docker service create - docker service update Signed-off-by: Alexander Berger <alex-berger@gmx.ch>
|
The corresponding PR for swarmkit is here moby/swarmkit#1565, once it has landed I will update the vendoring for swarmkit. |
There was a problem hiding this comment.
Thanks @alex-berger. This PR needs some more discussion. Also, to allow the option of having mixed-platform (Linux/Windows/Solaris?) Swarms, we should discuss if this option (which is Linux specific) should be copied 1-on-1 from the docker run syntax, or if we need a more "generic" concept /cc @stevvooe @aluzzardi @justincormack
| Options: | ||
| --args string Service command args | ||
| --cap-add Add Linux capabilities (default []) | ||
| --cap-drop Drop Linux capabilities (default []) |
There was a problem hiding this comment.
This won't work; the service update command allows you to specify the diff / changes, compared to the current service specification, so if we use the current convention; this would become --cap-add-add, --cap-add-rm, and --cap-drop-add, --cap-drop-rm, which would be really confusing.
We need to come up with different naming for this.
There was a problem hiding this comment.
For me as user it's OK to have --cap-add-add, because it express exact the intention to add or remove something to or from --cap-add. Another name I can think of is like --cap-extra-add/--cap-extra-rm. Or --cap-include-add/--cap-include-rm and --cap-exclude-add/--cap-exclude-rm.
|
I don't really like the current So I don't think we should add the interfaces as is to Swarm mode. |
|
I would be very pleased if someone could shed a light on the vision/plans for Docker Swarm Services. What are the goals and non-goals? If it won't fit well with the overall vision for Docker Swarm I will then gladly close this PR. |
Yes, that's an issue, and one that should be addressed (we don't want to end up with completely "dumbing down" services, if not all platforms support a feature)
I think it's ok to keep it open for now, for discussion. I agree that some goals/guidelines should be written for this. We do want to move forward, but at the same time prevent implementing features "because we can", and regretting that decision later (deprecating features is far more complicated than adding them). |
|
My understanding is that mixed platform will be supported, but that should not mean dumbing down, so the swarm should do its best to find somewhere it can run your job that requires a particular OS, device (eg we have requests for GPU hardware), or privileges. However we don't want to carry over interfaces that could be improved as it is a good opportunity for some judicious revision of interfaces. |
|
@justincormack we need this. I agree that explicit |
|
@errordeveloper I had an idea about this on the way back from the Docker Summit, so am working on this. |
|
@justincormack should we close this PR while you're working on an alternative? |
|
Yes, am making some progress, we can always reopen. On 13 Oct 2016 6:30 p.m., "Sebastiaan van Stijn" notifications@github.com
|
|
Ok, let's close this PR for now. Thanks @alex-berger! |
|
Hi @justincormack , any chance to update us on the progress on this front ? Thanks ! |
|
Any roadmap on fixing the capabilities support regression on Linux? For example we have a container requiring CAP_NET_ADMIN and it's impossible to run on swarm... EDIT: Is there a way for a daemon to not disable certain capabilities by default? (Globally, not per container) |
|
Is there a work around to enable some caps during 'service create'? |
|
@justincormack @thaJeztah can we reopen this PR? As we already have been supporting bind-mounting arbitrary path including docker.sock, I don't see any security degradation in this PR. |
|
@AkihiroSuda I can reopen, but this will probably have to be reimplemented to use @AkihiroSuda do you want to work on this / carry that? |
|
FYI, I do not intend to restart working on this PR as I no longer have any need for this Swarm feature. |
|
@alex-berger no worries; thanks for the update, and thanks for starting the work on this 👍 |
|
Hi, is there any update on this? We have a VPN that needs NET_ADMIN permissions and another server than needs NET_RAW, and we can't run these on stack deploy. |
|
+1 @justincormack should continue the great work he started in 2016. |
|
Work is continued in #38380 (thanks @olljanat!), so closing this one. Thanks for starting the work on this @alex-berger ! |
Fixes #25885
This PR adds Linux capabilities support to Docker Swarm services.
Having this in place we can now use capabilities in the following CLI calls respectively in the corresponding API calls.
Signed-off-by: Alexander Berger alex-berger@gmx.ch