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