Kubernetes 原生安全防护的优势

复制 URL

确保容器安全主要有 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 工具链紧密绑定在一起。

试用企业级 Kubernetes
中心

红帽官方博客

获取有关我们的客户、合作伙伴和社区生态系统的最新信息。

所有红帽产品试用

我们的免费试用可让您亲身体验红帽的产品功能,为获得认证做好准备,或评估某个产品是否适合您的企业。

扩展阅读

什么是入侵检测与防护系统(IDPS)?

入侵检测和防护系统(IDPS)可以监控网络中的威胁,并采取行动来阻止检测到的任何威胁。

什么是边缘安全防护?

边缘安全防护是指通过一系列工具和实践来保护偏远位置的边缘基础架构和工作负载,而专业人员可能难以为这些地方提供现场支持。

为什么选择红帽来实现 DevSecOps?

DevSecOps 是一项非常复杂的文化转型。借助红帽产品组合的安全功能,开发人员和安全团队可以更容易在生命周期的早期阶段就将安全防护整合进来。

安全防护 相关资源

相关文章