Custom Resource Definition (CRD) for profiles about security-profiles-operator HOT 6 CLOSED

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.

from security-profiles-operator.

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.

from security-profiles-operator.

cc @cmurphy

from security-profiles-operator.

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

from security-profiles-operator.

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.

from security-profiles-operator.

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.

from security-profiles-operator.