security profiles: discussion

[philips]

There is a nascent concept of security profiles that needs to be tackled. I think we should remove it from the spec as it is a little too ill-defined at the moment.

The big idea is that a system can have a collection of "high-level" security profile options that a user can apply to their container. For example:

• Default security profile
• Privileged security profile
• Untrusted security profile

These profiles would map to low-level details like seccomp filters, selinux profiles, apparmor profiles, etc. The challenge for the spec is to ensure that we define the "merge" operation from the restrictions that an image defines for itself and what the policy it is going to run under defines.

[jonboulle]

Prior art, in Kubernetes this is the security context

[thecloudtaylor]

For Windows this could be utilized to MAP between Windows Server Containers and Hyper-V Containers.

[mrunalp]

We discussed this in the face to face and concluded that it makes sense to handle this at a higher level. Higher level could create profiles that map to specific values in the spec. Different vendors can't agree on what their security levels actually translate to and hence better left up to higher levels.