Kubernetes的零信任基础架构

​译者 |胥磊 审校 |孙淑娟 近年来，安全模型也得到了越来越多的关注，特别是随着2019年新型冠状病毒的爆发，其更是迅速成为所有人关注的焦点。突如其来的居家使很多公司的工作模式从现场办公向远程或混合模式转变。零信任安全就成为这些准备向远程或混合办公模式转变的公司关注对象，同样其他机构，平台以及基础设施也都需要关注这些安全原则，特别是对于部署了Kubernetes的组织，采用零信任架构对于确保其所有环境的安全性是至关重要的。

Kubernetes安全挑战

如今各个行业都承受着无处不在的压力，他们需要IT公司能够向其交付运行更快，效率更高，规模更大的软件。为了寻求强大的可移植性和灵活性，许多IT公司都已经转向使用Kubernetes (K8S)来满足这些市场需求。同时也要看到虽然K8S是IT公司高效，大规模交付软件的优秀解决方案，但其本身也存在安全挑战和漏洞。仅仅因为 Kubernetes 是一个相对较新的系统，它就成为对网络攻击者来说颇具吸引力的猎物，再加上其操作模式的动态特性，如果不采取必要的安全措施，很容易给坏人留下渗透的空间。 Shadowserver 基金会的研究人员发现，仅今年一年就有38万台开放的 Kubernetes API 服务器暴露在互联网上。虽然这些服务器目前还只是被识别为暴露并没有受到攻击，但这个惊人数字的背后隐藏着API 服务器的脆弱性和潜在的危险性。而事实也是如此，Salt Security 的2022年 API 安全状态显示，34% 的受调查企业并没有 API 安全策略，尽管其中95% 的企业在过去12个月中 API 安全受到威胁。

零信任：Kubernetes 的安全救星？

面对这种可怕的局面，行业需要有一种新的解决方案来加强Kubernetes的部署，由此引发的另外一个问题就是，如何在确保强大的安全态势的同时，还能继续发挥K8S的众多优势。对许多人来说答案很明确–那就是零信任安全。

什么是零信任安全？

零信任安全模型是 Forrester 在2009年首次提出的，一经提出，这个开创性的概念就彻底颠覆了网络安全的标准。现有的传统安全模型是“信任，但要验证”，而零信任安全则改变了这种理念，取而代之的是“永远不要信任，始终要验证”，这就意味着所有用户和设备必须不加区分地持续检查和验证。 过去传统的安全模型都是为了确保边缘的安全。一旦用户通过验证，他们就被授予进入网络的权限，而只要他们进入了网络所有操作通常都会受到信任！而零安全信任则意味着永远不会有完全信任的时刻。恰恰相反其总是假设用户和设备受到了威胁，必须通过不断地进行授权、身份验证和认证，才能保持与网络的连接或采取任何操作。通过这种方式，零信任安全可以帮助组织始终保持谨慎，永远不放松警惕，从而防御坏人的渗透。

Kubernetes 的零信任架构

零信任安全为Kubernetes的安全挑战提供了真正的解决方案，而实现合规本身也带来了新的挑战。这里着重需要指出的是零信任安全只是一组目标而不是一个精确的工具，因此有许多不同的方法可以实现零信任体系结构。 那么，如何将零信任原则应用于 Kubernetes呢？下面从如何保护 Kubernetes API 服务器开始，服务器是每个 Kubernetes 集群控制层面的核心。因为这个 API 服务器用于控制所有 Kubernetes 对象，所以确保安全的 API 访问是保护受控 Kubernetes 访问的安全基石，从而实现零信任 Kubernetes。 为了控制和保护 API 服务器，首先就要控制所有的输入和传输出的流量，这些可以通过传输层安全协议(Transport Layer Security，TLS)来完成。一旦所有 API 服务器通信都得到保护，Kubernetes 就可以提供用来实现零信任安全的钩子（Hooks）。这里主要有四种类型的钩子：身份验证，授权，准入控制，审计和日志记录。它们对成功实现 Kubernetes 的零信任架构至关重要。

身份验证

为了坚持 Kubernetes 的零信任安全原则，第一步就是要确保所有用户和服务帐户都定期进行身份验证，这意味着在执行任何 API 调用之前需要进行身份验证。为了实现这种身份验证，可以使用如下几种安全模型和插件，如客户端证书、HTTP 基本身份验证和令牌。另外零信任模型还建议使用多维度身份验证 (MFA) 以进一步提升安全性。

授权

除了必要的身份验证之外，还需要所有用户和服务帐户必须具有授权，这也是零信任安全的一个关键原则。为了保持强健的安全性，所有的用户操作都应该受到限制，即使在身份验证之后也是如此。换句话说就是不允许用户不受限制的执行所有任务，而是要先授予他们足够的访问权限，然后来完成他们要执行的任务。 当谈到零信任Kubernetes时，所有访问Kubernetes集群的用户和服务帐户都不应该被允许执行任何操作。相反 Kubernetes 的请求只有在用户(通过身份认证)有执行请求任务的明确授权时才被允许执行。因此每个请求都应该指定请求者的用户名、被请求的操作以及该操作的效果。

准入控制

保持对所有用户和操作的可见性是零信任模型的另一个重要支柱。这就是为什么准入控制器成为了 Kubernetes 零信任架构的关键组件。使用准入控制器后，组织就可以管理所有的要创建、修改、删除或连接到Kubernetes 对象的请求。内置准入控制器可以协助组织实施操作并执行其策略，而动态准入控制器可以允许他们实时修改请求。至于更细致的安全控制方法，就是在系统中使用多个准入控制器，而且许多控制器是与 Kubernetes 部署相兼容的，例如 ResourceQuota 和 LimitRanger。

审计和日志

无论哪种安全态势，审计都是其弹性的基本组成部分。审计允许组织监控在 Kubernetes 集群中那些由用户、应用程序甚至控制层面执行的所有操作。然后，由团队决定在哪里记录这些审计事件，可以保存在本地文件系统或外部日志系统中。适当的审计和日志记录在确保 Kubernetes 基础设施符合政府的政策方面也发挥着关键作用。所以在不同的组织、机构和平台中，零信任安全正成为决定网络安全健康的关键角色，Kubernetes当然也不例外。