Pod 安全性标准

Pod 安全性标准定义了三种不同的 策略（Policy），以广泛覆盖安全应用场景。这些策略是 叠加式的（Cumulative），安全级别从高度宽松至高度受限。本指南概述了每个策略的要求。

Privileged 策略是有目的地开放且完全无限制的策略。此类策略通常针对由特权较高、受信任的用户所管理的系统级或基础设施级负载。

Privileged 策略定义中限制较少。默认允许的（Allow-by-default）实施机制（例如 gatekeeper）可以缺省设置为 Privileged。与此不同，对于默认拒绝（Deny-by-default）的实施机制（如 Pod 安全策略）而言， Privileged 策略应该禁止所有限制。

Baseline

Baseline 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。此策略针对的是应用运维人员和非关键性应用的开发人员。下面列举的控制应该被实施（禁止）：

说明：

在下述表格中，通配符（）意味着一个列表中的所有元素。例如 spec.containers[*].securityContext 表示 所定义的所有容器 的安全性上下文对象。如果所列出的任一容器不能满足要求，整个 Pod 将无法通过校验。

Restricted 策略旨在实施当前保护 Pod 的最佳实践，尽管这样作可能会牺牲一些兼容性。该类策略主要针对运维人员和安全性很重要的应用的开发人员，以及不太被信任的用户。下面列举的控制需要被实施（禁止）：

说明：

在下述表格中，通配符（*）意味着一个列表中的所有元素。例如 spec.containers[*].securityContext 表示 所定义的所有容器 的安全性上下文对象。如果所列出的任一容器不能满足要求，整个 Pod 将无法通过校验。

将策略定义从策略实例中解耦出来有助于形成跨集群的策略理解和语言陈述，以免绑定到特定的下层实施机制。

随着相关机制的成熟，这些机制会按策略分别定义在下面。特定策略的实施方法不在这里定义。

（已弃用）

替代方案

说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读。

在 Kubernetes 生态系统中还在开发一些其他的替代方案，例如：

这里定义的三种策略框架有一个明晰的线性递进关系，从最安全（Restricted）到最不安全，并且覆盖了很大范围的工作负载。特权要求超出 Baseline 策略者通常是特定于应用的需求，所以我们没有在这个范围内提供标准框架。这并不意味着在这样的情形下仍然只能使用 Privileged 框架，只是说处于这个范围的策略需要因地制宜地定义。

SIG Auth 可能会在将来考虑这个范围的框架，前提是有对其他框架的需求。

安全配置与安全上下文的区别是什么？

安全上下文在运行时配置 Pod 和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的，所代表的是传递给容器运行时的参数。

安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。在 2020 年 7 月，已被废弃，取而代之的是内置的 Pod 安全性准入控制器。

Kubernetes 中的 Windows 负载与标准的基于 Linux 的负载相比有一些局限性和区别。尤其是 Pod SecurityContext 字段对 Windows 不起作用。因此，目前没有对应的标准 Pod 安全性框架。

如果你为一个 Windows Pod 应用了 Restricted 策略，可能会 对该 Pod 的运行时产生影响。 Restricted 策略需要强制执行 Linux 特有的限制（如 seccomp Profile，并且禁止特权提升）。如果 kubelet 和/或其容器运行时忽略了 Linux 特有的值，那么应该不影响 Windows Pod 正常工作。然而，对于使用 Windows 容器的 Pod 来说，缺乏强制执行意味着相比于 Restricted 策略，没有任何额外的限制。

你应该只在 Privileged 策略下使用 HostProcess 标志来创建 HostProcess Pod。在 Baseline 和 Restricted 策略下，创建 Windows HostProcess Pod 是被禁止的，因此任何 HostProcess Pod 都应该被认为是有特权的。

沙箱（Sandboxed）Pod 怎么处理？

现在还没有 API 标准来控制 Pod 是否被视作沙箱化 Pod。沙箱 Pod 可以通过其是否使用沙箱化运行时（如 gVisor 或 Kata Container）来辨别，不过目前还没有关于什么是沙箱化运行时的标准定义。

沙箱化负载所需要的保护可能彼此各不相同。例如，当负载与下层内核直接隔离开来时，限制特权化操作的许可就不那么重要。这使得那些需要更多许可权限的负载仍能被有效隔离。