Kubernetes 是当今许多公司采用的容器编排平台，它的实施需要对其生态系统有一定的了解，以便部署一个准备好用于生产的集群。然而从原则上来说，Kubernetes 并不是一个安全的平台，因为它缺乏处理大多数与安全相关任务的本地工具。 因此，Kubernetes 的实施工作原理或工具至关重要，这个过程也需要包括运维、开发、安全等团队的共同合作，从而能够在短时间内以最快的速度发现异常，并提高编排器及其资源的安全级别。在本文中，我们将会一起讨论保护集群的安全原则。
Pre-Commit Hooks
DevSecOps 的主要目标就是通过尽早在持续集成流水线中添加自动化流程，从最大程度上减少对生产的影响，这也是当下公认的 DevSecOps 原则。因此，企业也开始引入“安全左移”的做法，来促进开发、安全和运营团队之间的共同协作，通过将安全和测试过程转移到软件开发生命周期的左侧。从添加预提交（Pre-commit）开始，在开发周期的早期确保应用程序安全。
最近几年出现了几种工具来促进这种集成，以完成以下任务：
- 格式化 YAML 文件代码
- 检测 Kubernetes 资源配置中的异常
- 强制应用配置和安全策略以保障良好的开发实践
- 在提交任何源代码之前检测敏感数据
以下是控制 YAML 定义文件的三个不错的工具示例：
- YAML lint
- Checkov
- K8svalidate
持续集成检查
预提交测试（Pre-commit test）通常被用来促进团队合作，但是 DevSecOps 团队很少会强制执行预提交测试。在某些情况下，pre-commit 任务的实现可能很麻烦，尤其是对于大型团队而言。不过这些测试仍然是必要的，因此必须在持续集成过程中推进。Pre-commit 任务可以分为两个部分，首先对代码进行格式化，然后对代码进行扫描来验证配置文件的一致性。
镜像扫描
由于许多人认为官方镜像是百分之百安全的，因此在部署之前往往会忽略扫描镜像这个步骤，但扫描镜像很重要，因为新的漏洞层出不穷。同时更新任何具有安全漏洞的系统来限制恶意攻击者的攻击范围同样也很重要。
这些扫描工作需要在容器生命周期的不同阶段执行：
- 在将镜像发布到远程镜像仓库之前，确保相关镜像在部署之前就符合安全规则
- 在容器运行期间，尽快确定需要重建的镜像来纠正新发现的漏洞
集群扫描
对 Kubernetes 集群的保护取决于公司的安全治理。应用的政策必须考虑到可访问性、维护、数据管理等。此外，更重要的是要遵守社区确定的一些规则，来确保在安装集群后立即获得良好的基本安全级别。还建议定期扫描 Kubernetes 集群，以便在其运行时识别任何与配置相关的已知异常。
安全上下文
Kubernetes 安全上下文遵循最小权限原则：对应人员应当只获得执行任务所需的权限。安全上下文是一种允许管理员根据每个资源定义安全相关参数的工具，它允许每个资源获得访问主机服务器上的资源所需的特定权限，同时拒绝访问它不特别需要的资源。在 Kubernetes 上下文中，安全上下文定义了 pod 中各个容器的权限。
管理安全上下文需要对集群及其安装和生态系统进行高级管理和理解，尽管它们的实现很复杂，但这些措施仍然是限制任何 pod 或容器操作的非常有效的方法。
基于角色的访问控制
利用 Kubernetes 基于角色的访问管理 (RBAC) 是保护在平台上运行的集群和应用程序的基本第一步。RBAC 原则非常简单：根据用户身份定义谁可以访问什么。 Kubernetes 有一个有效的粒度来管理对不同资源的访问：
- 用户访问
- 应用程序访问
- 用于定义权限的角色仅限于单个命名空间的资源
- 集群角色以应用集群级别的限制
这种粒度与外部身份提供者（如 Okta、Gmail 等）相结合，可以对访问进行非常精细的管理，从而确保对资源的控制以及可审计性。
网络政策
网络安全策略管理也是“安全左移”概念的一部分。Kubernetes 网络策略允许管理员和开发人员使用规则限制允许哪些网络流量，“左移”原则允许开发人员在不了解低级网络概念的情况下安全地访问和访问他们的应用程序。 DevOps 团队可以强制执行默认策略，开发人员可以管理特定的访问权限，从而使他们在管理应用程序方面具有一定的自主权。网络策略由部署在集群上的容器网络接口 (CNI) 控制。几个 CNI 提供了此功能，但这里有两个值得特别注意：
- Calico可能是 Kubernetes 生态系统中最著名和使用最广泛的 CNI。在免费版本中，Calico 可以将这些网络规则管理到 OSI 模型的第 3 级。
- Cilium 是一个很好的替代方案或附加组件，在 OSI 模型上提供了许多免费功能。
政策执行
Kubernetes 是一个主要基于 API 的应用程序。这种方法使得开发对这些不同资源的访问控制工具得以运用，以便对其进行审计和保护。准入控制器（Admission Controller）是 Kubernetes 客户端（例如 Kubectl）发出的所有请求的入口点。在此阶段添加检查点可以在执行所有查询之前对其进行验证，从而防止任何偏离公司安全治理的行为。
这些控制节点可用于：
- 检查是否设置了 CPU 和内存限制
- 确保用户不会更改默认网络策略
- 确保特定资源始终包含特定标签
- 拒绝特定资源的权限
- 防止使用最新标签
- 为每个新命名空间生成默认网络策略
DevOps 团队可以使用多种工具来管理这些安全规则，例如：
- Open Policy Agent (OPA) 可能是最著名的 Kubernetes 执行策略应用程序。
- Kyverno 可以使用准入控制和后台扫描来验证、变异和生成配置。Kyverno 策略与任何 Kubernetes 资源一样以 YAML 文件表示，不需要学习新语言。
建议企业的 DevOps 团队在任何 Kubernetes 集群的基本配置文件中包含这些工具之一。
运行时威胁检测
如之前所提，Kubernetes 并不是一个完全安全的平台，因为它缺乏处理大多数与安全相关的任务的本地工具，例如检测应用程序中的漏洞和监控违规行为。而异常或威胁的实时检测是任何安全治理的要点，同样对于 Kubernetes 平台也不例外。Kubernetes 在数据管理等领域的广泛使用使其安全性成为其业务运营的关键点。
过期资源
Kubernetes 是当今 DevOps 世界的主要参与者，因为它的灵活性和对生产中新功能交付有很大的影响。该工具允许开发团队提高他们的部署速度，因此需要特别注意所使用的资源，以免使用过期的资源危及集群的安全性。
有不同类型的过期资源：
- 已弃用的 Kubernetes API
- 旧的/不推荐使用的 Kubernetes 资源（如 Helm 版本）
已弃用的 Kubernetes API 不一定是安全漏洞，但它们会影响集群的生命周期，从而影响其维护。企业需要在更新集群之前在代码存储库和 helm 版本中找到已经弃用的 Kubernetes API，来避免潜在的安全漏洞。确保 Kubernetes 集群的保护还涉及扫描活动资源。作为包管理器，Helm 需要特别注意检查图表的生命周期，并遵循托管资源的每周或每月更新计划。