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> map<string, string> annotations = 7; // Optional configurations specific to Linux hosts. LinuxPodSandboxConfig linux = 8;

Related discussion:
text: Seccomp profile is passed to runtime by in CRI: is relative to node's local seccomp profile root, it is defined in kubelet. But runtime doesn't know it. We should pass full profile path in CRI. cc/ Will file a PR to fix this later.
Add support for Seccomp sounds like a new feature. The milestone should be reset to , correct?
not really. The current implementation supports seccomp already. If it's missing critical information to function properly, this would be a bug.
are we blocking releases for CRI in 1.5? i was not sure, so marking this as non-release-blocker and leaving 1.5 milestone. please correct if i am mistaken.
I don't get why this is a 1.5 targetted thing myself. Yes we want CRI to be in a good state in 1.5, but afaik we have zero intention of anyone actually using (at the very least because of the lack of exec auth regressing kubelet security). why should this be part of 1.5?
First, this is a small enough change that allows non-docker integrations to properly support seccomp. Second, if "we have zero intention of anyone actually using" is a valid reason, we should never fix any bugs in CRI. We do want people to try using it (perhaps not in production yet). However, given that seccomp is only in alpha, I am ok with dropping this and just continue the docker support for now.
Perhaps I misunderstood the meaning of code freeze, but I thought it was only bug-fixes regardless of size of change (or exceptions that have gone through some process) What I meant is we don't intend this to be used generally as part of the 1.5 release. Because of that, I don't think we should consider bugs in CRI bugs for the purpose of the 1.5 release freeze. My statement is just that we shouldn't violate code-freeze for this. We should totally fix this right after the 1.5 freeze window ends, and saying that I'm arguing we should never fix anything is disingenuous and taking it to an absurd extreme.
the only thing we don't seem to agree on is whether seccomp support was considered to be supported for CRI in 1.5.