Custom Resource Definition (CRD) for profiles

[saschagrunert]

The idea is to create a CRD on top of profiles, which helps to:

• focus on a better user experience
• provides a useful abstraction, like the minimum amount of syscalls needed for container runtimes like runc
• easier create profiles on a higher level

[saschagrunert]

cc @cmurphy

[cmurphy]

I started working on a rough schema definition for this: https://gist.github.com/cmurphy/dc67e2d1214947972f41b7caa2ebf3ae

Going to look into using kubebuilder to translate the yaml into Go and build the controller.

[saschagrunert]

Awesome, thank you for the update @cmurphy! I’ll give it a look. (cc @pjbgf @hasheddan)

[saschagrunert]

I really like the proposal in the GitHub gist! One thing you've already mentioned is that some fields are not part of the runtime spec. Now it gets a bit tricky: The main reason of that is because before the runtime spec even existed, docker invented the original seccomp profile types there:

https://github.com/moby/moby/blob/master/api/types/seccomp.go
(used by docker nowadays and includes the additional fields, like comment)

But, we also have types there:

• https://github.com/containers/common/blob/master/pkg/seccomp/types.go
  used by CRI-O and Podman to not have a need to vendor docker
• https://github.com/containerd/containerd/blob/master/contrib/seccomp/seccomp_default.go#L51
  used by containerd, I think they only rely on LinuxSeccomp from the spec and do not use moby's types

I like the idea to just rely on the runtime-spec in the first place, because that's the only one where a common standard exists. On the other hand we have to find a way to express the capability bounding (see includes, excludes in your proposal, or here in containerd.

[pjbgf]

Just added some comments directly in the gist, but in short: yes, brilliant stuff from @cmurphy! 👍

@saschagrunert I would agree with your suggestion to start with support for the runtime-spec. If we document that non-OCI fields are only supported on the ConfigMap implementation we should have no problems.

I have a feeling that most users won't be using things such as includes/excludes. But if I am wrong, we can always rely on the community to feedback and ask for it later.

[cmurphy]

Thanks for the comments! I started a rough implementation here: #125

I added KILL_THREAD but haven't addressed the other questions of whether to include properties from the runtime spec vs docker vs containerd etc yet.