CRI: add seccomp profile root path to runtime

[feiskyer]

This PR adds a new security.alpha.kubernetes.io/seccomp/root annotations to sandboxConfig to pass seccomp profile root path to runtime.

Fixes #36997.

cc @yujuhong @euank

[k8s-reviewable]

This change is 

[feiskyer]

cc @kubernetes/sig-node-misc

[k8s-ci-robot]

Jenkins GKE smoke e2e failed for commit 32de1fb. Full PR test history.

The magic incantation to run this job again is @k8s-bot cvm gke e2e test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.

[k8s-github-robot]

@feiskyer PR needs rebase

[euank]

I did a little more investigation, and as far as I can tell a seccomp root and the associated file structure is a docker specific (invented here) concept.

If we wanted to make this container runtime agnostic, the Kubelet could convert from that json to protobuf structs which clearly specify the exact details.

I think this is attractive for a number of reasons. Most importantly, the current specification is relying on incidental communication of state via the filesystem (passing references to files over an API is basically always an anti-pattern).

There are also things, such as no-new-privileges, which interact in some way with certain seccomp options, and so it makes sense for the kubelet to resolve a seccomp specification fully itself prior to reaching out to the runtime so that the kubelet may make any additional decisions that must be made.

That would also reduce the number of annotations that have magic powers, which is always a good thing in my book.

cc @lucab @jonboulle

[feiskyer]

If we wanted to make this container runtime agnostic, the Kubelet could convert from that json to protobuf structs which clearly specify the exact details.

Yes, I'm planning to add another issue to focus on the format of seccomp profile (in both kubernetes api and kubelet CRI). But it is not ready yet.

There are also things, such as no-new-privileges, which interact in some way with certain seccomp options, and so it makes sense for the kubelet to resolve a seccomp specification fully itself prior to reaching out to the runtime so that the kubelet may make any additional decisions that must be made.

If so, we need to spec the seccomp profile format first. (opened #39128 for this)

[timstclair]

Can you explain the motivation for this? There should be a single seccomp root path for the host, so this seems like a value that should be configured in the shim (e.g. flag), as opposed to a per-pod annotation.

@euank - I agree with you, but that's also not how seccomp works today. I'd like to be able to source seccomp (and AppArmor) profiles from ConfigMaps, and maybe at that point we could deprecate local profiles.

[feiskyer]

@timstclair This is a try to fix #36997.

I'd like to be able to source seccomp (and AppArmor) profiles from ConfigMaps, and maybe at that point we could deprecate local profiles.

If we have such plan, then we should pass full profile instead of path to runtimes.

[feiskyer]

Let's close this and move to #36997 to discuss more.