Code change:
// // In general, in order to preserve a well-defined interface between the // kubelet and the container runtime, annotations SHOULD NOT influence <del> // runtime behaviour. For legacy reasons, there are some annotations which // currently explicitly break this rule, listed below; in future versions // of the interface these will be promoted to typed features. </del> <ins> // runtime behaviour. </ins> // // Annotations can also be useful for runtime authors to experiment with // new features that are opaque to the Kubernetes APIs (both user-facing // and the CRI). Whenever possible, however, runtime authors SHOULD // consider proposing new typed fields for any new features instead. <del> // // 1. Seccomp // //      key: security.alpha.kubernetes.io/seccomp/pod //      description: the seccomp profile for the containers of an entire pod. //      value: see below. // //      key: security.alpha.kubernetes.io/seccomp/container/<container name> //      description: the seccomp profile for the container (overrides pod). //      value: see below // //      The value of seccomp is runtime agnostic: //      * runtime/default: the default profile for the container runtime //      * unconfined: unconfined profile, ie, no seccomp sandboxing //      * localhost/<profile-name>: the profile installed to the node's //        local seccomp profile root. Note that profile root is set in //        kubelet, and it is not passed in CRI yet, see https://issues.k8s.io/36997. // </del> Annotations map[string]string `protobuf:"bytes,7,rep,name=annotations" json:"annotations,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // Optional configurations specific to Linux hosts. Linux *LinuxPodSandboxConfig `protobuf:"bytes,8,opt,name=linux" json:"linux,omitempty"`

Related discussion:
text: My interpretation is that we assumed seccomp would be supported until we found out that it wouldn't for other runtimes due to the lack of profile path. That's the only reason why I considered this a bug. Of course we could say that this is not really an important feature in CRI, so we can drop it, but we can be more clear on that.
If there's a bug in a feature no one uses, does fixing it make a sound? I think what we're not agreeing on is the role of CRI in 1.5. I understood it as something that is not generally usable. We can't recommend a customer use it, even as an experimental feature, due to security aspects (if nothing else). Correct me if I'm wrong. It's a developer integration point, and developers integrating with it are doing so with the kubernetes master branch, not with some release. Those reasons together result in my opinion that CRI is still not really a customer/release feature, and thus bugs or features related to it should not be exceptions to the freeze window, but rather should targeted at master as soon as the freeze lifts. If this were already post-freeze, would we be cherry-picking this over to 1.5?
This is not true. cri-o is depending on this fix for apparmor support.
is it depending on the 1.5 release branch directly, or on master?
I think it's better to make this in 1.5, so cri-o could work with first release with experimental CRI. It helps to encourage people to use CRI and find features misses or bugs.
Modifying the user-specified annotation is a little bit unsettling. I think adding a new annotation explicitly for the path would be better. Or, we should just add an explicit field for this. I spoke to and separately. I still think this is a bug fix, but we may want to be more careful about the fix. Given the time constraint, let's just list this as a known issue and work on it for 1.6.
OK, let's move this to next release and think carefully about seccomp feature besides this: kubelet may just pass the profile as string via CRI; may assume the profile locate in a file in a known format and pass path to the runtime; or maybe some other solutions.