红帽全球峰会概述
Kubernetes（也称 K8s 或 “Kube”）是一个开源的容器编排平台，可以自动执行容器化应用的部署、管理和扩展。Kubernetes 将 Linux 容器组织成集群，并使用应用编程接口（API）来连接容器化的微服务。由于 Kubernetes 部署中涉及的任何层面或服务都有存在漏洞的风险，因此保护 Kubernetes 集群的安全流程可能会比较复杂。
有些团队对 Kubernetes 安全防护采取以容器为中心的方法，主要侧重于保护容器镜像和容器运行时的安全，而也有些团队则选择 Kubernete 原生安全防护，采用更综合的方法从 Kubernetes 提取上下文，并使用内置的 Kubernetes 功能和控制机制来实施基于风险的安全最佳实践，并覆盖整个应用开发生命周期。Kubernetes 原生安全防护还可以解决 Kubernetes 特有的风险和漏洞，例如配置错误的 Kubernetes RBAC 策略、不安全的 Kubernetes 控制平面组件，以及不当使用的 Kubernetes 机密等。
为什么 Kubernetes 安全防护很重要？
作为一种相对较新的技术，Kubernetes 近年来越来越普及，但安全方面的投入并不一定能跟上脚步。再加上安全意识欠缺和一直存在的技能差距，安全事件可能会造成毁灭性的后果。安全问题常常会导致应用开发和部署延迟或拖慢。当 Kubernetes 和容器安全问题导致安全事件发生时，也会对企业产生营收或客户损失、员工解雇以及业务运营方面的其他影响。
Kubernetes 和容器化能够实现速度更快、可扩展性更强的 DevOps 流程，但也带来了额外的安全风险。随着部署的容器越来越多，攻击面也会越来越大，查明哪些容器有漏洞或哪些配置有错误也变得越来越具有挑战性。
常见风险和挑战
Kubernetes 容器集间联网
Kubernetes 的一大优势是具有广泛的网络配置选项，可以控制集群中的容器集如何进行通信。不过，Kubernetes 默认不限制集群内不同容器集间的网络通信，因此每个容器集都能与其他容器集通信，直到单独分配了相关的网络策略为止。这意味着，一旦某个容器集被不法分子入侵，它就能被用作载体来攻击集群中的其他容器集。Kubernetes 网络策略是使用 YAML 文件编写的，这对于不熟悉 YAML 语法或缺乏经验的团队来说可能是具有一定难度，这也是 Kubernetes 网络策略实施困难的诸多原因之一，团队可能会为了提高速度而放弃网络分段。
配置管理
配置错误通常是由人为错误和缺乏自动化安全扫描而引起的，这会给 Kubernetes 环境带来严重风险，并有可能导致数据泄露。由于容器的动态特性，识别配置错误和保持一致的安全态势或许颇有难度。Kubernetes 本是为了优待速度和可操作性而开发的，因此默认配置通常是开放的/不受限制的。这使得企业或机构很容易受到攻击。
软件供应链问题
软件供应链中的安全问题，例如应用组件易受攻击、访问控制不足、软件物料清单（SBOM）欠缺、CI/CD 管道薄弱以及策略执行不一致等，也是企业或机构的一大痛点。云原生 Kubernetes 环境的一大特征是软件供应链的无序扩张，需要一套独特的控制措施。软件供应链安全防护必须从个人开发环境（IDE）开始，并且一直延伸到运行时环境。它需要考虑所有内容（源代码、镜像、工件）、工具（开发人员和安全防护）以及供应链中涉及的人员。源代码分析、访问控制、认证和 SBOM 只是软件供应链安全防护方面众多安全考虑因素中的一小部分。
安全防护左移
与软件供应链安全密切相关的是安全防护左移的挑战。安全防护左移这个概念是指将 Kubernetes 的安全防护工作移到容器生命周期的早期阶段。这并非易事，因为安全防护左移需要开发人员成为安全防护用户，拥有在其工作流中做出安全防护决策所需的知识和工具。然而，安全防护左移带来的业务效益是巨大的。这是实施 Kubernetes 和容器安全防护的主要方式。在构建阶段解决发现的安全问题越多，运行时可能出现的问题就越少，进而项目延迟也会越少。
运行时检测和响应
在 Kubernetes 环境中运行的容器化应用中，运行时威胁向量的数量对于负责检测和应对此类问题的团队来说是一个挑战。不法分子可以利用许多手段来获得 Kubernetes 环境初始访问权限，执行恶意代码，提升权限，实现持久存在，逃避检测和进行横向移动，从而导致数据删除或泄露、拒绝服务或资源劫持。您可以阅读我们有关适用于 Kubernetes 的 MITRE ATT&CK® 框架的博客文章，了解这一主题的更多信息。
Kubernetes 基础架构的安全防护
Kubernetes 的许多层面，从控制平面组件（如 API 服务器、kube-scheduler、kube-controller-manager 和 etcd 等）到运行容器化工作负载的工作节点组件，都提出了自己的安全挑战。这些服务都必须进行安全地配置，才能为运行应用提供一个坚固的集群环境。除此之外，您是打算将 Kubernetes 作为自助式服务运行，还是使用全托管式的云服务，也会决定您必须以何种方式保护 Kubernetes 各种组件的安全。例如，在自助式环境中，除了节点组件外，您还要负责所有的控制平面组件。在使用托管式 Kubernetes 服务时，安全防护责任由服务提供商和您（客户）共同承担。这又增添了一个挑战。
全阶段安全保障
容器化和 Kubernetes 有几个天生的安全优势，可以帮助团队解决与容器安全问题相关的风险。例如：
- 在发现容器在运行时存在安全问题时，通常会选择在构建阶段修复并重新部署容器，而不是在运行时进行更新或修补。这一特性称为不变性，可在容器行为和异常行为检测方面实现更好的可预测性。
- 网络策略可以对容器集或容器集组进行分段，而准入控制器则可应用策略来实现更好的监管。
- 基于角色的访问控制（RBAC）可以为用户和服务帐户分配特定的权限。
- Kubernetes 机密可以更好地保护诸如加密密钥等敏感数据。
然而，Kubernetes 并不是一个安全防护平台，因此团队必须在 Kubernetes 环境的每一层以及容器和应用生命周期的每个阶段实施风险评估和漏洞排查。为了有效提升 Kubernetes 安全性，您必须在构建、部署和运行时阶段实施最佳实践，并尽可能利用 Kubernetes 原生安全防护控制。
红帽能为您做些什么？
作为开源容器技术的领导者，红帽可以帮助您加强对 Kubernetes 安全防护最佳实践的认识，让您的容器实施变得更加安全。为了帮助团队更高效地识别和解决 K8s 安全问题，红帽可提供 Kubernetes 原生解决方案，将安全防护嵌入到容器生命周期中，并使 DevOps 团队能够构建和部署生产就绪型应用。
Kubelinter 由 StackRox 创立并于 2021 年被红帽收购，是一款开源静态分析工具，可用于识别 Kubernetes 部署中的配置错误和编程错误。KubeLinter 运行一系列测试来分析 Kubernetes 配置，识别错误，并为所有不符合安全最佳实践的内容生成警告。
红帽服务互连配备了内置安全防护功能，默认情况下可在集群和云中进行扩展，同时可在服务之间提供值得信赖的通信链路。红帽服务互连还允许跨传统平台、容器平台或 Kubernetes 平台进行灵活开发，为您的开发人员提供更多用于构建、更新和部署下一代业务应用的选择。
红帽® Kubernetes 高级集群安全防护（ACS）可使企业或机构安全地构建、部署和运行云原生应用。ACS 可作为自助管理或全托管式 SaaS 解决方案提供，能够保护所有主要云和混合环境中容器化工作负载的安全，使 DevOps 和 InfoSec 团队能够开展安全防护工作，降低运维成本，并提高开发人员生产力。
