Pod 安全策略
Pod 安全策略 是集群级别的资源,它能够控制 Pod 运行的行为,以及它具有访问什么的能力。 PodSecurityPolicy
对象定义了一组条件,指示 Pod 必须按系统所能接受的顺序运行。 它们允许管理员控制如下方面:
Pod 安全策略 由设置和策略组成,它们能够控制 Pod 访问的安全特征。这些设置分为如下三类:
- 基于布尔值控制 :这种类型的字段默认为最严格限制的值。
- 基于被允许的值集合控制 :这种类型的字段会与这组值进行对比,以确认值被允许。
- 基于策略控制 :设置项通过一种策略提供的机制来生成该值,这种机制能够确保指定的值落在被允许的这组值中。
- MustRunAs - 必须配置一个
range
。使用该范围内的第一个值作为默认值。验证是否不在配置的该范围内。 - MustRunAsNonRoot - 要求提交的 Pod 具有非零
runAsUser
值,或在镜像中定义了USER
环境变量。不提供默认值。 - RunAsAny - 没有提供默认值。允许指定任何
runAsUser
。
SELinux
- MustRunAs - 如果没有使用预分配的值,必须配置
seLinuxOptions
。默认使用seLinuxOptions
。验证seLinuxOptions
。 - RunAsAny - 没有提供默认值。允许任意指定的
seLinuxOptions
ID。
- MustRunAs - 至少需要指定一个范围。默认使用第一个范围的最小值。验证所有范围的值。
- RunAsAny - 没有提供默认值。允许任意指定的 ID。
FSGroup
- MustRunAs - 至少需要指定一个范围。默认使用第一个范围的最小值。验证在第一个范围内的第一个 ID。
- RunAsAny - 没有提供默认值。允许任意指定的
fsGroup
ID。
通过设置 PSP 卷字段,能够控制具体卷类型的使用。当创建一个卷的时候,与该字段相关的已定义卷可以允许设置如下值:
- azureFile
- azureDisk
- flocker
- flexVolume
- hostPath
- emptyDir
- awsElasticBlockStore
- gitRepo
- secret
- nfs
- iscsi
- glusterfs
- persistentVolumeClaim
- rbd
- cinder
- cephFS
- downwardAPI
- fc
- configMap
- vsphereVolume
- quobyte
- projected
- portworxVolume
- scaleIO
- storageos
- * (allow all volumes)
对新的 PSP,推荐允许的卷的最小集合包括:configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret 和 projected。
主机网络
- HostPorts , 默认为
empty
。HostPortRange
列表通过min
(包含) andmax
(包含) 来定义,指定了被允许的主机端口。
- AllowedHostPaths 是一个被允许的主机路径前缀的白名单。空值表示所有的主机路径都可以使用。
许可
包含 PodSecurityPolicy
的 _许可控制_,允许控制集群资源的创建和修改,基于这些资源在集群范围内被许可的能力。
如果某个策略能够匹配上,该 Pod 就被接受。如果请求与 PSP 不匹配,则 Pod 被拒绝。
Pod 必须基于 PSP 验证每个字段。
创建一个策略和一个 Pod
在一个文件中定义 PodSecurityPolicy 对象实例。这里的策略只是用来禁止创建有特权 要求的 Pods。
policy/example-psp.yaml |
---|
使用 kubectl 执行创建操作:
获取已存在策略列表,使用 kubectl get
:
修改 Pod 安全策略
该命令将打开一个默认文本编辑器,在这里能够修改策略。
一旦不再需要一个策略,很容易通过 kubectl
删除它:
启用 Pod 安全策略
为了能够在集群中使用 Pod 安全策略,必须确保满足如下条件:
- 已经启用 API 类型
extensions/v1beta1/podsecuritypolicy
(仅对 1.6 之前的版本) - 已经启用许可控制器
PodSecurityPolicy
在 Kubernetes 1.5 或更新版本,可以使用 PodSecurityPolicy 来控制,对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象,可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod,限制访问 PodSecurityPolicy 对象, 必须基于安全 API 端口运行,并且不能够具有超级用户权限。
PodSecurityPolicy 认证使用所有可用的策略,包括创建 Pod 的用户,Pod 上指定的服务账户(Service Account)。当 Pod 基于 Deployment、ReplicaSet 创建时,它是创建 Pod 的 Controller Manager,所以如果基于非安全 API 端口运行,允许所有的 PodSecurityPolicy 对象,并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效,仅当是直接部署 Pod 的情况。更多详情,查看 PodSecurityPolicy RBAC 示例,当直接部署 Pod 时,应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。