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 🤔