【云原生 | Kubernetes 系列】K8s 实战 一文学会如何从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器
PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器
- 前言
- 一、Pod 安全性
- 二、访问权限
- 三、标准化 PodSecurityPolicy
-
- 3.1、去掉纯粹变更性质的字段
- 3.2、去掉 Pod 安全性标准未涉及的选项
- 3.3、推出更新的 PSP
- 四、空间更新
-
- 4.1、选择 Pod 安全级别
- 4.2、检查 Pod 安全性级别
- 4.3、实施 Pod 安全性级别
- 4.4、绕过 PodSecurityPolicy
- 五、禁用 PodSecurityPolicy
- 总结
前言
本篇文章我们将学习，如何从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器的过程。
这一迁移过程可以通过综合使用试运行、audit 和 warn 模式等来实现， 尽管在使用了变更式 PSP 时会变得有些困难。
我们可以采用多种方法来完成从 PodSecurityPolicy 到 Pod 安全性准入 （Pod Security Admission）的迁移。 下面是一种可能的迁移方法，其目标是尽可能降低生产环境不可用的风险， 以及安全性仍然不足的风险。
- 确定 Pod 安全性准入是否对于你的使用场景而言比较合适。
- 审查名字空间访问权限。
- 简化、标准化 PodSecurityPolicy。
- 更新名字空间：
-
- 确定合适的 Pod 安全性级别；
-
- 验证该 Pod 安全性级别可工作；
-
- 实施该 Pod 安全性级别；
-
- 绕过 PodSecurityPolicy。
- 审阅名字空间创建过程。
- 禁用 PodSecurityPolicy。
一、Pod 安全性
Pod 安全性准入被设计用来直接满足最常见的安全性需求，并提供一组可用于多个集群的安全性级别。 不过，这一机制比 PodSecurityPolicy 的灵活度要低。 值得注意的是，PodSecurityPolicy 所支持的以下特性是 Pod 安全性准入所不支持的：
- 设置默认的安全性约束 - Pod 安全性准入是一个非变更性质的准入控制器， 这就意味着它不会在对 Pod 进行合法性检查之前更改其配置。如果你之前依赖于 PSP 的这方面能力， 你或者需要更改你的负载以满足 Pod 安全性约束，或者需要使用一个 变更性质的准入 Webhook 来执行相应的变更。进一步的细节可参见后文的简化和标准化 PodSecurityPolicy。
- 对策略定义的细粒度控制 - Pod 安全性准入仅支持 三种标准级别。 如果你需要对特定的约束施加更多的控制，你就需要使用一个 验证性质的准入 Webhook 以实施这列策略。
- 粒度小于名字空间的策略 - PodSecurityPolicy 允许你为不同的服务账户或用户绑定不同策略， 即使这些服务账户或用户隶属于同一个名字空间。这一方法有很多缺陷，不建议使用。 不过如果你的确需要这种功能，你就需要使用第三方的 Webhook。 唯一的例外是当你只需要完全针对某用户或者 RuntimeClasses 赋予豁免规则时， Pod 安全性准入的确也为豁免规则暴露一些 静态配置。
即便 Pod 安全性准入无法满足你的所有需求，该机制也是设计用作其他策略实施机制的 补充，因此可以和其他准入 Webhook 一起运行，进而提供一种有用的兜底机制。
二、访问权限
Pod 安全性准入是通过名字空间上的标签 来控制的。这也就是说，任何能够更新（或通过 patch 部分更新或创建） 名字空间的人都可以更改该名字空间的 Pod 安全性级别，而这可能会被利用来绕过约束性更强的策略。 在继续执行迁移操作之前，请确保只有被信任的、有特权的用户具有这类名字空间访问权限。 不建议将这类强大的访问权限授予不应获得权限提升的用户，不过如果你必须这样做， 你需要使用一个 准入 Webhook 来针对为 Namespace 对象设置 Pod 安全性级别设置额外的约束。
三、标准化 PodSecurityPolicy
本篇文章中，我们会削减变更性质的 PodSecurityPolicy，去掉 Pod 安全性标准范畴之外的选项。 针对要修改的、已存在的 PodSecurityPolicy，你应该将这里所建议的更改写入到其离线副本中。 所克隆的 PSP 应该与原来的副本名字不同，并且按字母序要排到原副本之前 （例如，可以向 PSP 名字前加一个 0）。 先不要在 Kubernetes 中创建新的策略 - 这类操作会在后文的推出更新的策略 部分讨论。
3.1、去掉纯粹变更性质的字段
如果某个 PodSecurityPolicy 能够变更字段，可能会在关掉 PodSecurityPolicy 时发现有些 Pod 无法满足 Pod 安全性级别。为避免这类状况， 我们应该在执行切换操作之前去掉所有 PSP 的变更操作。 PSP 没有对变更性和验证性字段做清晰的区分，所以这一迁移操作也不够简单直接。
我们可以先去掉那些纯粹变更性质的字段，留下验证策略中的其他内容。 这些字段（也列举于将 PodSecurityPolicy 映射到 Pod 安全性标准参考中） 包括：
- .spec.defaultAllowPrivilegeEscalation
- .spec.runtimeClass.defaultRuntimeClassName
- .metadata.annotations[‘seccomp.security.alpha.kubernetes.io/defaultProfileName’]
- .metadata.annotations[‘apparmor.security.beta.kubernetes.io/defaultProfileName’]
- .spec.defaultAddCapabilities - 尽管理论上是一个混合了变更性与验证性功能的字段， 这里的设置应该被合并到 .spec.allowedCapabilities 中，后者会执行相同的验证操作， 但不会执行任何变更动作。
3.2、去掉 Pod 安全性标准未涉及的选项
PodSecurityPolicy 中有一些字段未被 Pod 安全性准入机制覆盖。如果你必须使用这些选项， 需要在 Pod 安全性准入之外部署 准入 Webhook 补充这一能力，而这类操作不在本指南范围。
首先，可以去掉 Pod 安全性标准所未覆盖的那些验证性字段。这些字段（也列举于 将 PodSecurityPolicy 映射到 Pod 安全性标准参考中，标记为“无意见”）有：
- .spec.allowedHostPaths
- .spec.allowedFlexVolumes
- .spec.allowedCSIDrivers
- .spec.forbiddenSysctls
- .spec.runtimeClass
当然，也可以去掉以下字段，这些字段与 POSIX/UNIX 用户组控制有关。
- .spec.runAsGroup
- .spec.supplementalGroups
- .spec.fsGroup
剩下的变更性字段是为了适当支持 Pod 安全性标准所需要的，因而需要逐个处理：
- .spec.requiredDropCapabilities - 需要此字段来为 Restricted 配置去掉 ALL 设置。
- .spec.seLinux - （仅针对带有 MustRunAs 规则的变更性设置）需要此字段来满足 Baseline 和 Restricted 配置所需要的 SELinux 需求。
- .spec.runAsUser - （仅针对带有 RunAsAny 规则的非变更性设置）需要此字段来为 Restricted 配置保证 RunAsNonRoot。
- .spec.allowPrivilegeEscalation - （如果设置为 false 则为变更性设置） 需要此字段来支持 Restricted 配置。
3.3、推出更新的 PSP
接下来，我们将更新后的策略推出到集群上。这这里需要说明的是，因为去掉变更性质的选项可能导致有些工作负载缺少必需的配置。
针对更新后的每个 PodSecurityPolicy：
- 识别运行于原 PSP 之下的 Pod。可以通过
kubernetes.io/psp注解来完成。 例如，使用 kubectl：
PSP_NAME="original" # 设置你要检查的 PSP 的名称
kubectl get pods --all-namespaces -o jsonpath="{range .items[?(@.metadata.annotations.kubernetes\.io\/psp=='$PSP_NAME')]}{.metadata.namespace} {.metadata.name}{'\n'}{end}"
- 比较运行中的 Pod 与原来的 Pod 规约，确定 PodSecurityPolicy 是否更改过这些 Pod。 对于通过工作负载资源所创建的 Pod， 你可以比较 Pod 和控制器资源中的 PodTemplate。如果发现任何变更，则原来的 Pod 或者 PodTemplate 需要被更新以加上所希望的配置。要审查的字段包括：
-
- .metadata.annotations[‘container.apparmor.security.beta.kubernetes.io/*’] （将 * 替换为每个容器的名称）
-
- .spec.runtimeClassName
-
- .spec.securityContext.fsGroup
-
- .spec.securityContext.seccompProfile
-
- .spec.securityContext.seLinuxOptions
-
- .spec.securityContext.supplementalGroups
-
- 对于容器，在 .spec.containers[] 和 .spec.initContainers[] 之下，检查下面字段：
-
- .securityContext.allowPrivilegeEscalation
-
- .securityContext.capabilities.add
-
- .securityContext.capabilities.drop
-
- .securityContext.readOnlyRootFilesystem
-
- .securityContext.runAsGroup
-
- .securityContext.runAsNonRoot
-
- .securityContext.runAsUser
-
- .securityContext.seccompProfile
-
- .securityContext.seLinuxOptions
- 创建新的 PodSecurityPolicy。如果存在 Role 或 ClusterRole 对象为用户授权了在所有 PSP 上使用 use 动词的权限，则所使用的的会是新创建的 PSP 而不是其变更性的副本。
- 更新你的鉴权配置，为访问新的 PSP 授权。在 RBAC 机制下，这意味着需要更新所有为原 PSP 授予 use 访问权限的 Role 或 ClusterRole 对象，使之也对更新后的 PSP 授权。
- 验证：经过一段时间后，重新执行步骤 1 中所给的命令，查看是否有 Pod 仍在使用原来的 PSP。 注意，在新的策略被推出到集群之后，Pod 需要被重新创建才可以执行全面验证。
- （可选）一旦你已经验证原来的 PSP 不再被使用，你就可以删除这些 PSP。
四、空间更新
这里需要我们在集群中的所有名字空间上执行。所列步骤中的命令使用变量 $NAMESPACE 来引用所更新的名字空间。
4.1、选择 Pod 安全级别
为你的名字空间选择 Pod 安全性级别有几种方法：
- 根据名字空间的安全性需求来确定 - 如果你熟悉某名字空间的预期访问级别， 你可以根据这类需求来选择合适的安全级别，就像大家在为新集群确定安全级别一样。
- 根据现有的 PodSecurityPolicy 来确定 - 基于 将 PodSecurityPolicy 映射到 Pod 安全性标准 参考资料，你可以将各个 PSP 映射到某个 Pod 安全性标准级别。如果你的 PSP 不是基于 Pod 安全性标准的，你可能或者需要选择一个至少与该 PSP 一样宽松的级别， 或者选择一个至少与其一样严格的级别。使用下面的命令你可以查看被 Pod 使用的 PSP 有哪些：
kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u
- 根据现有 Pod 来确定 - 使用检查 Pod 安全性级别小节所述策略， 你可以测试 Baseline 和 Restricted 级别，检查它们是否对于现有负载而言足够宽松， 并选择二者之间特权级较低的合法级别。
4.2、检查 Pod 安全性级别
一旦我们已经为名字空间选择了 Pod 安全性级别（或者你正在尝试多个不同级别）， 先进行测试是个不错的主意（如果使用 Privileged 级别，则可略过此步骤）。 Pod 安全性包含若干工具可用来测试和安全地推出安全性配置。
可以试运行新策略，这个过程可以针对所应用的策略评估当前在名字空间中运行的 Pod，但不会令新策略马上生效：
# $LEVEL 是要试运行的级别，可以是 "baseline" 或 "restricted"
kubectl label --dry-run=server --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL
此命令会针对在所提议的级别下不再合法的所有 现存 Pod 返回警告信息。
第二种办法在抓取当前未运行的负载方面表现的更好：audit 模式。 运行于 audit 模式（而非 enforcing 模式）下时，违反策略级别的 Pod 会被记录到审计日志中， 经过一段时间后可以在日志中查看到，但这些 Pod 不会被拒绝。 warning 模式的工作方式与此类似，不过会立即向用户返回告警信息。 你可以使用下面的命令为名字空间设置 audit 模式的级别：
kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL
当以上两种方法输出意料之外的违例状况时，你就需要或者更新发生违例的负载以满足策略需求， 或者放宽名字空间上的 Pod 安全性级别。
4.3、实施 Pod 安全性级别
当你对可以安全地在名字空间上实施的级别比较满意时，你可以更新名字空间来实施所期望的级别：
kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL
4.4、绕过 PodSecurityPolicy
最后，我们通过将 完全特权的 PSP 绑定到某名字空间中所有服务账户上，在名字空间层面绕过所有 PodSecurityPolicy。
# 下面集群范围的命令只需要执行一次
kubectl apply -f privileged-psp.yaml
kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged
# 逐个名字空间地禁用
kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE
由于特权 PSP 是非变更性的，PSP 准入控制器总是优选非变更性的 PSP， 上面的操作会确保对应名字空间中的所有 Pod 不再会被 PodSecurityPolicy 所更改或限制。
按上述操作逐个名字空间地禁用 PodSecurityPolicy 这种做法的好处是， 如果出现问题，你可以很方便地通过删除 RoleBinding 来回滚所作的更改。 你所要做的只是确保之前存在的 PodSecurityPolicy 还在。
# 撤销 PodSecurityPolicy 的禁用
kubectl delete -n $NAMESPACE rolebinding disable-psp
五、禁用 PodSecurityPolicy
如果需要验证 PodSecurityPolicy 准入控制器不再被启用，可以通过扮演某个无法访问任何 PodSecurityPolicy 的用户来执行测试， 或者通过检查 API 服务器的日志来进行验证。在启动期间，API 服务器会输出日志行，列举所挂载的准入控制器插件。
I0218 00:59:44.903329 13 plugins.go:158] Loaded 16 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,LimitRanger,ServiceAccount,NodeRestriction,TaintNodesByCondition,Priority,DefaultTolerationSeconds,ExtendedResourceToleration,PersistentVolumeLabel,DefaultStorageClass,StorageObjectInUseProtection,RuntimeClass,DefaultIngressClass,MutatingAdmissionWebhook.
I0218 00:59:44.903350 13 plugins.go:161] Loaded 14 validating admission controller(s) successfully in the following order: LimitRanger,ServiceAccount,PodSecurity,Priority,PersistentVolumeClaimResize,RuntimeClass,CertificateApproval,CertificateSigning,CertificateSubjectRestriction,DenyServiceExternalIPs,ValidatingAdmissionWebhook,ResourceQuota.
你应该会看到 PodSecurity（在 validating admission controllers 列表中）， 并且两个列表中都不应该包含 PodSecurityPolicy。
一旦确定 PSP 准入控制器已被禁用（并且这种状况已经持续了一段时间， 这样你才会比较确定不需要回滚），你就可以放心地删除你的 PodSecurityPolicy 以及所关联的所有 Role、ClusterRole、RoleBinding、ClusterRoleBinding 等对象 （仅需要确保他们不再授予其他不相关的访问权限）。
总结
现在现有的名字空间都已被更新，强制实施 Pod 安全性准入， 你应该确保你用来管控新名字空间创建的流程与/或策略也被更新，这样合适的 Pod 安全性配置会被应用到新的名字空间上。
你也可以静态配置 Pod 安全性准入控制器，为尚未打标签的名字空间设置默认的 enforce、audit 与/或 warn 级别。
看完本篇文章，我想你应该对 PodSecurityPolicy 已经有了一个清晰的认识。