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: We need to clearly define it. define profile format clearly
Please document known issues for 1.5 in
(copied from ) And let's move here to discuss how to pass profiles to runtime. Related with .
This is issue is related with two level APIs: CRI, since we may also want to support profiles from ConfigMaps, I think we should pass full profile contents instead of path to runtime. issues is also related with seccomp api in kube-apiserver, it is based on annotations today. We should define seccomp profile format clearly (see ) and decide whether to add struct types to pod spec or just continue the annotations way. I think it's more clear to add specific struct types to pod spec.
Agreed - the path stuff is really a crutch (and implementation-specific) - I think is the answer here.
I don't disagree, but it's not strictly a requirement for supporting ConfigMaps (kubelet could create a file with the contents). An open question is whether to pass it as a raw string, or wait for and pass the structured data. The annotations way is deprecated (). I think the bigger question is where/how to put the data. E.g. structured data in the API, unstructured (string type) data in the API, reference to another object (e.g. ConfigMap). If the Kubelet needs to parse the spec, I think that's a good argument for a structured data type (either a standalone object or embedded in the pod API).
Yes, already opened to replace annotations with typed structs. I personally prefer a structured data type in both kubernetes API and CRI. WDYT?
A counter argument is that as the spec grows or new features are , we need to keep updating the Kubernetes API to maintain parity, or update the code in each CRI implementation to translate the Kubernetes spec. OTOH, if we use unstructured data we can use 3rd party libraries to parse out the data we need (assuming the spec evolves in a backwards compatible way).
What spec?
Whichever seccomp profile spec is being implemented by runtimes. E.g. if we decide to base the Kubernetes seccomp profile API off the OCI seccomp profile spec, and OCI adds some new features, at some point we'd probably want to add those features to Kubernetes.