本文已发表一年以上。较早的文章可能包含过时内容。请检查页面信息自发布以来是否已失效。
CRI-O：从 OCI 注册表应用 seccomp 配置
Seccomp 代表安全计算模式（secure computing mode），自 Linux 内核 2.6.12 版本以来一直是其特性之一。它可以用于沙箱化进程的权限，限制其从用户空间到内核的系统调用。Kubernetes 允许你将加载到节点上的 seccomp profiles 自动应用到你的 Pods 和容器。
但分发这些 seccomp profiles 在 Kubernetes 中是一个重大挑战，因为 JSON 文件必须在所有可能运行工作负载的节点上都可用。Security Profiles Operator 等项目通过在集群内作为守护进程运行来解决这个问题，这让我思考这种分发机制的哪个部分可以由容器运行时来完成。
运行时通常会从本地路径应用 profiles，例如
apiVersion: v1
kind: Pod
metadata:
name: pod
spec:
containers:
- name: container
image: nginx:1.25.3
securityContext:
seccompProfile:
type: Localhost
localhostProfile: nginx-1.25.3.json
`nginx-1.25.3.json` 这个 profile 必须在 kubelet 的根目录下可用，并附加到 `seccomp` 目录。这意味着 profile 在磁盘上的默认位置将是 `/var/lib/kubelet/seccomp/nginx-1.25.3.json`。如果 profile 不可用，则运行时将在容器创建时失败，如下所示
kubectl get pods
NAME READY STATUS RESTARTS AGE
pod 0/1 CreateContainerError 0 38s
kubectl describe pod/pod | tail
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 117s default-scheduler Successfully assigned default/pod to 127.0.0.1
Normal Pulling 117s kubelet Pulling image "nginx:1.25.3"
Normal Pulled 111s kubelet Successfully pulled image "nginx:1.25.3" in 5.948s (5.948s including waiting)
Warning Failed 7s (x10 over 111s) kubelet Error: setup seccomp: unable to load local profile "/var/lib/kubelet/seccomp/nginx-1.25.3.json": open /var/lib/kubelet/seccomp/nginx-1.25.3.json: no such file or directory
Normal Pulled 7s (x9 over 111s) kubelet Container image "nginx:1.25.3" already present on machine
必须手动分发 `Localhost` profiles 的主要障碍将导致许多最终用户退回到 `RuntimeDefault`，甚至将他们的工作负载运行为 `Unconfined` (禁用 seccomp)。
CRI-O 来救援
Kubernetes 容器运行时 CRI-O 提供各种使用自定义注解（annotations）的功能。v1.30 版本添加了对一组新注解的支持，名为 `seccomp-profile.kubernetes.cri-o.io/POD` 和 `seccomp-profile.kubernetes.cri-o.io/<CONTAINER>`。这些注解允许你指定
- 使用 `seccomp-profile.kubernetes.cri-o.io/<CONTAINER>` 时，为特定容器指定 seccomp profile（示例：`seccomp-profile.kubernetes.cri-o.io/webserver: 'registry.example/example/webserver:v1'`）
- 不带容器名称后缀但使用保留名称 `POD` 时，为 pod 中的每个容器指定 seccomp profile：`seccomp-profile.kubernetes.cri-o.io/POD`
- 如果镜像本身包含注解 `seccomp-profile.kubernetes.cri-o.io/POD` 或 `seccomp-profile.kubernetes.cri-o.io/<CONTAINER>`，则为整个容器镜像指定 seccomp profile。
CRI-O 仅在运行时被配置为允许该注解时，以及对于作为 `Unconfined` 运行的工作负载，才会遵从该注解。所有其他工作负载仍将使用具有更高优先级的 `securityContext` 中的值。
仅靠注解并不能很好地解决 profiles 的分发问题，但它们可以被引用的方式将会有所帮助！例如，现在你可以像引用常规容器镜像一样指定 seccomp profiles，通过使用 OCI artifacts
apiVersion: v1
kind: Pod
metadata:
name: pod
annotations:
seccomp-profile.kubernetes.cri-o.io/POD: quay.io/crio/seccomp:v2
spec: …
镜像 `quay.io/crio/seccomp:v2` 包含一个 `seccomp.json` 文件，该文件包含实际的 profile 内容。可以使用 ORAS 或 Skopeo 等工具检查镜像的内容
oras pull quay.io/crio/seccomp:v2
Downloading 92d8ebfa89aa seccomp.json
Downloaded 92d8ebfa89aa seccomp.json
Pulled [registry] quay.io/crio/seccomp:v2
Digest: sha256:f0205dac8a24394d9ddf4e48c7ac201ca7dcfea4c554f7ca27777a7f8c43ec1b
jq . seccomp.json | head
{
"defaultAction": "SCMP_ACT_ERRNO",
"defaultErrnoRet": 38,
"defaultErrno": "ENOSYS",
"archMap": [
{
"architecture": "SCMP_ARCH_X86_64",
"subArchitectures": [
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
# Inspect the plain manifest of the image
skopeo inspect --raw docker://quay.io/crio/seccomp:v2 | jq .
{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"config":
{
"mediaType": "application/vnd.cncf.seccomp-profile.config.v1+json",
"digest": "sha256:ca3d163bab055381827226140568f3bef7eaac187cebd76878e0b63e9e442356",
"size": 3,
},
"layers":
[
{
"mediaType": "application/vnd.oci.image.layer.v1.tar",
"digest": "sha256:92d8ebfa89aa6dd752c6443c27e412df1b568d62b4af129494d7364802b2d476",
"size": 18853,
"annotations": { "org.opencontainers.image.title": "seccomp.json" },
},
],
"annotations": { "org.opencontainers.image.created": "2024-02-26T09:03:30Z" },
}
镜像清单包含对特定所需配置媒体类型（`application/vnd.cncf.seccomp-profile.config.v1+json`）的引用，以及一个指向 `seccomp.json` 文件的单个层（`application/vnd.oci.image.layer.v1.tar`）。现在，让我们来尝试一下这个新特性！
为特定容器或整个 Pod 使用注解
在使用注解之前，需要对 CRI-O 进行适当配置。为此，将注解添加到运行时的 `allowed_annotations` 数组中。可以通过使用如下所示的 drop-in 配置 `/etc/crio/crio.conf.d/10-crun.conf` 来完成
[crio.runtime]
default_runtime = "crun"
[crio.runtime.runtimes.crun]
allowed_annotations = [
"seccomp-profile.kubernetes.cri-o.io",
]
现在，让我们从最新的 `main` commit 运行 CRI-O。这可以通过从源代码构建、使用静态二进制包或预发布包来完成。
为了演示这一点，我在命令行中使用 `local-up-cluster.sh` 启动了一个单节点 Kubernetes 集群并运行了 `crio` 二进制文件。现在集群已启动并运行，让我们尝试一个未带有注解、以 seccomp `Unconfined` 运行的 Pod
cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod
spec:
containers:
- name: container
image: nginx:1.25.3
securityContext:
seccompProfile:
type: Unconfined
kubectl apply -f pod.yaml
工作负载已启动并运行
kubectl get pods
NAME READY STATUS RESTARTS AGE
pod 1/1 Running 0 15s
如果我使用 `crictl` 检查容器，发现没有应用 seccomp profile
export CONTAINER_ID=$(sudo crictl ps --name container -q)
sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp
null
现在，让我们修改 Pod，将 `quay.io/crio/seccomp:v2` profile 应用到容器
apiVersion: v1
kind: Pod
metadata:
name: pod
annotations:
seccomp-profile.kubernetes.cri-o.io/container: quay.io/crio/seccomp:v2
spec:
containers:
- name: container
image: nginx:1.25.3
我必须删除并重新创建 Pod，因为只有重新创建才会应用新的 seccomp profile
kubectl delete pod/pod
pod "pod" deleted
kubectl apply -f pod.yaml
pod/pod created
CRI-O 日志现在将表明运行时已拉取了 artifact
WARN[…] Allowed annotations are specified for workload [seccomp-profile.kubernetes.cri-o.io]
INFO[…] Found container specific seccomp profile annotation: seccomp-profile.kubernetes.cri-o.io/container=quay.io/crio/seccomp:v2 id=26ddcbe6-6efe-414a-88fd-b1ca91979e93 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Pulling OCI artifact from ref: quay.io/crio/seccomp:v2 id=26ddcbe6-6efe-414a-88fd-b1ca91979e93 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Retrieved OCI artifact seccomp profile of len: 18853 id=26ddcbe6-6efe-414a-88fd-b1ca91979e93 name=/runtime.v1.RuntimeService/CreateContainer
容器最终正在使用该 profile
export CONTAINER_ID=$(sudo crictl ps --name container -q)
sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp | head
{
"defaultAction": "SCMP_ACT_ERRNO",
"defaultErrnoRet": 38,
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
同样的方法也适用于 Pod 中的每个容器，如果用户将 `/container` 后缀替换为保留名称 `/POD`，例如
apiVersion: v1
kind: Pod
metadata:
name: pod
annotations:
seccomp-profile.kubernetes.cri-o.io/POD: quay.io/crio/seccomp:v2
spec:
containers:
- name: container
image: nginx:1.25.3
为容器镜像使用注解
虽然将 seccomp profiles 指定为特定工作负载上的 OCI artifacts 是一个很酷的功能，但大多数最终用户希望将 seccomp profiles 链接到已发布的容器镜像。这可以通过使用容器镜像注解来完成；该注解不是应用于 Kubernetes Pod，而是应用于容器镜像本身的一些元数据。例如，可以使用 Podman 在镜像构建期间直接添加镜像注解
podman build \
--annotation seccomp-profile.kubernetes.cri-o.io=quay.io/crio/seccomp:v2 \
-t quay.io/crio/nginx-seccomp:v2 .
推送的镜像随后包含该注解
skopeo inspect --raw docker://quay.io/crio/nginx-seccomp:v2 |
jq '.annotations."seccomp-profile.kubernetes.cri-o.io"'
"quay.io/crio/seccomp:v2"
如果我随后在 CRI-O 测试 Pod 定义中使用该镜像
apiVersion: v1
kind: Pod
metadata:
name: pod
# no Pod annotations set
spec:
containers:
- name: container
image: quay.io/crio/nginx-seccomp:v2
那么 CRI-O 日志将表明镜像注解已被评估并且 profile 已被应用
kubectl delete pod/pod
pod "pod" deleted
kubectl apply -f pod.yaml
pod/pod created
INFO[…] Found image specific seccomp profile annotation: seccomp-profile.kubernetes.cri-o.io=quay.io/crio/seccomp:v2 id=c1f22c59-e30e-4046-931d-a0c0fdc2c8b7 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Pulling OCI artifact from ref: quay.io/crio/seccomp:v2 id=c1f22c59-e30e-4046-931d-a0c0fdc2c8b7 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Retrieved OCI artifact seccomp profile of len: 18853 id=c1f22c59-e30e-4046-931d-a0c0fdc2c8b7 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Created container 116a316cd9a11fe861dd04c43b94f45046d1ff37e2ed05a4e4194fcaab29ee63: default/pod/container id=c1f22c59-e30e-4046-931d-a0c0fdc2c8b7 name=/runtime.v1.RuntimeService/CreateContainer
export CONTAINER_ID=$(sudo crictl ps --name container -q)
sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp | head
{
"defaultAction": "SCMP_ACT_ERRNO",
"defaultErrnoRet": 38,
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
对于容器镜像，注解 `seccomp-profile.kubernetes.cri-o.io` 将被视为与 `seccomp-profile.kubernetes.cri-o.io/POD` 相同，并应用于整个 Pod。此外，当在镜像上使用容器特定注解时，整个功能也有效，例如，如果一个容器被命名为 `container1`
skopeo inspect --raw docker://quay.io/crio/nginx-seccomp:v2-container |
jq '.annotations."seccomp-profile.kubernetes.cri-o.io/container1"'
"quay.io/crio/seccomp:v2"
这项功能的酷之处在于，用户现在可以为特定的容器镜像创建 seccomp profiles，并将它们存储在同一个仓库中。将镜像链接到 profiles 提供了一个很大的灵活性，可以在应用程序的整个生命周期中维护它们。
使用 ORAS 推送 profiles
使用 ORAS 创建包含 seccomp profile 的 OCI 对象需要更多工作。我希望将来像 Podman 这样的工具能够简化整个过程。目前，容器仓库需要兼容 OCI artifacts，Quay.io 就是如此。CRI-O 希望 seccomp profile 对象具有容器镜像媒体类型（`application/vnd.cncf.seccomp-profile.config.v1+json`），而 ORAS 默认使用 `application/vnd.oci.empty.v1+json`。为了实现这一切，可以执行以下命令
echo "{}" > config.json
oras push \
--config config.json:application/vnd.cncf.seccomp-profile.config.v1+json \
quay.io/crio/seccomp:v2 seccomp.json
生成的镜像包含 CRI-O 期望的 `mediaType`。ORAS 将一个单独的层 `seccomp.json` 推送到仓库。profile 的名称并不重要。CRI-O 将选择第一个层并检查它是否可以作为 seccomp profile。
未来的工作
CRI-O 在内部像常规文件一样管理 OCI artifacts。这提供了移动它们、在不再使用时删除它们或拥有除 seccomp profiles 之外的任何其他数据的优势。这使得 CRI-O 未来可以在 OCI artifacts 之上进行增强，同时也允许考虑将 seccomp profiles 作为 OCI artifact 中包含多个层的一部分进行堆叠。v1.30.x 版本中仅对 `Unconfined` 工作负载有效这一限制是 CRI-O 未来希望解决的问题。通过不牺牲安全性来简化整体用户体验似乎是 seccomp 在容器工作负载中成功未来的关键。
CRI-O 维护者很高兴听到关于新功能的任何反馈或建议！感谢阅读这篇博客文章，请随时通过 Kubernetes Slack channel #crio 联系维护者，或在 GitHub 仓库中创建 issue。