Kubernetes 原生安全防护的优势

确保容器安全主要有 2 种方法： 以容器为中心的安全防护和 Kubernetes 原生的安全防护。 

以容器为中心的平台在容器级别运行，主要侧重于保护容器镜像和容器运行时。这些工具在容器级别本身提供控制，例如，使用内联代理或 shim 来控制跨容器通信。

Kubernetes 原生安全防护则在 Kubernetes 层上运行。它从 Kubernetes 派生上下文，并将策略推送给 Kubernetes，让 Kubernetes 执行。

Kubernetes 原生安全防护依赖于与 Kubernetes 的深度集成，以此来拉取上下文并借助 Kubernetes 的原生控制。这种架构通过提供丰富的上下文和智能分析，以及检测 Kubernetes 特定的威胁，在 2 个关键方面提高了安全性。

Kubernetes 原生安全防护奉行的原则是：当安全防护与管理容器化应用的系统保持一致时，安全防护才能得到最有效的实现。 

一个安全平台必须具备以下特性，才会被视为 Kubernetes 原生：

• 直接与 Kubernetes API 服务器集成，从而能获得关于 Kubernetes 工作负载和基础架构的第一手信息
• 评估 Kubernetes 软件本身的漏洞
• 以 Kubernetes 对象模型中的资源（包括部署、命名空间、服务、容器集等）为基础，建立策略管理等安全功能
• 分析 kubernetes 特定工件（例如，工作负载清单）和配置中的声明性数据
• 尽可能使用内置的 Kubernetes 安全功能来处理执行，以实现更高的自动化、可扩展性和可靠性
• 部署并作为 Kubernetes 应用来运行，包括集成和支持云原生工具链中的常用工具

Kubernetes 原生安全防护不仅提供了对您的容器配置的可见性，还提供了对 Kubernetes 部署的可见性。 

了解您的工作负载是否隔离以及隔离的方式十分重要。默认情况下，Kubernetes 允许所有部署与命名空间内外的所有其他部署通信。深入了解网络策略设置（最好是用可视化格式，而非阅读 YAML 文件内容）可以突出哪些工作负载未被隔离。

要了解您的整体安全态势，您必须确保 Kubernetes 配置（例如角色权限、密钥访问、允许的网络流量和控制面板组件上的设置）都已锁定，遵循最佳实践，并限制为应用运行所需的最小特权。

与其他计算资源一样，许多组织选择在云中运行 Kubernetes。关于如何在云平台运行 Kubernetes，您有多种选择：

• 自管理式 Kubernetes
• Kubernetes 商业发行版
• 托管式 Kubernetes 服务

无论您选择哪种模型，您都和云提供商"共同承担"着保护部署安全的责任。虽然典型的责任共担模型可以应用于 Kubernetes——尤其是托管式 Kubernetes 服务，但如何界定安全责任，有时候会令人十分困惑。

使用托管式 Kubernetes 服务时，云提供商管理 Kubernetes 控制平面，其中包括用于控制集群的 Kubernetes 组件，以及一些有关集群状态和配置的数据。

服务通常包括设置控制平面、支持这些节点的冗余，通常包括在不同区域运行这些节点，以防止因为云提供商的基础架构部分中断而停机。

通常，云提供商：

• 会使 Kubernetes 保持最新状态
• 关于持续修补控制平面的漏洞
• 可能提供修补节点操作系统的补丁，通常取决于您选用的操作系统
• 通常会为节点提供容器优化型操作系统镜像
• 有时会提供漏洞扫描器，但您必须创建策略，例如使用许可控制器根据扫描结果允许/拒绝

客户始终有责任保护 Kubernetes 工作负载的安全，包括以下这些安全方面：

• 容器镜像：它们的源、内容和漏洞
• 部署： 网络服务、存储、特权
• 配置管理：角色、组、角色绑定、服务帐户
• 应用：密钥管理、标签、注释
• 网络分段：集群中的网络策略
• 运行时：威胁检测和事故响应

Kubernetes 原生安全防护平台提供几大关键优势。 

增强保护

Kubernetes 原生安全防护通过绑定 Kubernetes 的声明性数据来发现 Kubernetes 和容器中的漏洞，从而提供更丰富的智能分析。 

更高的运维效率

使用相同的基础架构管理和安全框架可以降低 Kubernetes 学习难度，Kubernetes 上下文也能支持实现更快的威胁检测和风险优先评估。

降低运维风险

使用 Kubernetes 原生控制可以确保安全防护兼具 Kubernetes 的速度和可扩展性。通过在 Kubernetes 中嵌入策略，因此外部控制和编排器之间不会产生冲突。

Kubernetes 原生安全防护可帮助减少因配置不一致、缺乏协调和用户错误导致的运维问题。

大部分用户的 Kubernetes 学习曲线会让他们很容易犯错，包括使用 Kubernetes 基于角色的访问控制（RBAC）授予更高的权限，例如授予用户或帐户全面的集群管理权限，或允许部署获取密码（即使是在不需要密码时），导致 Kubernetes 密钥被不必要地暴露。

Kubernetes 原生安全平台可以自动、持续不断地识别这些错误配置。

直接将安全控制嵌入到 Kubernetes 中也消除了使用独立控制软件的风险——在出现故障时，该软件要么可能无法打开，在未启用安全防护的情况下允许所有流量通过，要么无法关闭，导致断开所有应用流量。

由 Kubernetes 编排器强制执行策略控制意味着安全防护可以即时获得 Kubernetes 本身的所有可扩展性，以及它所包含的一系列策略执行选项。 

相反，使用内联代理或 shim 来实施，则会导致出现单点故障、可扩展性问题和性能限制。

使用 Kubernetes，您可以（例如）使用网络策略来分段流量，使用许可控制器对发送到 Kubernetes API 服务器的请求应用策略，使用密钥来保存敏感型凭证，以及使用基于角色的访问权限控制（RBAC）来授予某些用户和服务帐户使用某些功能的权限。

您还可以使用额外的标准化工具，例如依附于容器网络接口（CNI）的网络插件和 Kubernetes 原生安全防护平台，并根据需要更改这些额外的工具。

通过提供单个统一平台来置备和运维基础架构服务，Kubernetes 简化并统一了应用开发和运维团队的工作流程。 

当您部署 Kubernetes 原生安全平台时，同样的整合方法（每个人都使用相同的事实来源和相同的基础架构）也可以扩展用到安全防护上。 

这种方法可以缩短学习曲线，支持实现更快的分析和补救，从而节省时间和资金。

如果 DevOps 和安全团队使用不同的工具，他们的配置方式很容易出现冲突。 

DevOps 团队可以指定允许在 2 个节点之间通信的 Kubernetes 网络策略，安全防护则可以通过单独的控制软件实现控制，拦截该流量。

查看 Kubernetes 中的设置，DevOps 团队就会知道应用要在流量流动的情况下工作，如果他们看不到独立的控制软件所施加的控制，就很难明白应用为何会出现故障。

如果 DevOps 和安全防护团队使用相同的结构来构建和交付容器化应用，以及保护它们的安全，他们要了解的接口、工具和模型的数量就会更少。 

DevOps 使用 Kubernetes 清单文件来定义特定应用所需的资源。使用这些相同的资产来收集安全上下文和应用策略，可以降低复杂性并提高安全防护成果。 

Kubernetes 原生安全防护将 Kubernetes 作为安全策略事实来源，因此所有人（包括安全、运维团队、DevOps 和站点可靠性工程（SRE）团队）都将使用相同的事实来源。 

此外，安全问题直接映射到这些团队日常使用的 Kubernetes 对象和资源，有助于进一步简化运维。

通过使用 Kubernetes 原生防护执行您的安全策略，可避免因使用独立的安全软件而到带来的运维风险。

容器在许多方面都会让云原生应用的安全防护变得更复杂，包括安全事件可能非常分散、容器产生大量要处理的数据，再加上它们的寿命短，会导致传统的事件响应过时。

Kubernetes 原生安全防护让您能够更准确地检测对您容器的威胁，降低在您的环境中高效应用安全防护所花费的时间和精力。

在 Kubernetes 上下文中，预期行为一目了然。因此，Kubernetes 原生安全防护可以以更高的精确度识别异常，以便您更放心地使用强制执行选项，比如终止某个容器集。

同时，使用 Kubernetes 上下文还可以减少误报和警报疲劳。

Kubernetes 原生安全防护让用户能够根据风险来处理安全任务。 

您的部署中可能包含多处策略违规，但您该从哪里开始解决？Kubernetes 上下文同样可以提供帮助。 

它将 Kubernetes 元数据的各种信息组合在了一起，包括集群是处于开发阶段还是生产阶段、它是否在互联网上公开、应用有多重要，以及目前是否有可疑流程在其上运行，能清晰地让您知道团队目前需要注意些什么。 

检测 Kubernetes 特定的漏洞，特别是那些让 Kubernetes API 服务器置于危险境地的漏洞，对于预防、识别和补救尤为关键。Kubernetes 原生安全防护工具可以自动识别这些漏洞。

与 Kubernetes API 服务器集成，可以为在 Kubernetes 集群中运行的容器和 Kubernetes 资源（例如部署、守护进程设置、服务、容器集和其他资源）提供安全监控。

Kubernetes 部署的完全开放特性是另一个威胁因素。因为 Kubernetes 首先是一个基础架构运维平台，所以为了实现简单运维，默认没有对所有组件实施安全保护。 

使用 Kubernetes 网络策略来限制通信，这是保护 Kubernetes 部署安全的另一大关键因素。Kubernetes 原生安全防护平台可以自动为网络活动设定基准线、确认服务您的应用需要使用哪些通信路径，并创建正确的 YAML 文件来缩小网络访问权限范围。

通过 Kubernetes 原生安全防护平台中的自动安全设置，您将能够持续识别并阻止 Kubernetes 层中的威胁

Kubernetes 原生安全防护也支持实现高可移植性和重复使用。在 Kubernetes 运行的所有位置使用单个标准化方法，可以确保策略在所有环境中得到一致使用。 

Kubernetes 原生安全防护让用户能指定单个配置，例如网络策略，将其应用于部署中的所有容器集，而不是在集群中的每个主机上配置系统级控制。 

通过将策略绑定到 CI/CD 系统和 Kubernetes 许可控制器框架，组织能够更容易在软件开发生命周期的早期阶段使用控制策略，以防在运行时出现漏洞。 

使用 Kubernetes 结构（例如许可控制器）可以将安全防护和 Kubernetes 工具链紧密绑定在一起。