现代IT环境正变得越来越动态。例如，Kubernetes为许多组织突破了可能的界限。开源技术在容器化应用程序的自动化部署、可扩展性和管理方面具有许多优势。特别是，IT团队可以利用它的强大功能、效率和灵活性来快速开发现代应用程序并大规模交付它们。然而，确保Kubernetes环境强化实践的过程越来越具有挑战性。随着分布在本地数据中心、多个公共云提供商和边缘位置的Kubernetes开发和生产集群数量的增长，这种相对较新的动态操作模型给访问控制带来了极大的复杂性。由于大多数团队都有多个集群在多个位置运行——通常使用不同的分布，具有不同的管理界面——企业IT部门需要考虑开发、运营、承包商和合作伙伴团队需要不同级别的访问权限。鉴于Kubernetes的分布式和可扩展性，IT部门必须尽一切可能确保访问安全并避免错误发生。下面我们将介绍如何应用Kubernetes零信任原则保护整个环境，为容器提供零信任安全。Kubernetes集群的零信任访问零信任是一种安全模型，它自动假设在网络内或跨网络运行的所有人员、系统和服务都是不可信任的。零信任正在成为防止恶意攻击的最佳技术。零信任基于认证、授权和加密技术，目的是不断验证安全配置和态势，确保整个环境是可信的。下面简单解释一下Kubernetes的基本工作原理：对于每个集群，Kubernetes控制平面的核心是KubernetesAPI服务器。可以调用API来查询和操作所有Kubernetes对象的状态。Kubernetes对象包括命名空间、pod、配置信息等。API访问控制是管理对Kubernetes的访问和实现零信任的关键特性。保护对Kubernetes集群的访问的第一步是使用传输层安全性(TLS)保护进出API服务器的流量。API服务器零信任的最佳实践：无处不在启用TLS。使用API服务器的私有端点。API服务器使用第三方认证。关闭API服务器的防火墙入站规则，以确保它是不可见的，并且不能直接从Internet访问。在保护传输层之后，Kubernetes还包括必要的钩子来实现零信任并控制每个Kubernetes集群对API服务器的访问。这些钩子代表了Kubernetes可靠安全态势的4个关键领域：身份验证授权准入控制日志记录和审计Kubernetes身份验证在零信任原则下，与Kubernetes集群关联的所有用户帐户和服务帐户都经过身份验证。有许多安全模块和插件可以使Kubernetes平台与您团队首选的身份验证系统有效运行：HTTPBasicAuth身份验证代理（支持LDAP、SAML、Kerberos等）客户端证书Bearer令牌OpenIDConnect令牌BrandWebhook令牌身份验证常见的身份验证最佳做法是启用至少两种身份验证方法（多因素身份验证或MFA）并定期轮换客户端证书。必须减少Kubernetes授权任何用户帐户或服务帐户访问Kubernetes集群并在通过身份验证后执行任何可能的操作的情况。零信任的思想是，只有经过身份验证的用户拥有完成请求操作的必要权限，请求才会被授权。对于发出的每个请求，模型需要指定用户名、操作和受影响的Kubernetes集群对象。Kubernetes支持多种授权方式，包括：基于属性的访问控制(ABAC)，根据用户、环境和资源属性的组合动态授权访问。基于角色的访问控制(RBAC)根据用户在组织中的角色（例如开发人员、管理员、安全员等）授予访问权限。组织最常用的方法是RBAC，因为它实用、管理相对简单，并且提供大多数情况下所需的粒度。在业界，启用最小权限的RBAC是常见的做法。ABAC提供了额外的粒度，但也需要额外的时间和资源来正确定义和配置。但是，对ABAC方法进行故障排除更具挑战性。因此，通常的做法是启用最小权限的RBAC。KubernetesAdmissionControlAdmissionControllers提供了一种实现业务逻辑的方法，可以改进Kubernetes的零信任方法。其目的是让系统自动响应创建、修改、删除或连接Kubernetes对象的请求。有时，可能需要启用多个准入控制器以满足组织的需求，如果特定请求被其中任何一个拒绝，系统将自动拒绝。目前，Kubernetes中内置的各种准入控制器为团队执行策略和实施各种操作提供了大量选项。动态控制器可以快速修改请求以满足既定规则集的要求。例如，ResourceQuota准入控制器可以监视传入请求以确保它们不违反ResourceQuota对象中列出的命名空间约束。有关详细信息，请参阅文档“准入控制器的使用”。Kubernetes日志和审计审计级别有4种：None-不记录这个事件Metadata-记录请求元数据Request-记录事件元数据和请求RequestResponse-记录事件元数据，请求和响应除了指定审计级别，Teams还可以控制审计事件的存储位置。日志后端将事件写入集群的本地文件系统，webhook后端将审计事件发送到外部日志系统。扩展零信任架构虽然上述方法和实践可以提供创建零信任环境的能力，但是当有许多Kubernetes集群需要管理时，正确配置和调整所有这些元素变得更具挑战性。当涉及多个工作负载和Kubernetes分布时，事情会变得特别复杂。这不是一个新的挑战，而是许多公司今天面临的挑战。例如，让我们考虑这样一种情况。该公司管理着100个Kubernetes集群——从开发到QA，再到暂存，再到生产——这些集群需要在地理位置上靠近其全球客户群，以便他们的应用程序可以处理实时视频和音频数据流。为保证Kubernetes集群用户访问的安全，公司需要解决以下三个问题：如果公司有数百名开发人员和数十名IT运维人员，需要手动为每个集群添加或删除用户，那么这个困难的工作将解决比它造成的问题更多的问题。如果发生意外事件，及时修复至关重要。如果访问方法需要故障排除者几分钟才能登录到受影响的集群，则问题可能会加剧。由于日志分散在100个集群中，因此不太可能为审计和合规性报告提供全局视图。平台团队注意事项企业平台团队的众多目标之一是使分布在全球的IT团队能够集中管理用户对其所有集群的访问。目标是有效保护和管理对Kubernetes基础设施的访问，同时显着简化审计日志和合规性报告。平台团队应考虑实施Kubernetes零信任访问，以确保应用和强制执行前面描述的最佳实践，以保护整个Kubernetes环境。避免在每个集群上手动应用最佳实践可以大大降低IT组织大规模运行Kubernetes的风险。平台团队在设计Kubernetes零信任访问时应该考虑以下三个好处：1.让RBAC超级灵活：如果团队成员的角色发生变化，那么访问权限应该自动更新，这样任何人的权限都不会改变。或多或少都会有他的作用。2.让访问变得简单快捷：安全的单点登录允许授权用户无缝访问，消除访问任何集群的延迟。3.即时场景凭证：授权用户的服务账号在用户访问时立即在远程集群上创建，并在用户注销后自动删除，避免证书过期。随着越来越多的Kubernetes集群和容器化应用程序，组织将越来越多地面临安全风险，而这些风险在运行一两个集群时并不明显。因此，平台团队需要在Kubernetes基础设施中为集群和应用程序实施集中的企业级安全和控制。
