[FEATURE] include workload security needs in the score spec

[astromechza]

Detailed description

Frequently, users of the score spec need to include security context when running their workload in a remote runtime, either to lock it down because admission policies require it (non-root, read only fs, cap-drop-all, etc) or to explicitly open it up (root, priviliged, etc..)

Some of these are things that are up to the score implementation (should be best-practice and secure by default) but others are workload-dependent things: some workloads must run as root or have access to the host networking/hardware namespaces.

• A separate security section in the spec
• A property indicating that the container root filesystem MUST be read/write for the workload to run. Note that the opposite isn't necessary: a workload that requires a read-only fs should be able to run fine on read-write.
• A property indicating that the container user MUST be root. Without this, implementations should check that the container has a valid USER stanza which is not == root OR should request non-root by default.

Possible implementations:

A: a seperate section

security:
  read_write_root_fs: true (default to false)
  run_as: root (default to 1000:1000 unless container has another non-root `USER` stanza)

B: capabilities

capabilities:
- read-write-root-fs
- run-as-root

Unfortunately neither approach really makes sense for things like k8s service account names 🤔

[mathieu-benoit]

I'm wondering if that's something at the spec level, but maybe rather at each implementation level instead?

• Devs shouldn't worry about this by default, and maybe they will have an annotation for the implementation itself, like" score.compose/run-as-user: root, etc.
• PEs have an opportunity to hide/abstract/standardize this in each implementation (either by default by the implementation itself, or by having a customization entrypoint).

[astromechza]

@mathieu-benoit Sure, but some settings are required for the workload to run successfully and those should be in the Score spec and cannot be ignored per implementation.

Eg: if a workload requires a writable root-fs, all implementations MUST support that for it to run otherwise it just won't work. I don't think annotations are good enough support there.