# Kubernetes 策略管理

原文：[Kubernetes Policy Management Whitepaper](https://github.com/kubernetes/sig-security/tree/main/sig-security-docs/papers/policy)

本文试图清晰地阐述 Kubernetes 策略管理的必要性以及在工作负载安全和自动化方面的作用。另外还会讲述 Kubernetes 策略的适用场景以及实现原理。

## 简介

策略是一组规则，组织能用策略来帮助达成预期目标。策略可以应用在成本、安全以及生产力等各类行为之中。例如一个公司的开支策略定义了财务团队对员工采购进行审计的指导方针。

在信息技术方面，策略是系统配置和行为的规则，可能应用在安全、弹性、韧性以及最佳实践等不同领域之中。策略中定义的系统控制规则可以用声明式的方法来表达这些建议行为。Kubernetes 为代表的云原生系统通常是可扩展的，所以可以将策略管理能力集成到系统配置之中。为系统的执行或者审计行为建立报告就能对策略的遵从情况进行衡量。

在 Kubernetes 中，策略可以理解为应用属主、集群管理员以及安全管理员之间签订的数字契约。Kubernetes 管理员根据安全与合规需求，制定策略并部署到集群之中。策略会针对特定配置或行为做出放行、禁止或者审计的响应。一般来说策略是由运维和信息安全团队协作编写的。管理策略的最佳方式就是用代码表达策略，并且进行可审计的源码管理。

Kubernetes 的[原生 API](https://kubernetes.io/docs/concepts/overview/kubernetes-api/) 中就带有策略的内容（例如[网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)），还可以通过[动态准入控制器](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)的方式把外部的策略引擎运行在 [Kubernetes 控制面](https://kubernetes.io/docs/reference/glossary/?all=true#term-control-plane)之中。本文会同时涉及这两种策略实施方式。

## 作者

* Anca Salier, IBM
    
* Ardhna Chetal, TIAA
    
* Jayashree Ramanathan, Red Hat
    
* Jim Bugwadia, Nirmata
    
* Robert Ficcaglia, Sunstone Secure
    

## 鸣谢

作者团队在此感谢下列各位对本文的评审和反馈：

* Raj Krishnamurthy, ContiNube
    
* Itay Shakury, Aqua Security
    
* Vishwas Manral, McAfee Enterprise (NanoSec)
    
* Rory McCune, Aqua Security
    
* Andres Vega, VMware
    
* Sayantani Saha, IEM-Kolkata
    
* Jack Kelly
    
* Ash Narkar, Styra
    
* Kapil Bareja, Deloitte
    
* Karim Benzidane, IBM
    
* Maor Kuriel, WhiteSource
    
* Herbert Mühlburger, IT-Ziviltechniker
    
* Maarten Hoogendoorn, Container Solutions
    
* Pushkar Joglekar, VMware
    
* Alok Raj
    
* Dan Papandrea, Sysdig
    
* Abdelrahman Essam
    
* Rahul Jadhav, Accuknox
    

同时还需要感谢 CNCF [安全 TAG](https://github.com/cncf/tag-security#readme) 以及 Kubernetes [安全 SIG](https://github.com/kubernetes/community/tree/master/sig-security#security-special-interest-group) 的合作和支持。

## 目标读者

本文适用于 Kubernetes 管理员、SRE 工程师以及其他希望在安全、韧性以及最佳实践方面符合组织标准以及监管要求的情况下创建集群并运行工作负载的从业者。

首席安全官（CSO）、首席信息安全官（CISO）、首席技术官（CTO）、安全以及合规从业人员，以及使用 Kubernetes 的审计人员也能从本文中受益。其它对 Kubernetes 安全、合规以及治理有兴趣的人也可以参考本文内容。

## 包括什么

Kubernetes 文档定义了[云原生安全的 4C 模型](https://kubernetes.io/docs/concepts/security/overview/#the-4c-s-of-cloud-native-security)，其中包含了代码、容器、集群和云四个维度：

![](images/c4security.png align="left")

Kubernetes 中的策略聚焦于中间的两层——容器和集群；而代码和云则不在本文范围之内，另外两层则属于总体安全策略的范畴。也就是说除了确保容器和集群的安全之外：

* 云和其它基础设施的安全也必须进行加固和管理
    
* 运行在容器中的应用代码和第三方依赖也必须确保安全
    

在 4C 模型中，Code 代表着[运行在容器中的应用程序代码](https://kubernetes.io/docs/concepts/security/overview/#code)。Kubernetes 配置是由一系列对资源理想状态的声明构成的，这些声明通常用一组以 YAML 编写的资源清单构成。管理 Kubernetes 资源清单的最佳实践就是 `As Code`（例如版本控制、评审以及测试的措施），这些资源清单用于描述容器化应用在 Kubernetes 集群中的运行方式，因此在 4C 模型中被映射为容器层。

## 不包括什么

根据上面的讨论，不包括在本文中的层次是：

* 云：容器平台所在的基础设施
    
* 代码：应用代码和第三方依赖的安全
    

## 策略引擎和工具

本文内容围绕策略管理概念展开，而不会对策略管理工具进行陈述或比较。云原生全景图中的[安全与合规](https://landscape.cncf.io/card-mode?category=security-compliance&grouping=category)类目中包含了工具方面的内容。

## 策略架构

来自 OASIS（Organization for the Advancement of Structured Information Standards 结构化信息标准促进组织）的 XACML（eXtensible Access Control Markup Language 可扩展访问控制标记语言）标准，定义了策略的语言、架构和过程模型。要定义 Kubernetes 的策略管理架构，XACML 架构是一个合适的起点。

在 XACML 架构中，PAP（Policy Administration Point 策略管理点）会为 PDP（Policy Desision Point 策略决策点）创建策略或者策略组。PEP（Policy Enforcement Point 策略执行点）会对用户请求进行处理，处理过程中会和 PDP 进行通信，得到最终决策。PDP 会从 PIP（Policy Information Point 策略信息点）获取属性值，以此充实策略数据。PDP 接下来就会指示 PEP 如何处理请求——例如放行或者拒绝。

下图展示了 XACML 组件和组件之间的互动。[OASIS 的 XACML 3.0 规范](http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html)中描述了这方面的详细内容。

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745923353998/db66e80a-8183-48a2-b0fa-edb38e9eb0ad.png align="center")

接下来看看 XACML 架构在 Kubernetes 策略管理中的应用。

### PAP

在 Kubernetes 中实施 XACML 架构时，通常会用一个中央管理系统来在多个集群中进行策略的定义和分发，以此实现 PAP 的职责。PAP 能集成版本控制系统或者兼容 [OCI](https://opencontainers.org/) 的仓库来存储策略定义。版本控制和预发布测试及验证等软件开发方面的最佳实践都可以应用到策略的定义行为之中，也就是策略即代码（Polic as Code，PAC）。随着策略数量的增长，策略管理员会试着依据服务、领域或者控制焦点等维度对策略进行组织，用多个小的代码段来表达策略，让应用或服务查询特定策略；或者通过构造等设计模式进行策略的动态查找。例如根据控制类型或者特定的合规标准以及安全领域对策略进行分析组织。

PAP 为多个集群提供策略支持，并提供接口进行策略的配置。PAP 根据绑定关系将策略部署到受管理的集群上。一种弹性的实施方法就是用标签标识集群，根据对标签的查询来选择在特定集群上部署特定的策略。

PAP 用于编写、部署策略，并管理策略的变更。然而现实世界中的策略管理系统还会提供合规映射、策略结果管理、自动化工作流、团队协作以及和其它企业系统（例如认证管理、版本控制、告警等）进行集成的能力。除了管理和分发策略之外，PAP 的典型功能有：

* 用图形化的方式组织多个集群的策略执行结果和违规记录，结合上下文数据，促成不同分工团队（例如开发、SRE 以及 SecOps）的协作；
    
* 用策略报告的方式导出多个集群的详细违规记录，和其它 IT 工具进行集成，受管理的多个集群就无需各自完成和这些 IT 工具进行对接了；
    
* 为合规工作提供长期的概要报告。特定策略的详细违规记录保存在各种 PEP 之中。PAP 保存策略结果的时长一般是可以配置的，也可以将长期结果卸载到外部存储；
    
* 提供安全和合规评估报告以及态势细节；
    
* 和 SOC（Security Operations Center 安全运维中心）、事件管理以及 GRC（Governance Risk and Compliance）等企业工具进行对接。和 SOC 以及 GRC 结合 可以将 PDP 的结果映射到特定的合规条例（例如 PCI）、法规（例如 HIPAA）或者标准（例如 NIST 800-53）及其控制；
    
* 将原生的策略报告格式转译为 NIST 开放安全评估控制语言（OSCAL—Open Security Controls Assessment Language）或者为审计过程提供模板。
    

![](images/pap.png align="left")

### PEP

PEP 用于执行策略，确保 Kubernetes 的工作负载和集群本身符合策略要求。还可以帮助对配置进行审计，并且在 API 资源发生违规操作时候进行告警。

Kubernetes 会使用以下方式执行策略：

1. 内置策略对象
    
2. 用准入控制器来扩展 Kubernetes
    
3. 策略引擎
    

这些选项并非互斥关系，全面的安全解决方案会使用多种方式协作完成任务。

#### Kubernetes 策略对象

Kubernetes 内置了多种策略以及可以作为策略基础的资源对象。这些资源由 Kubernetes 控制器来实现。

* Namespaces：Kubernetes [命名空间](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)提供了 API 级别的资源分片，让不同工作负载和团队共享一个集群。即使是一个应用或者团队独占的集群，也应该使用命名空间作为安全边界，以此限制集群级别的访问；
    
* RBAC：Kubernetes 可以定义集群级或命名空间级的角色，其中包含了授权信息，并可以将[角色绑定](\(https://kubernetes.io/docs/reference/access-authn-authz/rbac/\))到用户或 Service Account 上；
    
* Pod Security admission：Pod 是 Kubernetes 中的基本执行单元，每个 Pod 都有一个安全上下文，其中定义了 Pod 的特权情况以及其它安全需求。[Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 中定义了三个级别的安全策略，[Pod 安全准入控制器](https://kubernetes.io/docs/concepts/security/pod-security-admission/) 提供了一个实现，用于在命名空间级别应用策略；
    
* Quota：这个对象为工作负载和命名空间指定了 request 和 limit，确保工作负载不会影响到同一集群中其它工作负载的性能。
    
* 网络策略：网络策略控制了工作负载的 Ingress 和 Egress 流量。网络策略是 Kubernetes API 的一部分，其具体实现是来自 CNI 插件的，因此必须安装支持网络策略的 CNI 插件才能使用网络策略。
    

#### 准入控制器

Kubernetes 中所有的配置变更活动，不论来自于管理员、终端用户、内置控制器、扩展或者外部管理系统，都是用声明式 API 进行的。所有 API 请求都是经由 Kubernetes API 服务器完成的，这样 API Server 就可以作为一个可扩展的执行点来进行工作了：

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745923375870/248a9d92-a757-4e43-9ffa-27b9798f9764.png align="center")

每个 Kubernetes API 请求在持久化到数据层（通常是 ETCD）之前，都会经过三个检查点：

* 认证：请求的发出方可能是用户或者应用，认证环节会验证凭据来鉴别用户的身份。Kubernetes 支持多种[认证方法](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)。例如基于 OpenID Connect（OIDC）的认证过程会使用中央认证的方式对 Token 进行认证，可以用于用户和 Service Account 的认证过程。策略管理需要确保部署了合适的认证方式，并遵循最佳实践进行配置。
    
* 鉴权：调用方经过认证之后，需要由鉴权环节来判别是否允许当前调用对指定资源进行读取或修改。Kubernetes 支持多种[鉴权模式](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)。RBAC 模式下，使用 Role 和 RoleBinding 对象控制命名空间中的资源；对于集群级的资源则会使用 ClusterRole 和 ClusterRoleBinding。 Kubernetes 中可以注册 Webhook 形式的鉴权插件。然而要使用这种模式，就需要对 API Server 的配置参数进行修改，托管 Kubernetes 通常不支持这种修改，因此很少使用这种模式。策略管理要求 Kubernetes 使用 RBAC 之类的鉴权模式。
    
* 准入控制：调用过程通过了认证和鉴权之后，Kubernetes 会调用[准入控制器](https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/)，对 API 请求的处理过程进行额外的控制。Kubernetes 内置了很多的准入控制器，可以使用 API Server 参数进行[启用或者禁用](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)。 准入控制器可以对数据进行校验甚至修改。例如内置的 LimitRanger 会对确保特定命名空间中的资源约束和预订配额没有冲突；DefaultIngressClass 会修改新建的 Ingress 控制器，设置一个缺省的 Ingress Class。 除了内置的准入控制器之外，Kubernetes 还可以用加密的方式注册以及调用外部控制器的 Webhook（Webhook 是一个软件组件，能够接收和响应 HTTP 请求），对请求数据进行校验和变更。这样外部策略引擎就能够对所有的 Kubernetes 请求进行校验或者修改。策略引擎可以作为一种深度防御机制，弥补常见的故障-放行控制。策略管理应该确保结合各种准入控制器和策略引擎来部署和实时策略。
    

在处理请求之前，可以用准入控制器实施策略，针对请求进行各种校验和修改，例如：

* 检查是否使用了可信的镜像仓库
    
* 检查镜像签名
    
* 把镜像标签转换为不可变的哈希值
    
* 执行供应链检查
    
* 强制使用 Kubernetes 策略对象，例如 Pod Security Admission、RBAC、命名空间、Limit 和 Quota 以及网络策略
    
* 使用合适的 SecComp 和 SELINUX 方案
    
* 禁止不安全的配置用法，例如不合理的特权 Pod
    
* （借助 Mutating Webhook）自动消减不安全配置
    
* 根据最佳实践进行审计和策略实施，例如设置健康检查和资源配额
    
* 生成缺省资源，例如缺省的网络策略
    

#### 运行时策略实施

对于一些不安全配置或者不当行为，例如访问被保护的文件系统，可以新增一个安全层进行检测。

在一些场景下，例如在现存的重要工作负载上引用新策略时，对于违规问题应该进行报告而不是阻断业务。PEP 应该提供这种细粒度的弹性控制。

容器运行时有两种不同的威胁：

1. 攻击者获得了控制权，可以创建新容器
    
2. 运行中的容器中产生的威胁
    

针对第一条威胁，可以使用 Kubernetes 认证、鉴权以及准入控制器来检查所有的 API 请求，这方面的策略在前面的章节已经有所涉及。接下来我们要关注的是第二个场景，要消减这方面的需求，需要对容器运行时参数进行合理的配置，并且要用策略来限制运行时做出非预期的行为。

Kubernetes 运行时策略引擎可以对运行中的容器进行观察，察觉或制止恶意的系统调用或进程，例如可以通过 LSM 直接拒绝危险的系统调用，阻止违规行为。实施最小特权原则可以保障容器只能在合法范围内进行活动，例如禁止或者限制或者审计对 debugfs 的使用，对其它进程的注入、写入可执行内存区、动态载入代码、载入内核模块以及进程钩子。可以定义策略限制或者审计到主机服务、Kubernetes API Server、云基础设施元数据服务（例如 AWS EC2 元数据服务），或者数据渗透、下载二进制文件等行为。

运行时策略能够根据访问 Token 中定义的的上下文和范围，限制 Kubernetes API 对资源的访问，或者对请求速率进行限制，避免队列积压或者控制器发生拒绝服务。例如阻止容器访问不应访问的命名空间内的资源，或者从 CoreDNS 中拉取服务信息，或者尝试通过 DoS 攻击准入控制器来绕过策略引擎。

运行时策略中可以依据 [CIS Benchmark for Kubernetes](https://www.cisecurity.org/benchmark/kubernetes/) 这样的容器安全标准进行周期性的检查。合规人员可以实现自动化的 CIS 基线检查，进行加固或者简单地进行监控和输出报告。

安全团队可以将策略报告输出到 Kubernetes API 审计流中，从而保持对编排活动的掌控。

在这些机制之外，云原生世界中出现了越来越多的安全左移的案例，例如在 GitOps 流程中可以在 CI 环节甚至开发者的工作站中执行策略，这样开发者就可以尽早得到策略评估的反馈情况。在“开发”一节中，会包含更多这方面的内容。

### PDP

策略引擎的角色就是策略决策点（PDP）。策略引擎可以在 Kubernetes 准入控制器中运行，或者也可以用特权工作负载的方式运行在集群里。PDP 可以做出安全、韧性、软件工程等方面的策略决策。

当策略设置为通知或者审计模式的时候，PDP 会根据策略中的要求进行检测，不匹配的截获会报送给 PEP。

策略引擎可以有自己的语言，用于策略的定义和管理。策略语言可以是 DSL，也可以是通用语言，或者声明式配置。不论如何定义，策略都是可以被 Kubernetes 集群进行访问的，最佳实践就是将其表达为 Kubernetes CRD。

[Kubernetes 策略工作组](https://github.com/kubernetes/community/tree/master/wg-policy)编写了一种弹性的可复用的策略结果报告定义。策略报告 CRD 是一种 Kubernetes API 对象，任何的 PDP 都可以用这种资源来报告策略执行结果；而 PAP 可以借此读取、保存以及报告当前以及实时的策略数据。PAP 还可以使用 Policy Report 对象对多个集群违反策略的细节情况进行外化，从而可以集成到外部的运维工具，用于事件管理、安全运维以及治理、风险、合规，以及进一步的映射到法规和标准控制。

补救措施包括根据策略要求进行修复，以符合策略中指定的最佳实践。当策略设置为 `enforce` 模式时，PEP 会在违反策略的时候进行补救。当策略设置为 `inform` 模式的时候，PEP 会将违反策略的情况汇报给 PAP，PAP 则会触发补救措施，或者将信息转换为告警发送给事件管理系统或者安全运维中心，从而启动补救措施。

### PIP

策略决策过程还需要其他的元数据和配置数据的支持。例如有的规则需要针对命名空间标签进行过滤，这样就需要对命名空间的标签进行查询；另外还可能需要从 API Server 进行查询，获取资源限制以及其它相关属性。

Kubernetes 策略引擎通常需要调用 Kubernetes API 来查询额外信息，以此作为策略决策的驱动数据。有的策略引擎还允许调用外部系统的信息。当然对外部系统的调用需要具备合适的性能以及安全性。

## 生命周期

前文介绍了 Kubernetes 的策略，并提供了一个引用架构。本节则会讨论 Kubernetes 策略在生命周期中的映射。

[CNCF 安全 TAG](https://github.com/cncf/tag-security#cncf-security-technical-advisory-group) 出品的 [云原生安全白皮书](https://github.com/cncf/tag-security/blob/main/security-whitepaper/CNCF_cloud-native-security-whitepaper-Nov2020.pdf) 定义了如下的生命周期：开发、分发、部署和运行。

Kubernetes 的策略可以应用到每个阶段之中，这里有两个需要聚焦的对象：

* 镜像：容器镜像通常由 CI/CD 构建而成，并且在容器化工作负载部署之后开始运行。
    
* 配置：Kubernetes 资源定义中使用声明式方法描述了容器化工作负载的运行方式。
    

PaC（策略即代码，Policy as Code）已经v成为云原生世界的共识，策略管理机制借此进入软件分发管线之中。Kubernetes 策略可以以自定义资源或者 [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) 的方式存在，和应用资源清单协同工作。

本节中，我们会讨论 Kubernetes 策略在四个声明周期阶段中的使用方式，以及 Kubernetes 策略的开发、分发以及管理。

### 开发

在软件开发生命周期的早期引入安全内容，能更轻松地发现和解决问题，降低总体风险，提高安全性。因此云原生实践的重点方法就是采用左移的思路，以便尽可能在产品周期的早期发现安全问题。

针对应用的 Kubernetes 策略应该和应用代码一起进行开发和管理。前面提到的网络策略、RBAC 和其它 Kubernetes 资源都属于这个类型。

开发阶段还包含了 IaC 以及 PaC 物料的创建和校验，如此一来团队就可以通过声明资源，并以版本控制的方式管理这些物料，从而轻松地管理 Kubernetes 资源。

在关键性的软件之中，实现全面的测试和分发策略是非常必要的。策略和代码一样，策略中的 Bug 或者非预期行为也能会导致严重的不易检测的问题。策略语言和引擎应该支持预览，并能模仿用户行为，使用多种输入进行测试。

### 分发

软件供应链链中包含很多步骤，例如构建、测试、打包和分发，会包含不同工具进行持续构建和持续交付。

Kubernetes 策略可以用于镜像和配置的校验，通过使用准入控制校验数字签名，确保其可信任，并且在分发过程没有遭到篡改。

这一过程的最佳实践，可以把包括软件物料清单（Software Bill of Materials，SBOM）、透明日志以及证明在分发阶段发布到仓库的元数据里，并在工作负载部署进入集群执行之前使用 Kubernetes 策略进行校验。

Kubernetes 准入控制和策略引擎还可以通过应用 Pod 和工作负载策略来满足组织合规要求。不合规的资源清单会被拒绝部署，同时策略引擎还可以用弹性的方式，在遭遇非关键问题时进行报告。

策略报告可以把违规情况和策略结果汇报给集群管理员和工作负载属主。Kubernetes 策略工作组发布了一个可复用的报告格式，可以在任何策略引擎中发布结果。这个报告是一个 Kubernetes 的自定义资源，可以使用 Kubernetes API 进行查询和管理。

另外 Kubernetes 策略引擎的设计目标中包含了策略执行的透明性，这里的透明性用指标来表达，其中包含了规则数量、结果以及策略执行的延迟等。

### 运行

已部署的镜像中，一旦发现新的脆弱性，应该能被检出。所以 Kubernetes 策略应该是持续更新的，才能在运行中的脆弱镜像中指出违反策略的问题。

类似地，Kubernetes 安全策略和最佳实践也应该是随时进化的，需要周期性的对运行中的应用进行检测，从而发现最新的策略违反情况。

## 安全映射

策略是运维和其他安全领域之间的桥梁。本节会讨论 Kubernetes 策略映射到其他安全功能的方式。

### 安全保障

安全保障需要一种整体能力，跨越构建、基础设施和运行时，解决平台和应用设计生命周期中的安全需求。作为安全开发生命周期的一部分，第一步就是为平台和工作负载开发一个威胁模型。

#### 威胁模型

在企业中，可以通过在不同层次中定义控制和策略进行深度防御，从而对威胁进行消解。策略是最佳实践的表达，通过策略实施的治理，就是让控制项进入符合最佳实践的状态。Kubernetes 工作负载以跟用户运行并且还具备主机访问能力，这种案例就可以判别为违反策略要求。在这种情况下，威胁模型是在实际状态和配置基础之上的，

用基于策略的方式来管理 Kubernetes 集群和工作负载，能够简化云原生安全模型中容器和集群的漏洞和威胁的管理工作。工作负载的隔离和分段策略，对于控制漏洞影响、制定防御措施来说非常重要。所有集群和容器的威胁模型，以及容器镜像和工作负载配置的安全影响分析是 Kubernetes 策略管理模型的基础。要进行安全影响分析，就需要了解工作负载、节点和集群的使用模式。可以使用标签或者注解的方式标识这些信息，方便策略的管理。例如 DevOps 工程师可以将管理持卡人数据的工作负载标记为高风险关键资产。

#### 交付管线中的安全保障

IaC 和 PaC 扩大了交付管道的适用范围。在软件声明周期中尽早加入安全内容，是确保云原生应用和服务安全的关键。在 CI 中整合安全工具的方式被称为左移。

错误配置会导致特权逃逸、脆弱镜像、来自非信任仓库的镜像、用 Root 身份运行的容器、内核篡改和数据丢失。

攻击者会开发各种新方法，尝试用恶意软件渗透到软件供应链之中进行攻击，从而避开传统的应用安全控制。有一些关键策略可以用于保护软件供应链。这些策略可以在 CI/CD 中执行，例如可以使用数字签名、代码完整性、镜像软件物料单等来方法来验证软件供应商的身份。还可以在将软件引入企业存储库之前，在沙箱环境中进行扫描。安全 TAG 发布的《[软件供应链最佳实践](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)》中包含了更多软件供应链安全方面的内容。

企业使用的软件，不管是自行构建还是来自第三方，安全保障都是必须的。从整体的安全角度保证看来，策略实施和违规检测都是关键行为。

#### 运行时安全保障

对策略的执行情况应该是可观测的，在违反策略的情况下需要进行告警。跟踪执行趋势、记录违规历史也是必要的。这种记录必须具备一定的粒度，避免在可视性方面产生断层。违规行为需要被审查，以改进政策并提高安全态势。

理想状况下，应该能使用自动化的方式补救违规行为。可以用隔离违规容器或者恢复配置的方式进行弥补，防止违规情况引发进一步的攻击。当然只有相当成熟的应用程序团队和平台团队，凭借成熟的流程和应用设计才能达成自动化目标。

Kubernetes 运行时安全策略的一些例子：

* 监控认证和访问控制日志
    
* 容器完整性监控，例如确保没有流氓进程在运行，没有更新主机文件。
    
* 观测网络流量、和网络安全
    
* 检测提权或新增 Capability
    
* 限制以 Root 身份运行容器
    
* 定期扫描 CIS 的合规性
    
* 检测并报告容器的攻陷情况
    
* 进行漏洞检测，确定是否有恶意软件通过交互式访问或通过网络接口注入
    
* 容器遥测，为检测和响应提供信息
    
* 检测在容器内运行的恶意脚本，如挖矿软件或端口扫描工具
    

#### 事件响应

事件响应主要是人工过程，因此本节主要讨论 Kubernetes 策略管理对该活动的影响。Kubernetes 事件响应应该和 DevSecOps 流程对齐，强调可声明状态、工作负载瞬态和自动化控制。

Kubernetes 和云原生技术为事件响应计划引入了新的挑战。需要对大量的遥测数据进行有效的识别，在容器的短暂生命周期中克服持久化资源的缺失，检测到其中的攻击行为。要自动地对遥测和审计数据进行采集和处理，自动化工作流从原始遥测数据中提取可操作的事件，应对基础设施的运行状态变化。现有的 SIEM 和 SOAR 平台如果聚焦于人工操作，可能难于应对这样的挑战。

Kubernetes 中正在引入更多的[混沌工程](https://en.wikipedia.org/wiki/Chaos_engineering)实践，用于事件响应计划和模拟，有利于发现新的威胁，设计更好的监控和遥测过程。基于机器学习的遥测分析能够帮助识别反常行为和边缘案例。自愈的重要性日益增长，借助策略及代码技术，训练 ML 模型，让这些工具随着攻击者的发展而适应。Kubernetes 策略报告中可以提供额外的数据，可以在 PAP 中搜集和保存长期数据。

### 合规

Kubernetes 策略有助于自动化合规。目前已有一系列的监管标准或者行业惯例，例如 PCI、NIST 800-30、NIST 800-53，NIST 800-190、HIPAA 等。策略映射关系在集群和应用负载配置中，建立了合规目标和技术控制的连接。

策略映射让集群管理员和应用属主用代码的形式定义控制的实现方式。例如 NIST 800-53 的控制项 `PROTECTION OF INFORMATION AT REST`（用户信息和系统信息的机密性和完整性）可以映射到 Kubernetes 控制项：

* 确定容器磁盘被加密
    
* 保障启用 ETCD 加密
    
* 用加密方式保存 Secret 对象
    

可以使用策略语言在 Kubernetes 中编写这些控制。另外为了便于复用，可以为策略定义参数，在保障基本功能和缺省能力的情况下，提供一种可变能力，能够应对不同的风险。

策略映射完成之后，根据客户现状结合相应的参数，就可以进行部署并对 Kubernetes 配置和容器进行校验了。

Kubernetes 集群中的策略不仅对安全运维团队有帮助，对合规部门也是有好处的。集群管理员需要根据合规基线对安全配置和容器以及集群进行校验；合规人员也希望通过他们的监管视角来对集群和容器的监管合规性进行评估和分享。

运营和合规角色之间成功联动的关键是认识到两者之间专业知识和期望值的差异：运营管理员更喜欢不合规资产或资源的报告，而合规官员更喜欢控制实施的缺陷或缺失以及系统和数据的相应风险的报告。

像之前讨论过的一个标准化的评估结果格式，如之前讨论的政策报告CRD，解决了这种观点和目标的两分法。如果使用一种模式，其格式旨在并支持不同资产和系统的标准化，这就可以实现端到端的自动化。OSCAL就是这样一种标准模式，有许多层次（见下文）。

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745923394611/bf1993bf-1ba3-4cba-ae91-e28dc02659b7.png align="center")

[OSCAL 评估结果模型](https://pages.nist.gov/OSCAL/documentation/schema/assessment-results-layer/assessment-results/)定义了结构化的、机器可读的 JSON 和 YAML，以表示评估报告中包含的信息。任何对系统进行评估或持续监控活动的人都可以使用这个模型，以确定该系统符合一个或多个框架的程度。如果想要提高补救的自动化程度，这一点尤其有帮助。

从本质上讲，合规的集群是使用 Kubernetes 策略管理的。基于策略的方法提高了自动化程度，减少了整体的合规性负担，使企业能够专注于制作他们的应用程序和开发流程。政策和合规状态验证的正式方法仍在制定过程之中，但在云原生社区正在出现。

## 结论

云原生组织正在采用 Kubernetes 来提高敏捷性，并使其运营和管理实践标准化。然而，安全和自动化仍然是一个挑战。在最近的一项云原生安全调查中，超过 80% 的受访者表示，他们正在寻找带有开源软件的现代安全系统，主要痛点是缺乏专业知识、与现有工具不匹配以及管理的复杂性。

基于策略的 Kubernetes 运营有助于解决这些挑战，它提供了跨开发、运营和安全角色的关注点分离。各方向专家将各种配置控制的推荐做法和指南作为策略，使用云原生最佳实践在集群中部署。

一个全面的 Kubernetes 策略管理战略遵循三个准则。

* 使用 [Kubernetes 策略对象](https://kubernetes.io/docs/concepts/policy/)，如 Pod Security、Limit Range、配额，以及其他与安全相关的资源，如命名空间、角色和角色绑定，以及网络策略。
    
* 使用准入控制来对 Kubernetes 政策和安全资源的正确使用进行审计和执行，并在整个集群范围和工作负载配置中应用额外的策略，以实现安全和自动化。作为一个最佳实践，同样的政策集也作为持续交付管道的一部分被应用，以向熟悉系统的工作负载所有者报告违规情况。
    
* 使用运行时检测和执行工具来发现、报告和阻止不安全的运行时行为，这些行为没有被配置策略阻止、或者由于配置错误而被绕过。定期的配置扫描对于管理现有工作负载的策略变化也是必要的。
    

来自各执行点的政策报告和违规行为被传送到政策管理点（PAP），然后与事件响应系统和 SOC 整合，以便快速解决问题。

[CNCF 云原生互动全景图](https://landscape.cncf.io/card-mode?category=security-compliance&grouping=category)中安全与合规类别提供了相关项目和工具的清单。

云原生组织可以利用 Kubernetes 策略来定义操作控制和其他安全领域之间的映射，目的是实现治理和合规流程的自动化。通过采用基于策略的操作，企业可以实现他们的目标，即在不影响开发人员的灵活性和自助服务的情况下更加安全和合规。