docker service create "--security-opt" option

[tianshr123]

There is a --security-opt flag in docker run, Will there be support for a similar option in docker service create?

[thaJeztah]

#25303 keeps track of options that are available on docker run, but not (yet) supported for services. (#25209 also mentions the --security-opt flag).

The --security-opt flag provides various options (apparmor, seccomp, selinux); are there specific options in those that you're looking for?

[Rojikku]

For a purpose like accessing cloud storage via rclone, security_opt apparmor:unconfined is necessary.
I see cap_add is in progress for 20.03, and devices /dev/fuse...Maybe one day. That's all I really need for this.
Alternatively, privileged: true works fine, but I don't foresee that happening anytime soon.

[mhemrg]

In our Docker Swarm cluster, we need to load custom AppArmor profiles for Swarm services.

[dohnto]

We are in the same situation as @mhemrg - we need custom AppArmor profile.

[1riggs]

I'm working on a project which requires support to set the seccomp profile using a custom seccomp profile json file for Swarm services, and would love that option to be added.

[suukit]

We'd need to set no_new_privileges in swarm mode.

[dehy]

I actually need --security-opt on Docker Swarm to load an AppArmor profile for running DataDog Agent with a global deploy mode.

It actually produces AppArmor DENIED logs continuously and can be fixed in k8s with custom AppArmor profile (DataDog/datadog-agent#6915)

[andystroz]

Any updates on when --security-opt will be added to swarm, specifically seccomp?

[q5616417]

Still no updates? Would simply be nice to know if this issue is in the scope of someone or if the statement is that the use of apparmor (for example) together with docker in swarm mode is not supported and won't be in the near future.

[martin-marko]

Still looking for --security-opt also, any workaround for setting seccomp for services in a swarm?

[mjf]

Imagine running Docker Swarm with SELinux enabled and container policy in use happily. Suddenly you are in need to allow a single service to access the Docker socket! It could be some CI worker based on Docker or perhaps some Docker Swarm orchestrator your customer requested or whatever else... Now, how to do it without breaking the overall Docker security? Of course, one would just tune the SELinux a bit for the certain service, but...

Imagine that you were so desperate that you tainted the SELinux policy with custom module allowing the container's SELinux type to access the type of the Docker socket and allowing it to connect to and write to the socket in the end. That's definitely not the right way to do it because the moment you effectively ruined overall Docker security! But this sort of things must have been happening all the time! Poor, desperate sysadmin! Just read the blogs out there. How many Docker Swarm instances are running with such dangerous hacks in use? Are all those people who already did so really supposed to write some post-mortem blog posts one day?

Imagine you at least told us how to do such things the right (meaning documented and reproducible) way in Docker Swarm for now first. Do not force us to use any sort of undefined, unsupported or insecure hacks to achieve what's otherwise pretty common and normal for most of the system administrators anymore! Let us setup security-related things in a sane way again. Let us take full control of our systems again! Provide us with full and well-granulated support for SELinux, AppArmor, Linux capabilities etc. - for both the compose file and service commands. I would also suggest to cooperate more closely with the SELinux policy developers and other experts too.

Imagine...

services:
  my_service:
    image: my_image
    security:
      selinux:
        user: my_user_u
        role: my_role_r
        type: my_type_t
        range: s0:c1,c0
      capabilities:
        - CAP_NET_ADMIN

There are lot of discussions about lacking these basic security features for Docker compose for a long time... Is this state of the things going to stay forever? 👎

[jasunen]

In our Docker Swarm cluster, we need to load custom AppArmor profiles for Swarm services.

The same!
Need Swarm mode support for "--security_opt apparmor=unconfined" or "--security_opt apparmor=my_apparmor_profile"

[pavelsevcik]

+1

it's also required to run netdata as service as per netdata/netdata#11933

[dtufood-kihen]

+1

Needed to run Podman in Docker Swarm

[Microbion]

Any updates now?

[thaJeztah]

Options for AppArmor and Seccomp options were added in SwarmKit's API;

• Add support for Seccomp and AppArmor profiles. swarmkit#3152

I need to check with @dperny if those options are wired up everywhere though

[Qwarctick]

Options for AppArmor and Seccomp options were added in SwarmKit's API;

* [Add support for Seccomp and AppArmor profiles. swarmkit#3152](https://github.com/moby/swarmkit/pull/3152)

I need to check with @dperny if those options are wired up everywhere though

Hey @thaJeztah and @dperny, any news on this ? It does not seem to be release yet.

[Qwarctick]

Ok. I saw that #46386 has been merged into Docker 25 but still doesn't seem usable at the moment. What is missing to make it usable?

[bgemmill]

seccomp:unconfined is currently needed to initialize and run an io_uring via the syscall io_uring_setup.

edit: io_uring is not on the allow list yet