Pod 安全性标准

以前，对集群的安全性上下文的需求的实施及其基于策略的定义都通过使用 来实现。 Pod 安全性策略（Pod Security Policy） 是一种集群层面的资源，控制 Pod 规约中 安全性敏感的部分。

不过，新的策略实施方式不断涌现，或增强或替换 PodSecurityPolicy 的使用。 本页的目的是详细介绍建议实施的 Pod 安全框架；这些内容与具体的实现无关。

在进一步讨论整个策略谱系之前，有必要对基本的策略下个定义。 策略可以是很严格的也可以是很宽松的：

• Baseline/Default - 限制性最弱的策略，禁止已知的策略提升。 允许使用默认的（规定最少）Pod 配置。
• Restricted - 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。

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

Privileged 策略定义中限制较少。对于默认允许（Allow-by-default）实施机制（例如 gatekeeper）， Privileged 框架可能意味着不应用任何约束而不是实施某策略实例。 与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言， Privileged 策略应该默认允许所有控制（即，禁止所有限制）。

Baseline/Default

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

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

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

PodSecurityPolicy

• Baseline

为什么策略类型定义在 Privileged 和 Default 之间

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

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

安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。 在 2020 年 2 月，目前实施这些安全性策略的原生解决方案是 - 一种对集群中 Pod 的安全性策略进行集中控制的机制。 Kubernetes 生态系统中还在开发一些其他的替代方案，例如 OPA Gatekeeper。

我应该为我的 Windows Pod 实施哪种框架？

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

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

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