Add CLI flags for Swarm Service seccomp, AppArmor, and no-new-privileges

[dperny]

- What I did

Add 3 flags to the docker service create and docker service update CLI commands to support the security options in moby/moby#46386.

• --apparmor allows setting AppArmor to default or disabled.
• --no-new-privileges does what it says on the tin
• --seccomp allows either default, unconfined, or a file name of a JSON file with a custom seccomp profile.

- How I did it

Added CLI flags in the standard way. Mostly boilerplate.

- How to verify it

Added tests for the flags.

- Description for the changelog

* Added `--apparmor` flag to `docker service create` and `docker service update`. Allows configuring AppArmor as `default` or `disabled`.
* Added `--no-new-privileges` flag to `docker service create` and `docker service update`.
* Added `--seccomp` flag to `docker service create` and `docker service update`. Allows setting seccomp to `default`, `unconfined`, or a custom profile.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 86.20690% with 16 lines in your changes missing coverage. Please review.

Project coverage is 59.62%. Comparing base (91d097e) to head (b66fa05).
Report is 52 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5698      +/-   ##
==========================================
+ Coverage   59.51%   59.62%   +0.11%     
==========================================
  Files         346      346              
  Lines       29379    29487     +108     
==========================================
+ Hits        17486    17583      +97     
- Misses      10923    10932       +9     
- Partials      970      972       +2     

[thaJeztah]

Looks like the linter complains on this one;

68.89 cli/command/service/opts_test.go:376:7: ST1003: const testJson should be testJSON (stylecheck)
68.89 const testJson = `{
68.89       ^

[thaJeztah]

Looks like this const is only used in the test below, so perhaps consider defining the const inside that test. Give that it's a very small JSON, perhaps put it on one line?

const testJSON = `{"json": "you betcha"}`

Oh; I guess that also means changing the file to be the same , well 😂

[dperny]

What is done:

• All CLI flags
• Compose file parsing

What needs to be done still:

• Error messages for bad flag values in CLI
• Evaluate possible problems with reading seccomp JSON file with os.ReadFile
• Compose type conversion (Compose -> Docker API types)
• Come up with way to ingest seccomp JSON file with Compose

What I have up now is ready for review, even in its incomplete state, but not ready for merging.

[corhere]

IMO it's the user's problem. The flag value is always a file path, except when it isn't; not reading a local file is the astonishing case. It's on them if the CLI process gets OOM-killed because they chose the wrong file.

That being said, interpreting any value aside from the special cases as a file path leaves no room to add new special cases, like additional seccomp modes. Adding a new special case would result in the flag --seccomp=foo changing semantics from reading a local file to whatever the special case is --- a breaking change.

I suggest that only values containing a path separator character be interpreted as a path to a custom seccomp profile. That cleanly solves several problems at once.

• Loading a custom profile from a file is always explicit and unambiguous. Users wanting to use a profile located in the CWD would have to pass --seccomp=./my-custom-profile.json in much the same way that a shell user has to type ./my-script.sh to run an executable from the CWD.
• All values not containing a slash or backslash character (aside from default and unconfined) are reserved for future use.

[corhere]

Return this. The CLI understands the option and what the user requested. We should tell the user why reading the file failed so they can take corrective action: fix the typo in the file name, sort out file permissions, etc.