1. Pod Security Policy, PSP
Pod 安全策略是一种 Kubernetes 原生的安全功能,允许你控制 Pod 的安全配置。虽然 Kubernetes 1.21 后开始逐步弃用 PSP,但在老版本 Kubernetes 中仍然常用。可以使用 Pod 安全策略来限制哪些 Pod 可以以特权模式运行
1.1 Pod Security Policy 简介
Pod Security Policy 是一个赋予集群管理员控制 Pod 安全规范的内置准入控制器,可以让管理人员控制Pod实例安全的诸多方面,例如禁止采用root权限、防止容器逃逸等等。Pod Security Policy 定义了一组 Pod 运行时必须遵循的条件及相关字段的默认值,Pod 必须满足这些条件才能被成功创建,Pod Security Policy 对象 Spec 包含以下字段也即是 Pod Security Policy 能够控制的方面:
控制的角度 | 字段名称 |
---|---|
运行特权容器 | privileged |
使用宿主名字空间 | hostPID,hostIPC |
使用宿主的网络和端口 | hostNetwork, hostPorts |
控制卷类型的使用 | volumes |
使用宿主文件系统 | allowedHostPaths |
允许使用特定的 FlexVolume 驱动 | allowedFlexVolumes |
分配拥有 Pod 卷的 FSGroup 账号 | fsGroup |
以只读方式访问根文件系统 | readOnlyRootFilesystem |
设置容器的用户和组 ID | runAsUser, runAsGroup, supplementalGroups |
限制 root 账号特权级提升 | allowPrivilegeEscalation, defaultAllowPrivilegeEscalation |
Linux 功能(Capabilities) | defaultAddCapabilities, requiredDropCapabilities, allowedCapabilities |
设置容器的 SELinux 上下文 | seLinux |
指定容器可以挂载的 proc 类型 | allowedProcMountTypes |
指定容器使用的 AppArmor 模版 | annotations |
指定容器使用的 seccomp 模版 | annotations |
指定容器使用的 sysctl 模版 | forbiddenSysctls,allowedUnsafeSysctls |
其中AppArmor 和seccomp 需要通过给PodSecurityPolicy对象添加注解的方式设定:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
seccomp.security.alpha.kubernetes.io/defaultProfileNames: 'docker/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
apparmor.security.beta.kubernetes.io/defaultProfileNames: 'runtime/default'
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
seccomp.security.alpha.kubernetes.io/defaultProfileNames: 'docker/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
apparmor.security.beta.kubernetes.io/defaultProfileNames: 'runtime/default'
Pod Security Policy是集群级别的资源,我们看一下它的使用流程:
PodSecurityPolicy 在 Kubernetes v1.21 中被弃用, 在 Kubernetes v1.25 中被移除。
2. 为什么出现Pod Security Admission
通过对PodSecurityPolicy使用,应该也会发现它的问题,例如没有dry-run和审计模式、不方便开启和关闭等,并且使用起来也不那么清晰。种种缺陷造成的结果是PodSecurityPolicy在Kubernetes v1.21被标记为弃用,并且将在 v1.25中被移除,在kubernets v1.22中则增加了新特性Pod Security Admission。
2. Pod Security Admission介绍
pod security admission是kubernetes内置的一种准入控制器,在kubernetes v1.23版本中这一特性门是默认开启的,在v1.22中需要通过kube-apiserver参数 --feature-gates="...,PodSecurity=true"
开启。在低于v1.22的kuberntes版本中也可以自行安装Pod Security Admission Webhook。
pod security admission是通过执行内置的 Pod Security Standards来限制集群中的pod的创建。
3. Pod Security Standards
为了广泛的覆盖安全应用场景, Pod Security Standards渐进式的定义了三种不同的Pod安全标准策略:
Profile | 描述 |
---|---|
Privileged | 不受限制的策略,提供最大可能范围的权限许可。此策略允许已知的特权提升。 |
Baseline | 限制性最弱的策略,禁止已知的策略提升。允许使用默认的(规定最少)Pod 配置。 |
Restricted | 限制性非常强的策略,遵循当前的保护 Pod 的最佳实践。 |
详细内容参见Pod Security Standards。
3.1 Pod Security Standards实施方法
在kubernetes集群中开启了pod security admission特性门之后,就可以通过给namespace设置label的方式来实施Pod Security Standards。其中有三种设定模式可选用:
Mode | Description |
---|---|
enforce | 违反安全标准策略的 Pod 将被拒绝。 |
audit | 违反安全标准策略触发向审计日志中记录的事件添加审计注释,但其他行为被允许。 |
warn | 违反安全标准策略将触发面向用户的警告,但其他行为被允许。 |
label设置模板解释:
# 设定模式及安全标准策略等级
# MODE必须是 `enforce`, `audit`或`warn`其中之一。
# LEVEL必须是`privileged`, `baseline`或 `restricted`其中之一
pod-security.kubernetes.io/<MODE>: <LEVEL>
# 此选项是非必填的,用来锁定使用哪个版本的的安全标准
# MODE必须是 `enforce`, `audit`或`warn`其中之一。
# VERSION必须是一个有效的kubernetes minor version(例如v1.23),或者 `latest`
pod-security.kubernetes.io/<MODE>-version: <VERSION>
# 设定模式及安全标准策略等级
# MODE必须是 `enforce`, `audit`或`warn`其中之一。
# LEVEL必须是`privileged`, `baseline`或 `restricted`其中之一
pod-security.kubernetes.io/<MODE>: <LEVEL>
# 此选项是非必填的,用来锁定使用哪个版本的的安全标准
# MODE必须是 `enforce`, `audit`或`warn`其中之一。
# VERSION必须是一个有效的kubernetes minor version(例如v1.23),或者 `latest`
pod-security.kubernetes.io/<MODE>-version: <VERSION>