CRI-O：从OCI注册表应用seccomp配置
内容提要
Seccomp（安全计算模式）是Linux内核的特性，用于限制进程的系统调用。Kubernetes支持将seccomp配置应用于Pods，但分发这些配置存在挑战。CRI-O容器运行时通过注解支持seccomp配置，简化了管理，并提升了安全性和灵活性。
延伸解读
传统分发方式的痛点
在Kubernetes中，使用Localhost类型的seccomp配置要求JSON文件必须预先放置在每一个可能运行工作负载的节点上，默认路径为/var/lib/kubelet/seccomp/。如果文件缺失，容器创建会直接失败并报错。这种手动分发方式不仅繁琐，还容易导致用户为了省事而退回到RuntimeDefault甚至Unconfined，从而削弱安全隔离。
CRI-O注解的启用条件与优先级
CRI-O v1.30引入的seccomp-profile.kubernetes.cri-o.io注解并非默认生效，需要在运行时配置的allowed_annotations数组中显式添加。此外，该注解仅对以Unconfined模式运行的工作负载生效；如果Pod的securityContext中已指定seccompProfile，则securityContext的优先级更高，注解会被忽略。
OCI工件引用的实践要点
将seccomp配置作为OCI工件引用时，需要确保工件使用CRI-O期望的配置媒体类型application/vnd.cncf.seccomp-profile.config.v1+json。使用ORAS推送时，默认媒体类型不匹配，需通过--config参数指定。CRI-O会拉取工件并读取第一层中的seccomp.json文件，配置文件的名称不影响识别。
镜像注解与生命周期管理
除了Pod注解，还可以在构建容器镜像时通过Podman的--annotation参数添加seccomp-profile.kubernetes.cri-o.io注解，将配置与镜像本身关联。这样，使用该镜像的Pod无需额外注解即可自动应用配置。CRI-O内部将OCI工件作为普通文件管理，支持移动和删除未使用的配置，为未来多层seccomp配置等增强功能提供了基础。
Q&A
什么是seccomp，它的作用是什么？
Seccomp（安全计算模式）是Linux内核的特性，用于限制进程的系统调用，从而提高安全性。
Kubernetes如何应用seccomp配置？
Kubernetes允许将seccomp配置应用于Pods和容器，但分发这些配置存在挑战，因为JSON文件需在所有节点上可用。
CRI-O如何简化seccomp配置的管理？
CRI-O通过注解支持seccomp配置，允许用户为Pods和容器指定seccomp配置，从而简化管理并提升安全性。
如何将seccomp配置与容器镜像关联？
用户可以将seccomp配置作为OCI工件引用，并通过将其与容器镜像关联，在整个应用生命周期中灵活管理seccomp配置。
CRI-O v1.30版本引入了哪些新功能？
CRI-O v1.30版本引入了新的注解，允许用户为Pods和容器指定seccomp配置，提升了灵活性和安全性。
使用OCI工件的seccomp配置有什么优势？
使用OCI工件的seccomp配置可以简化配置的分发过程，并允许在多个节点上灵活管理seccomp配置。
