我目前正在研究是否能够通过RBAC防止Kubernetes用户创建特权容器。 我知道从Kubernetes 1.1开始,默认启用特权容器以支持底层Docker需求。 这很好,我不想阻止每个人运行特权容器。
然而,我希望遵循最小特权原则。例如,我想通过RBAC防止用户能够使用类似kubectl node-shell的东西来获取对工作节点的root访问权限。
这可行吗?
我目前正在研究是否能够通过RBAC防止Kubernetes用户创建特权容器。 我知道从Kubernetes 1.1开始,默认启用特权容器以支持底层Docker需求。 这很好,我不想阻止每个人运行特权容器。
然而,我希望遵循最小特权原则。例如,我想通过RBAC防止用户能够使用类似kubectl node-shell的东西来获取对工作节点的root访问权限。
这可行吗?
Kubernetes 文档提供了一些关于如何与 PSP 交互的示例,尽管必须声明一个重要的警告:必须在 API 服务器上激活 PodSecurityPolicy 准入控制器。决定了 Pod 中任何容器是否可以启用特权模式。默认情况下,容器不允许访问主机上的任何设备,但是“特权”容器被赋予访问主机上所有设备的权限。这使得容器几乎具有与在主机上运行的进程相同的访问权限。这对于希望使用 Linux 能力如操作网络堆栈和访问设备的容器非常有用。
一旦在您的集群上启用了 PodSecurityPolicies,标准 建议创建3个级别的策略:
截至1.23版本,正确的做法是使用由Pod安全性准则执行的Pod安全性准入控制器。自1.23版本以来,默认情况下已包含该控制器。K8s在1.25中删除了Pod安全策略(PSP),而PSP在1.23中已被弃用。
K8s带有3个预定义的Pod安全标准:特权、基线和受限。强制执行基线和受限标准都可以防止特权pod。但是,受限可能对您的pod过于严格,因此建议从基线标准开始。
将Pod安全标准强制应用于命名空间存在阻止新Pod部署到该命名空间的风险。因此,我们首先进行干运行,而不是直接强制执行基线。
运行干运行并检查是否会抛出任何警告:
kubectl label --dry-run=server --overwrite ns default \
pod-security.kubernetes.io/enforce=baseline
如果您看到没有任何警告标记的命名空间/默认值,则意味着如果强制执行基线,则命名空间默认中所有当前运行的 Pod 都将被允许。
假设您没有收到任何警告。让我们从在默认命名空间上强制执行基线标准开始:
kubectl label --overwrite ns default \
pod-security.kubernetes.io/enforce=baseline
apiVersion: v1
kind: Pod
metadata:
name: nginx-priv
spec:
containers:
- name: nginx-priv
image: nginx:1.14.2
ports:
- containerPort: 80
securityContext:
privileged: true
kubectl apply -f nginx-priv.yaml
Error from server (Forbidden): error when creating "nginx-priv.yaml": pods "nginx-priv" is forbidden: violates PodSecurity "baseline:latest": privileged (container "nginx-priv" must not set securityContext.privileged=true)
请注意,您也可以像这样在所有命名空间中强制实施基线(在部署新的 Pod 时可能会导致问题):
kubectl label --overwrite ns --all \
pod-security.kubernetes.io/enforce=baseline
免责声明:本文作者为以下原始内容的作者
原始内容:https://samos-it.com/posts/Preventing-Privileged-pods-using-Pod-Security-Admission-Standards.html