[feature request] set services to non-root and read-only file system by default

[astromechza]

I'd like to propose that compose workloads are set to non-root and read-only by default - and then users should opt-in to enabling root or readable fs if the workloads strictly requires it.

This would ensure that workloads follow best practise by default, and are most broadly compatible by default. We tend to find that security constraints are the most common thing that customers "patch" into the output manifests for compose and k8s.

For compose, this would mean setting the read_only flag on output workload services (not on services generated by provisioners) and warning the user if their image does not contain a USER stanza. See https://docs.docker.com/reference/compose-file/services/#user. We could perhaps fail if the image does not contain this and the customer must provide the root override instead. However, I don't really know how we can efficiently determine if the container image contains an image stanza.. If we have the image locally we can inspect it using tar/oci image formats/docker inspect, however if the image is remote and will only be pulled on compose up, we won't have this information yet.

We also don't yet have a way of declaring the security section or extra capabilities that a workload requests.

[mathieu-benoit]

I really like the idea, with a security first and by default approach, and options to disable it or at least to override the default values?

Today, on my end, I'm doing this:

score-compose generate score.yaml \
    --build 'webapp={"context":"."}' \

echo '{"services":{"nginx-webapp":{"read_only":"true","user":"65532","cap_drop":["ALL"]}}}' | yq e -P > compose.override.yaml

We should definitely simplify this... this yq part is not very built-in...

So this highly secure by default with read_only, user and cap_drop would be really great.

[mathieu-benoit]

End users can now use this patch template https://github.com/score-spec/community-patchers/blob/main/score-compose/unprivileged.tpl, like this:

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

Do we still want this feature request directly in score-compose, or should we close it now?

[mathieu-benoit]

Closing as per last comment, now available via community patch templates: https://github.com/score-spec/community-patchers.