Seccomp 和 Kubernetes
Seccomp 表示安全计算（Secure Computing）模式，自 2.6.12 版本以来，一直是 Linux 内核的一个特性。 它可以用来沙箱化进程的权限，限制进程从用户态到内核态的调用。 Kubernetes 能使你自动将加载到节点上的 seccomp 配置文件应用到你的 Pod 和容器。
Seccomp 字段
Kubernetes v1.19 [stable]有四种方式可以为 Pod 指定 seccomp 配置文件：
- 为整个 Pod 使用
spec.securityContext.seccompProfile - 为单个容器使用
spec.containers[*].securityContext.seccompProfile - 为（可重启/边车）Init 容器使用
spec.initContainers[*].securityContext.seccompProfile - 为临时容器使用
spec.ephemeralContainers[*].securityContext.seccompProfile
apiVersion: v1
kind: Pod
metadata:
name: pod
spec:
securityContext:
seccompProfile:
type: Unconfined
ephemeralContainers:
- name: ephemeral-container
image: debian
securityContext:
seccompProfile:
type: RuntimeDefault
initContainers:
- name: init-container
image: debian
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: container
image: docker.io/library/debian:stable
securityContext:
seccompProfile:
type: Localhost
localhostProfile: my-profile.json
上面的示例中的 Pod 以 Unconfined 运行，而 ephemeral-container 和
init-container 独立设置了 RuntimeDefault。
如果临时容器或 Init 容器没有明确设置 securityContext.seccompProfile 字段，
则此值将从 Pod 继承。同样的机制也适用于运行 Localhost 配置文件 my-profile.json 的容器。
一般来说，（临时）容器的字段优先级高于 Pod 层级的值，而未设置 seccomp 字段的容器则从 Pod 继承配置。
说明：
你不可以将 seccomp 配置文件应用到在容器的 securityContext 中设置了 privileged: true 的
Pod 或容器。特权容器始终以 Unconfined 运行。
对于 seccompProfile.type，可以使用以下值：
Unconfined- 工作负载在没有任何 seccomp 限制的情况下运行。
RuntimeDefault- 由容器运行时定义的默认 seccomp 配置文件被应用。这个默认的配置文件旨在提供一套强大的安全默认值，同时保持工作负载的功能不受影响。 不同的容器运行时及其版本之间的默认配置文件可能会有所不同， 例如在比较 CRI-O 和 containerd 的默认配置文件时就会发现不同。
LocalhostlocalhostProfile将被应用，这一配置必须位于节点磁盘上（在 Linux 上是/var/lib/kubelet/seccomp）。 在创建容器时，容器运行时会验证 seccomp 配置文件的可用性。如果此配置文件不存在，则容器创建将失败，并报错CreateContainerError。
Localhost 配置文件
Seccomp 配置文件是遵循 OCI 运行时规范定义的 JSON 文件。配置文件主要根据所匹配的系统调用来定义操作，但也允许将特定值作为参数传递给系统调用。例如：
{
"defaultAction": "SCMP_ACT_ERRNO",
"defaultErrnoRet": 38,
"syscalls": [
{
"names": [
"adjtimex",
"alarm",
"bind",
"waitid",
"waitpid",
"write",
"writev"
],
"action": "SCMP_ACT_ALLOW"
}
]
}
上述配置文件中的 defaultAction 被定义为 SCMP_ACT_ERRNO，并可回退至 syscalls 中所定义的操作。
此错误通过 defaultErrnoRet 字段被定义为代码 38。
通常可以使用以下操作：
SCMP_ACT_ERRNO- 返回指定的错误码。
SCMP_ACT_ALLOW- 允许执行系统调用。
SCMP_ACT_KILL_PROCESS- 杀死进程。
SCMP_ACT_KILL_THREAD和SCMP_ACT_KILL- 仅杀死线程。
SCMP_ACT_TRAP- 发送
SIGSYS信号。 SCMP_ACT_NOTIFY和SECCOMP_RET_USER_NOTIF- 通知用户空间。
SCMP_ACT_TRACE- 使用指定的值通知跟踪进程。
SCMP_ACT_LOG- 在将操作记录到 syslog 或 auditd 之后，允许执行系统调用。
SCMP_ACT_NOTIFY 或 SECCOMP_RET_USER_NOTIF 这类操作可能不被支持，
具体取决于所使用的容器运行时、OCI 运行时或 Linux 内核版本。也可能存在其他限制，
例如 SCMP_ACT_NOTIFY 不能用作 defaultAction 或用于某些系统调用（如 write）。
所有这些限制由 OCI 运行时
（runc、crun）
或 libseccomp 所定义。
syscalls JSON 数组包含对象列表，每个对象通过系统调用的 names 引用系统调用。
例如，SCMP_ACT_ALLOW 操作可用于创建包含如上例所示的系统调用的白名单。
也可以使用 SCMP_ACT_ERRNO 操作定义另一个列表，但会有不同的返回值（errnoRet）。
你还可以指定传递给某些系统调用的参数（args）。有关这些高级用例的细节，请参见
OCI 运行时规范
和 Seccomp Linux 内核文档。