linux - k8s 检查 pod securityContext 定义

Question

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

但是根据securityContext:规范还有其他字段，例如

• allowPrivilegeEscalation
• 以用户身份运行
• ProcMount
• 功能等等

这可能有风险(不确定)，

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

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

securityContext:
  allowPrivilegeEscalation: true
  privileged: false

我想知道 pod 配置的哪个 securityContext 组合可以控制集群中的其他 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 内部的其他事情。绑定(bind)到 cluster-admin ClusterRole 的 ServiceAccount 可以在 API 中执行任何操作，甚至更多，例如向主机添加 ssh key 。

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

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

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

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