Kubernetes中的Pod安全性标准-Kubernetes中文教程(三)

当前位置:　首页>> 技术小册>> Kubernetes中文教程(三)

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

| Profile | 描述 |
| ------ | ----------- |
| Privileged | 不受限制的策略，提供最大可能范围的权限许可。此策略允许已知的特权提升。 |
| Baseline | 限制性最弱的策略，禁止已知的策略提升。允许使用默认的（规定最少）Pod 配置。 |
| Restricted | 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。 |

## Profile 细节

### Privileged

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

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

### Baseline

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

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

### Restricted

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

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

## 策略实例化

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

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

[**Pod 安全性准入控制器**]

- Privileged 名字空间
- Baseline 名字空间
- Restricted 名字空间

### 替代方案

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

- [Kubewarden]
- [Kyverno]
- [OPA Gatekeeper]

## Pod OS 字段

Kubernetes 允许你使用运行 Linux 或 Windows 的节点。你可以在一个集群中混用两种类型的节点。
Kubernetes 中的 Windows 与基于 Linux 的工作负载相比有一些限制和差异。
具体而言，许多 Pod `securityContext`
字段[在 Windows 上不起作用]。

v1.24 之前的 Kubelet 不强制处理 Pod OS 字段，如果集群中有些节点运行早于 v1.24 的版本，
则应将限制性的策略锁定到 v1.25 之前的版本。

### 限制性的 Pod Security Standard 变更

Kubernetes v1.25 中的另一个重要变化是**限制性的（Restricted）** Pod 安全性已更新，
能够处理 `pod.spec.os.name` 字段。根据 OS 名称，专用于特定 OS 的某些策略对其他 OS 可以放宽限制。

#### OS 特定的策略控制

仅当 `.spec.os.name` 不是 `windows` 时，才需要对以下控制进行限制：
- 特权提升
- Seccomp
- Linux 权能

## 常见问题

### 为什么不存在介于 Privileged 和 Baseline 之间的策略类型

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

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

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

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

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

### 沙箱（Sandboxed）Pod 怎么处理？

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

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

此外，沙箱化负载的保护高度依赖于沙箱化的实现方法。
因此，现在还没有针对所有沙箱化负载的建议配置。

该分类下的相关小册推荐：

Kubernets合辑10-网络

Kubernets合辑13-集群监控

Kubernets合辑9-资源约束

Kubernets合辑8-权限控制

Kubernets合辑7-存储

云原生-K8S入门实战

Kubernetes中文教程(一)

Kubernetes中文教程(六)

Kubernets合辑4-kubernetes入门

Kubernets合辑3-kubernetes介绍

Kubernets合辑5-Pod控制器

Kubernets合辑14-日志收集