现代 IT 环境日益动态化。例如，Kubernetes 正在突破许多 IT 组织的可能性。

开源技术在自动化容器化应用程序的部署、可扩展性和管理方面的很多好处。特别是，IT 团队正在利用其强大的功能、效率和灵活性来快速开发现代应用程序并完成大规模交付。

然而，在 Kubernetes 环境中强化安全实践的过程是一个日益严峻的挑战。随着越来越多的开发和生产 Kubernetes 集群分布在本地数据中心、多个公共云提供商和边缘位置，这种相对较新的动态操作模型为访问控制带来了极大的复杂性。

由于大多数团队都有在多个区域运行的多个集群的场景——通常具有不同的分布和管理界面——企业 IT 需要考虑到需要不同级别访问权限的开发人员、运营人员、承包商和合作伙伴团队。

鉴于 Kubernetes 的分布式和扩展性，IT 必须尽一切可能确保访问安全，以避免正在发生的错误。下面，我们将看看如何应用 Kubernetes 零信任原则来保护整个环境，如何为容器提供零信任安全性。

Kubernetes 集群的零信任访问

假设在网络中和网络之间访问的所有人员、系统和服务都是不可信的安全模型，零信任正在成为防止恶意攻击的最佳技术。基于身份验证、授权和加密技术，零信任的目的是不断验证安全配置和状态，以确保跨环境的可信。

以下是对 Kubernetes 工作原理的基本了解：

每个集群的 Kubernetes 控制平面的核心是 Kubernetes API Server。API Server 用于查询和操作所有 Kubernetes 对象的状态。Kubernetes 资源对象包括命名空间、pod、配置映射等。

控制对 API Server 的访问是管理 Kubernetes 访问和实现零信任的关键功能。保护对 Kubernetes 集群的访问的第一步是使用传输层安全性 (TLS) 保护进出 API Servre 的流量。

实现零信任的 API 服务器最佳实践：

随处启用 TLS。使用 API Server 的专用端点。对 API Server 使用第三方身份验证。关闭 API Server 的防火墙入站规则，确保它被隐藏并且不能从 Internet 直接访问。

在保护传输层之后，Kubernetes 还包括必要的钩子来实现零信任和控制每个 Kubernetes 集群的 API Server 访问。这些钩子代表了 Kubernetes 强化安全态势的四个关键领域：

验证授权准入控制记录和审计Kubernetes 身份验证

在零信任的情况下，所有与 Kubernetes 集群相关的用户级和面向服务的帐户都必须在执行 API 调用之前进行身份验证。Kubernetes 可以广泛使用安全模块和插件，以确保该平台能够通过团队首选的身份验证系统有效运行：

HTTP 基本身份验证身份验证代理（支持 LDAP、SAML、Kerberos 等）客户证书不记名令牌OpenID Connect 令牌Webhook 令牌授权

身份验证的常见最佳实践包括启用至少两种身份验证方法（多因素身份验证或 MFA）和定期轮换客户端证书。

对 Kubernetes 的授权

必须允许每个具有身份验证访问权限的用户或服务帐户在 Kubernetes 集群中执行任何可能的操作。零信任的想法是，只有经过身份验证的用户具有完成所请求操作的必要权限，才能授权请求。对于发出的每个请求，此模型将需要指定 Kubernetes 集群中的用户名、操作和受影响的对象。

Kubernetes 支持多种授权方法，包括：

基于属性的访问控制 (ABAC) 根据用户、环境和资源属性的组合动态地授权访问。基于角色的访问控制或 RBAC，根据用户在组织中的角色（例如开发人员、管理员、安全人员等）授权访问。

组织最常使用 RBAC，因为它的实用性允许更轻松的管理控制并提供大多数用例所需的粒度。在行业内，以最低权限启用 RBAC 是很常见的。

ABAC 可以提供额外的粒度，但需要额外的时间和资源来正确定义和配置。但是，使用 ABAC 方法解决问题可能更具挑战性。因此，通常以最低权限启用 RBAC。

Kubernetes 准入控制

准入控制器提供了一种实现业务逻辑的方法，以改进 Kubernetes 的零信任方法。准入控制器的目的是使系统能够自动处理创建、修改、删除或连接到 Kubernetes 对象的请求。可能需要启用多个准入控制器以满足您组织的需求，如果其中任何一个拒绝特定请求，系统也会自动拒绝它。

当今可用的各种内置准入控制器为团队提供了许多用于执行策略和实施各种操作的选项。动态控制器可以快速修改请求以遵守已建立的规则集。例如，ResourceQuota 准入控制器观察传入的请求并确保它们不违反已在命名空间的 ResourceQuota 对象中列出的约束。

Kubernetes 的日志记录和审计

审计功能提供了集群内执行的操作的跟踪记录，这对于 Kubernetes 安全态势至关重要。这些功能可以跟踪任何用户、应用程序和控制平面本身的任何操作。

有四种不同类型的审计级别：

无 – 不记录此事件元数据 – 记录请求元数据请求 - 记录事件元数据和请求RequestResponse – 记录事件元数据、请求和响应

除了指定审计级别之外，团队还可以控制记录审计事件的位置。当日志后端将事件写入集群的本地文件系统时，webhook 后端会将审计事件发送到外部日志系统。

扩展零信任架构

虽然上述不同的方法和实践提供了创建零信任环境的能力，但当 Kubernetes 的足迹扩展到几个集群之外时，正确配置和对齐这些单独的元素成为一个更重大的挑战。当涉及多个工作负载和 Kubernetes 分布时，事情会变得特别复杂。这一挑战并不新鲜，但如今已为许多公司所共有。

例如，让我们考虑一个场景，一家公司管理着 100 个 Kubernetes 集群——从开发到 QA 到预生产再到生产——并且这些集群需要在地理位置上靠近其全球客户群，以便应用程序能够处理实时视频和音频数据。

在确保用户安全访问 Kubernetes 集群方面，该公司可能会遇到三个问题：

假设这家公司有几百名开发人员和几十名 IT 运维人员，手动在每个集群中添加和删除用户的艰巨任务会产生比解决的问题更多的问题。如果发生紧急事件，补救所需的时间至关重要。如果访问方法让那些对问题进行故障排除的人只需要几分钟才能登录到受影响的集群，那么问题可能会成倍增加。由于日志数据分布在 100 个集群中，因此可能无法全面了解审计和合规性报告。平台团队的注意事项

企业平台团队的众多目标之一是帮助全球分布的 IT 团队从一个中心位置管理其所有集群中的用户访问。其目的是有效地保护和管理对 Kubernetes 基础设施的访问，同时使审计日志记录和合规性报告更加简单。

平台团队应考虑为 Kubernetes 实施零信任，以确保应用和实施前面描述的最佳实践来保护整个 Kubernetes 环境。通过消除在每个集群上手动应用最佳实践的需要，IT 组织可以以更低的风险大规模运行 Kubernetes。

在为 Kubernetes 设计零信任时，平台团队需要考虑以下三个好处：

使 RBAC 超灵活：如果团队成员更改角色，访问权限应自动更新，这样任何人都不会拥有过多或过少的访问权限。快速和简化可访问性：通过安全的单点登录为授权用户提供无缝访问，从而消除对任何集群的延迟访问。即时场景的凭据：授权用户的服务帐户应在具有“即时”访问权限的远程集群上创建，并在用户注销后自动删除，从而消除凭据过期的机会。

一两个集群时并不会存在明显的安全风险，但随着 Kubernetes 集群和容器化应用程序数量的增加。因此，平台团队需要在其整个 Kubernetes 基础架构中为集群和应用程序启用集中的企业级安全和控制。

关键词： 身份验证 应用程序 开发人员 访问控制 命名空间