安全

• 1: 云原生安全概述
• 2: Pod 安全性标准
• 3: Pod 安全性准入
• 4: Kubernetes API 访问控制

1 - 云原生安全概述

本概述定义了一个模型，用于在 Cloud Native 安全性上下文中考虑 Kubernetes 安全性。

云原生安全的 4 个 C

你可以分层去考虑安全性，云原生安全的 4 个 C 分别是云（Cloud）、集群（Cluster）、容器（Container）和代码（Code）。

云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。你无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。

云

在许多方面，云（或者位于同一位置的服务器，或者是公司数据中心）是 Kubernetes 集群中的 可信计算基。 如果云层容易受到攻击（或者被配置成了易受攻击的方式），就不能保证在此基础之上构建的组件是安全的。 每个云提供商都会提出安全建议，以在其环境中安全地运行工作负载。

云提供商安全性

如果您是在您自己的硬件或者其他不同的云提供商上运行 Kubernetes 集群， 请查阅相关文档来获取最好的安全实践。

下面是一些比较流行的云提供商的安全性文档链接：

基础设施安全

关于在 Kubernetes 集群中保护你的基础设施的建议：

集群

保护 Kubernetes 有两个方面需要注意：

• 保护可配置的集群组件
• 保护在集群中运行的应用程序

集群组件

如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关保护集群的建议。

集群中的组件（您的应用）

根据您的应用程序的受攻击面，您可能需要关注安全性的特定面，比如： 如果您正在运行中的一个服务（A 服务）在其他资源链中很重要，并且所运行的另一工作负载（服务 B） 容易受到资源枯竭的攻击，则如果你不限制服务 B 的资源的话，损害服务 A 的风险就会很高。 下表列出了安全性关注的领域和建议，用以保护 Kubernetes 中运行的工作负载：

容器

容器安全性不在本指南的探讨范围内。下面是一些探索此主题的建议和连接：

代码

应用程序代码是您最能够控制的主要攻击面之一，虽然保护应用程序代码不在 Kubernetes 安全主题范围内，但以下是保护应用程序代码的建议：

代码安全性

接下来

学习了解相关的 Kubernetes 安全主题：

• Pod 安全标准
• Pod 的网络策略
• 控制对 Kubernetes API 的访问
• 保护您的集群
• 为控制面加密通信中的数据
• 加密静止状态的数据
• Kubernetes 中的 Secret
• 运行时类

2 - Pod 安全性标准

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

Profile 细节

Privileged

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

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

Baseline

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

Restricted

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

策略实例化

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

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

Pod 安全性准入控制器

• Privileged 名字空间
• Baseline 名字空间
• Restricted 名字空间

PodSecurityPolicy （已弃用）

• Privileged
• Baseline
• Restricted

常见问题

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

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

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

安全策略与安全上下文的区别是什么？

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

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

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

• OPA Gatekeeper。
• Kubewarden。
• Kyverno。

我应该为我的 Windows 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）来辨别，不过 目前还没有关于什么是沙箱化运行时的标准定义。

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

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

3 - Pod 安全性准入

Kubernetes Pod 安全性标准（Security Standards） 为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。

作为一项 Beta 功能特性，Kubernetes 提供一种内置的 Pod 安全性 准入控制器， 作为 PodSecurityPolicies 特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在 名字空间层面实施的。

启用 PodSecurity 准入插件

在 v1.23 中，PodSecurity 特性门控 是一项 Beta 功能特性，默认被启用。

在 v1.22 中，PodSecurity 特性门控 是一项 Alpha 功能特性，必须在 kube-apiserver 上启用才能使用内置的准入插件。

--feature-gates="...,PodSecurity=true"

替代方案：安装 PodSecurity 准入 Webhook

对于无法应用内置 PodSecurity 准入插件的环境，无论是因为集群版本低于 v1.22， 或者 PodSecurity 特性无法被启用，都可以使用 Beta 版本的 验证性准入 Webhook。 来使用 PodSecurity 准入逻辑。

在 https://git.k8s.io/pod-security-admission/webhook 上可以找到一个预先构建的容器镜像、证书生成脚本以及一些示例性质的清单。

git clone git@github.com:kubernetes/pod-security-admission.git
cd pod-security-admission/webhook
make certs
kubectl apply -k .

Pod 安全性级别

Pod 安全性准入插件对 Pod 的安全性上下文 有一定的要求，并且依据 Pod 安全性标准 所定义的三个级别（privileged、baseline 和 restricted）对其他字段也有要求。 关于这些需求的更进一步讨论，请参阅 Pod 安全性标准页面。

为名字空间设置 Pod 安全性准入控制标签

一旦特性被启用或者安装了 Webhook，你可以配置名字空间以定义每个名字空间中 Pod 安全性准入控制模式。 Kubernetes 定义了一组标签， 你可以设置这些标签来定义某个名字空间上要使用的预定义的 Pod 安全性标准级别。 你所选择的标签定义了检测到潜在违例时，控制面 要采取什么样的动作。

名字空间可以配置任何一种或者所有模式，或者甚至为不同的模式设置不同的级别。

对于每种模式，决定所使用策略的标签有两个：

# 针对模式的级别标签用来标示针对该模式所应用的策略级别
#
# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
# LEVEL 必须是 `privileged`、baseline` 或 `restricted` 之一
pod-security.kubernetes.io/<MODE>: <LEVEL>

# 可选：针对每个模式版本的版本标签可以将策略锁定到
# 给定 Kubernetes 小版本号所附带的版本（例如 v1.23）
#
# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
# VERSION 必须是一个合法的 Kubernetes 小版本号或者 `latest`
pod-security.kubernetes.io/<MODE>-version: <VERSION>

关于用法示例，可参阅 使用名字空间标签来强制实施 Pod 安全标准。

负载资源和 Pod 模板

Pod 通常是通过创建 Deployment 或 Job 这类工作负载对象 来间接创建的。工作负载对象为工作负载资源定义一个 Pod 模板 和一个对应的 负责基于该模板来创建 Pod 的控制器。 为了尽早地捕获违例状况，audit 和 warn 模式都应用到负载资源。 不过，enforce 模式并 不 应用到工作负载资源，仅应用到所生成的 Pod 对象上。

豁免

你可以为 Pod 安全性的实施设置 豁免（Exemptions） 规则， 从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。 豁免规则可以在准入控制器配置 中静态配置。

豁免规则可以显式枚举。满足豁免标准的请求会被准入控制器 忽略 （所有 enforce、audit 和 warn 行为都会被略过）。 豁免的维度包括：

• Username： 来自用户名已被豁免的、已认证的（或伪装的）的用户的请求会被忽略。
• RuntimeClassName： 指定了已豁免的运行时类名称的 Pod 和负载资源会被忽略。
• Namespace： 位于被豁免的名字空间中的 Pod 和负载资源 会被忽略。

策略检查时会对以下 Pod 字段的更新操作予以豁免，这意味着如果 Pod 更新请求仅改变这些字段时，即使 Pod 违反了当前的策略级别，请求也不会被拒绝。

• 除了对 seccomp 或 AppArmor 注解之外的所有 meatadata 更新操作：
  • seccomp.security.alpha.kubernetes.io/pod （已弃用）
  • container.seccomp.security.alpha.kubernetes.io/* （已弃用）
  • container.apparmor.security.beta.kubernetes.io/*
• 对 .spec.activeDeadlineSeconds 的合法更新
• 对 .spec.tolerations 的合法更新

接下来

• Pod 安全性标准
• 强制实施 Pod 安全性标准
• 通过配置内置的准入控制器强制实施 Pod 安全性标准
• 使用名字空间标签来实施 Pod 安全性标准
• 从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器

4 - Kubernetes API 访问控制

本页面概述了对 Kubernetes API 的访问控制。

用户使用 kubectl、客户端库或构造 REST 请求来访问 Kubernetes API。 人类用户和 Kubernetes 服务账户都可以被鉴权访问 API。 当请求到达 API 时，它会经历多个阶段，如下图所示：

传输安全

在典型的 Kubernetes 集群中，API 服务器在 443 端口上提供服务，受 TLS 保护。 API 服务器出示证书。 该证书可以使用私有证书颁发机构（CA）签名，也可以基于链接到公认的 CA 的公钥基础架构签名。

如果你的集群使用私有证书颁发机构，你需要在客户端的 ~/.kube/config 文件中提供该 CA 证书的副本， 以便你可以信任该连接并确认该连接没有被拦截。

你的客户端可以在此阶段出示 TLS 客户端证书。

认证

如上图步骤 1 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。 集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。 身份认证组件在认证节中有更详细的描述。

认证步骤的输入整个 HTTP 请求；但是，通常组件只检查头部或/和客户端证书。

认证模块包含客户端证书、密码、普通令牌、引导令牌和 JSON Web 令牌（JWT，用于服务账户）。

可以指定多个认证模块，在这种情况下，服务器依次尝试每个验证模块，直到其中一个成功。

如果请求认证不通过，服务器将以 HTTP 状态码 401 拒绝该请求。 反之，该用户被认证为特定的 username，并且该用户名可用于后续步骤以在其决策中使用。 部分验证器还提供用户的组成员身份，其他则不提供。

鉴权

如上图的步骤 2 所示，将请求验证为来自特定的用户后，请求必须被鉴权。

请求必须包含请求者的用户名、请求的行为以及受该操作影响的对象。 如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过。

例如，如果 Bob 有以下策略，那么他只能在 projectCaribou 名称空间中读取 Pod。

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

如果 Bob 执行以下请求，那么请求会被鉴权，因为允许他读取 projectCaribou 名称空间中的对象。

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

如果 Bob 在 projectCaribou 名字空间中请求写（create 或 update）对象，其鉴权请求将被拒绝。 如果 Bob 在诸如 projectFish 这类其它名字空间中请求读取（get）对象，其鉴权也会被拒绝。

Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。 使用 REST 格式很重要，因为这些控制系统可能会与 Kubernetes API 之外的 API 交互。

Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhook 模式等。 管理员创建集群时，他们配置应在 API 服务器中使用的鉴权模块。 如果配置了多个鉴权模块，则 Kubernetes 会检查每个模块，任意一个模块鉴权该请求，请求即可继续； 如果所有模块拒绝了该请求，请求将会被拒绝（HTTP 状态码 403）。

要了解更多有关 Kubernetes 鉴权的更多信息，包括有关使用支持鉴权模块创建策略的详细信息， 请参阅鉴权。

准入控制

准入控制模块是可以修改或拒绝请求的软件模块。 除鉴权模块可用的属性外，准入控制模块还可以访问正在创建或修改的对象的内容。

准入控制器对创建、修改、删除或（通过代理）连接对象的请求进行操作。 准入控制器不会对仅读取对象的请求起作用。 有多个准入控制器被配置时，服务器将依次调用它们。

这一操作如上图的步骤 3 所示。

与身份认证和鉴权模块不同，如果任何准入控制器模块拒绝某请求，则该请求将立即被拒绝。

除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。

可用的准入控制模块在准入控制器中进行了描述。

请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 4 所示）。

API 服务器端口和 IP

前面的讨论适用于发送到 API 服务器的安全端口的请求（典型情况）。 API 服务器实际上可以在 2 个端口上提供服务：

默认情况下，Kubernetes API 服务器在 2 个端口上提供 HTTP 服务：

1. localhost 端口:

   • 用于测试和引导，以及主控节点上的其他组件（调度器，控制器管理器）与 API 通信
   • 没有 TLS
   • 默认为端口 8080
   • 默认 IP 为 localhost，使用 --insecure-bind-address 进行更改
   • 请求 绕过 身份认证和鉴权模块
   • 由准入控制模块处理的请求
   • 受需要访问主机的保护

2. “安全端口”：

   • 尽可能使用
   • 使用 TLS。 用 --tls-cert-file 设置证书，用 --tls-private-key-file 设置密钥
   • 默认端口 6443，使用 --secure-port 更改
   • 默认 IP 是第一个非本地网络接口，使用 --bind-address 更改
   • 请求须经身份认证和鉴权组件处理
   • 请求须经准入控制模块处理
   • 身份认证和鉴权模块运行

接下来

阅读更多有关身份认证、鉴权和 API 访问控制的文档：

• 认证
  • 使用 Bootstrap 令牌进行身份认证
• 准入控制器
  • 动态准入控制
• 鉴权
  • 基于角色的访问控制
  • 基于属性的访问控制
  • 节点鉴权
  • Webhook 鉴权
• 证书签名请求
  • 包括 CSR 认证 和证书签名
• 服务账户
  • 开发者指导
  • 管理

你可以了解

• Pod 如何使用 Secrets 获取 API 凭证.