利用零信任原则保障 Kubernetes 环境访问安全

随着 Kubernetes 集群和容器化应用程序越来越多，组织将日益暴露在运营一两个集群时并不明显的安全风险之下。因此，平台团队需要为整个 Kubernetes 基础设施的集群和应用实现集中式的企业级安全与控制。

本文最初发布于 The New Stack 博客。

现代 IT 环境变得越来越动态。举例来说，Kubernetes拓展了许多组织的可能性边界。开源技术在容器化应用程序自动部署、扩展性和管理方面有诸多好处。特别地，IT 团队可以利用其强大的功能、有效性和灵活性快速开发现代应用程序并大规模交付。

然而，为 Kubernetes 环境安全强化实践提供保障的流程面临着越来越大的挑战。随着分布在本地数据中心、多公有云提供商和边缘位置的 Kubernetes 开发和生产集群数量越来越多，这种相对较新的动态操作模型给访问控制带来了很大的复杂性。

由于大部分团队都有多个集群在多个位置运行——通常使用不同的发行版，有不同的管理界面——企业 IT 部门需要考虑到，开发、运营、承包商和合作伙伴团队需要不同级别的访问权限。

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

Kubernetes 集群零信任访问

零信任是一个安全模型，它会自动假设所有在网络中或网络间进行操作的人、系统和服务都是不可信任的。零信任正成为预防恶意攻击的最佳技术。以身份验证、授权和加密技术为基础，零信任的目的是持续验证安全配置和态势，确保整个环境值得信任。

以下是对 Kubernetes 基本工作原理的一个简单说明：

• 对于每个集群，Kubernetes 控制平面的核心是 Kubernetes API 服务器。

• 可以调用 API 来查询和操作所有 Kubernetes 对象的状态。

• Kubernetes 对象包括命名空间、pod、配置信息等。API 访问控制是管理 Kubernetes 访问、实现零信任的关键功能。保障 Kubernetes 集群访问安全的第一步是通过传输层安全（TLS）来保护流入/流出 API 服务器的流量。

图片来源：kubernetes.io

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

• 启用所有地方的 TLS。

• 使用 API 服务器的私有端点。

• API 服务器使用第三方身份验证。

• 关闭 API 服务器的防火墙入站规则，确保它是隐形的，不能直接从 Internet 访问。在确保传输层安全后，Kubernetes 还要包含必要的钩子，用于实现零信任，并控制对每个 Kubernetes 集群的 API 服务器的访问。这些钩子代表了 Kubernetes 坚固安全态势的 4 个关键领域：

• 身份验证

• 授权

• 准入控制

• 日志和审计

Kubernetes 身份验证

在零信任原则下，所有与 Kubernetes 集群关联的用户账号和服务账号在执行 API 调用之前都要进行身份验证。有许多安全模块和插件可以保证 Kubernetes 平台在团队首选的身份验证系统下有效运行：

• HTTP Basic Auth

• 身份验证代理（为支持 LDAP、SAML、Kerberos 等）

• 客户端证书

• 无记名令牌（Bearer tokens）

• OpenID Connect 令牌

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

Kubernetes 授权

任何用户账号或服务账号一旦通过身份验证就可以访问 Kubernetes 集群并执行任何可能的操作，这种情况一定要减少。零信任的思想是，只有当通过身份验证的用户有必要的权限完成所请求的动作时，才会对请求授权。对于发起的每一个请求，该模型都要求指明用户名、动作和受影响的 Kubernetes 集群对象。

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

• 基于属性的访问控制（ABAC）根据用户、环境和资源属性的组合动态进行访问授权。

• 基于角色的访问控制（RBAC）根据用户在组织中的角色（如开发人员、管理员、安全员等）进行访问授权。组织最常用的方式是 RBAC，因为它很实用，管控也比较简单，而且提供了大多数情况所需的粒度。在行业中，常见的做法是启用最小权限的 RBAC。

ABAC 提供了额外的粒度，但也需要额外的时间和资源来定义并做适当的配置。然而，ABAC 方法的问题排查更具挑战性。因此，常见的做法是启用最小权限的 RBAC。

Kubernetes 准入控制

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

目前，Kubernetes 内置的各种准入控制器为团队执行策略及实现各种操作提供了大量的选项。动态控制器可以快速修改请求，以满足既定规则集的要求。例如，ResourceQuota 准入控制器可以监视入站请求，确保它们不会违反 ResourceQuota 对象中列出的命名空间约束。要了解更多信息，可查阅文档“准入控制器的用法”。

Kubernetes 日志和审计

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

审计等级有 4 种类型：

• None —— 不记录这个事件

• Metadata —— 记录请求元数据

• Request —— 记录事件元数据和请求

• RequestResponse —— 记录事件元数据、请求和响应除了指定审计等级，团队还可以控制被审计事件的存储位置。日志后端会将事件写入集群的本地文件系统，然后由 Webhook 后端将审计事件发送到一个外部日志系统。

扩展零信任架构

虽然上面介绍的方法和实践可以提供创建零信任环境的能力，但当要管理的 Kubernetes 集群很多时，恰当地配置和调整所有这些元素将变得更具挑战性。当涉及多工作负载和 Kubernetes 发行版时，情况会变得尤其复杂。这不是一项新挑战，是如今许多公司都面临的问题。

例如，让我们考虑这样一个情况。公司管理着 100 个 Kubernetes 集群——从开发到 QA，再到过渡，然后生产——而且，这些集群要在地理上靠近其全球客户群，以便他们的应用程序可以处理实时的视频和音频数据流。

要确保 Kubernetes 集群用户访问安全，公司需要解决以下三个问题：

1. 假如该公司有几百名开发人员和几十名 IT 运维人员，每个集群添加或删除用户都需要手动完成，那么这项艰苦的工作所解决的问题会比所导致的问题还多。

2. 如果发生意外事件，则修复时间至关重要。如果访问方法要耗掉问题排查人员几分钟的时间才允许他登录到受影响的集群，那么问题可能会加重。

3. 由于日志分散在 100 个集群里，所以不大可能提供审计和合规性报告的全局视图。

平台团队注意事项

在企业平台团队的众多目标中，其中一个是使全球的分布式 IT 团队能够集中管理用户对其所有集群的访问。目的是，既有效地保护和管理对 Kubernetes 基础设施的访问，又大幅简化审计日志和合规性报告。

平台团队应考虑实现 Kubernetes 零信任访问，确保之前介绍的最佳实践得以应用和执行，从而保证整个 Kubernetes 环境的安全。避免手动在每个集群上应用最佳实践，那样可以大幅减低 IT 组织在大规模操作 Kubernetes 时的风险。

平台团队在设计 Kubernetes 零信任访问时应考虑以下三个方面的收益：

1. 使 RBAC 超级灵活：如果一名团队成员的角色变了，那么访问权限应该自动更新，这样，任何人的权限都不会超出或少于他的角色。

2. 使访问快速简单：通过安全单点登录让授权用户可以无缝访问，消除访问任何集群的延迟。

3. 即时场景凭证：授权用户的服务账号应该在用户访问时在远程集群上即时创建，并在用户登出后自动删除，从而避免出现证书过期的情况。随着 Kubernetes 集群和容器化应用程序越来越多，组织将日益暴露在运营一两个集群时并不明显的安全风险之下。因此，平台团队需要为整个 Kubernetes 基础设施的集群和应用实现集中式的企业级安全与控制。

原文链接：

Securing Access to Kubernetes Environments with Zero Trust