[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.

[ozie777]

It's always the lack of integrity that I dislike it leads to mediocre performance and negligence due to insecurities

[ozie777]

It's always the lack of integrity that I dislike it leads to mediocre performance and negligence due to insecurities

[rabelmervin]

Hi @mathieu-benoit I'm interested Can i work on this issue ?

[mathieu-benoit]

Thanks for the bump, @rabelmervin, but not yet ready to be tackled or picked up.

Since we captured this one, the patch templates feature for both score-compose and score-k8s came to life.

Allowing to inject custom security context section by doing this:

score-compose init \
   --patch-templates https://raw.githubusercontent.com/score-spec/community-patchers/refs/heads/main/score-compose/unprivileged.tpl

Or:

score-k8s init \
   --patch-templates https://raw.githubusercontent.com/score-spec/community-patchers/refs/heads/main/score-k8s/unprivileged.tpl

Not sure we need to implement anything else, otherwise we definitely need some refinements here. @astromechza @chris-stephenson, could you please share your thoughts here with more prescriptive guidance if we still think we need to do that?