k8s 检查 pod securityContext 定义

Question

我想检查集群中的 pod 是否运行为privileged pods，这可能表明我们可能存在安全问题，因此我检查是否 privileged: true

然而，在 securityContext:规范下还有其他字段，例如

• allowPrivilegeEscalation
• RunAsUser
• ProcMount
• Capabilities ETC

这可能有风险（不确定），

我的问题是，如果 Pod 被标记为，privileged:false并且其他字段都为 true，如下例所示，这是否表明存在某些安全问题？该 Pod 是否可以对其他 Pod等执行某些操作，访问外部数据？

例如，以下配置表明 pod 没有特权，但是allowPrivilegeEscalation: true

securityContext:
  allowPrivilegeEscalation: true
  privileged: false

我想知道哪个securityContextPod 配置组合可以控制集群中的其他 Pod ？ pods/process

Answer 1

它们securityContext更多地与容器本身以及对主机的一些访问相关。

允许allowPrivilegeEscalation进程获得比其父进程更多的权限。这与二进制文件中的 setuid/setgid 标志更相关，但在容器内没有什么可担心的。

hostPath如果您有卷或类似的东西，则只能从容器内部控制主机中的其他容器，从而允许您访问.sock文件/run/crio/crio.sock或docker.sock. 很明显，如果您担心这一点，则应禁用允许通过网络向 Docker API 发出请求。

当然，所有这些访问都受到 DAC 和 MAC 限制。这就是为什么 podman uidmap更好，因为容器内部的 root 与容器外部的 root id 不一样。

从 Kubernetes 的角度来看，你不需要这种权限，你所需要的只是一个ServiceAccount和正确的 RBAC 权限来控制 Kubernetes 内部的其他东西。ServiceAccount绑定到 a 的Acluster-admin ClusterRole可以在 API 中执行任何操作，甚至更多，例如向主机添加 ssh 密钥。

如果您担心 Pod 在 Kubernetes 或主机中执行操作，只需强制使用nonRoot容器，避免滥用hostPath卷，并控制 RBAC。

Openshift 默认使用一个非常好的限制：

• 确保 Pod 无法以特权运行
• 确保 pod 无法挂载主机目录卷
• 要求 pod 以预分配 UID 范围内的用户身份运行（openshift 功能、随机 uid）
• 要求 pod 使用预先分配的 MCS 标签运行（selinux 相关）

我没有准确回答你想要的，因为我将注意力转移到了 RBAC，但我希望这能给你一个好主意。