中文
随着网络安全攻击的复杂性和数量的激增，您部署在本地环境、混合环境和多云 Kubernetes 环境中的应用面临着巨大的暴露风险。传统的安全模型是基于边界的，假定位于环境安全边界之内的用户是可信的（并且他们之间的通信是安全的）。然而，在今天的分布式环境中，有边界的安全区这一概念已不复存在，来自环境“内部”的通信可能与外部威胁一样危险。
我们将在本文中探讨采用零信任模式来保护您的 Kubernetes 基础架构的好处，以及 NGINX 如何帮助您改善安全态势。
什么是零信任？
“零信任”是一种基于身份而非位置的安全模式。它假定任何对应用、数据和设备的访问请求都可能是一种攻击，无论请求者看似是位于本地、远程或是云端。
根据“零信任”的三个核心原则——永不信任、始终验证、持续监控，每个用户、服务、应用和设备都需要持续提供身份认证和授权证明。基于动态访问策略和最小权限原则，授予限时权限。
所有通信都是加密的，并通过一个策略决策点/执行点 (PDP/PEP) 进行路由，策略决策点/执行点会对所有各方进行身份认证，并根据动态访问策略进行授权。此外，还采用审计、监控、报告和自动化功能来分析、评估和降低安全风险。
零信任如何帮助您改善安全态势
零信任可通过以下几种方式帮助您改善安全态势：
- 自动拦截未经授权的活动
- 实施访问控制以减少暴露的攻击
- 检测行为异常和危害指标
- 制定实时的最小权限策略，限制访问时间
- 持续进行身份验证和确认，以拦截进行中的攻击
对于在 Kubernetes 环境中运行的现代云原生应用来说，零信任尤为重要。松散耦合、可移植的分布式应用和服务以容器的形式在混合多云环境中运行。在这种情况下，基于位置的安全模式已无法满足需求。现在的安全必然依赖于身份和权限的持续验证、端到端加密和监控。
如何实现零信任安全
为了实现零信任原则，Kubernetes 环境必须具备一些关键的安全功能，例如对用户、应用和服务的认证、授权、访问控制、策略、加密、监控和审计。
一个可能的实现方法是将安全防护嵌入到应用本身之中。但这意味着开发人员必须实施多种安全程序——用于建立和验证信任，管理用户身份和证书，加密和解密所有通信等。他们还必须了解并整合第三方技术，例如 TLS 和单点登录 (SSO)。所有这些不仅会进一步加剧 Kubernetes 部署的复杂性，还会分散开发人员的精力，使他们无法专注于其需要（和想要！）的工作——优化应用的业务功能。
别担心，还有一个更好的解决办法，那就是将安全防护和其他非功能性需求解耦，在到 Kubernetes基础架构中实现！Kubernetes 集群的连接性工具，例如 Ingress controller 和 service mesh，可以为应用和服务之间的所有通信提供 PDP 和 PEP，无论这些通信是由用户发起的还是其他应用或服务发起的。这意味着您可以专注于核心业务功能，同时更快、更轻松地交付应用。
F5 NGINX 如何助您一臂之力
如下图所示，用于保护 Kubernetes 互联的 NGINX 解决方案包括各种您所需要的与基础架构无关的组件和工具，支持您在任何环境（本地、混合和多云）中为用户、分布式应用、微服务和 API 提供大规模的端到端保护。NGINX 解决方案由业内最流行的数据平面提供支撑，包括以下组件：
- NGINX Ingress Controller，作为 Kubernetes 的 Ingress controller，可以充当PDP/PEP的角色，与与第三方身份认证和 SSO 提供商集成。NGINX Ingress Controller 基于 NGINX Plus，可处理高级连接、监控和可视化、身份认证和 SSO，并充当 API 网关。
- NGINX Service Mesh，是一款对开发人员友好的轻量级的、开箱即用的 服务网格，可保护 Kubernetes 集群内的服务连接。NGINX Service Mesh以企业级边车的方式为每一个 Kubernetes 服务提供基于 NGINX Plus的能力，作为每个服务的PDP/PEP。
- NGINX App Protect 基于 F5 市场领先的安全技术而构建，可为现代应用和 API 提供全面保护。它采用模块化的方式，来实现部署方案的灵活性和资源的最佳利用：
- NGINX App Protect WAF—— 一个功能强大的轻量级 WAF，能够抵御 OWASP 十大安全漏洞，并帮助企业遵守 PCI DSS 标准
- NGINX App Protect DoS—— 一款 DoS 行为检测和防护解决方案，可跨各种云环境和架构提供一致的自适应防护
NGINX 解决方案使您实现以下功能：
- 在分布式环境中集成强大的安全控制，同时不影响发布速度或性能
- 通过持续的认证、身份鉴定和行为异常检测，自动拦截正在进行的攻击
- 跨团队实现实时最小权限策略、精细的访问控制、端到端加密和管理
- 通过强大的集成式 WAF 和应用级 DoS 防御，安全地将应用从代码交付给客户
- 通过精细的实时和历史指标，持续评估和改善 Kubernetes 环境的安全态势
- 通过技术整合，简化用户和服务以及服务与之间安全通信的部署和管理
NGINX 助力实现全面的零信任安全
随着企业规模不断扩大，对于应用的非特定功能需求，例如零信任安全功能，把他们从应用层卸载下来变得至关重要。我们在上面解释了这是如何将开发人员从跨应用构建、维护和复制安全逻辑的负担中解放出来，取而代之的，他们可以轻松地从平台层面利用安全技术。NGINX 可以在集群边缘（借助 NGINX Ingress Controller）及集群内部（借助 NGINX Service Mesh）为 Kubernetes 提供统一的安全策略实施。您可以根据应用安全需求，通过在集群边缘或内部部署 NGINX App Protect WAF 和 DoS，添加高级应用防护，以防止复杂的网络攻击。
下面让我们深入探讨下 NGINX 解决方案包含哪些功能来支撑您在 Kubernetes 环境中实现全面的零信任安全防护
身份认证和授权
零信任安全的关键原则之一是，每个设备、用户、服务和请求都需要经过身份认证和授权。身份认证是验明身份的过程，换句话说，确保参与通信的各方都如其所声称。授权是验证一方是否有权获得其所要求的对某一资源或功能的访问的过程。
为了满足这一原则，NGINX 解决方案为实施身份认证和授权提供了几个选项，包括 HTTP 基本认证、JSON Web 令牌 (JWT) 和 OpenID Connect（通过与 Okta 和 Azure Active Directory 等身份提供商的集成来实现）。NGINX 解决方案还向服务发放安全身份（就像以证书形式向应用用户发放身份证明一样），为它们在 Kubernetes 集群中执行操作提供身份认证与授权。除了处理工作负载身份外，这款 NGINX 解决方案还通过与公钥基础设施 (PKI) 和证书机构的内置集成，实现了自动化的证书管理。
由于 NGINX Ingress Controller 会检查进入集群的所有请求并将其路由到相应的服务，因此对于集中的用户身份认证和授权以及在某些情景中的服务认证，这是最有效的部署位置。
更多详情请参阅我们博客上的《借助 Okta 和 NGINX Ingress Controller 实现 Kubernetes OpenID Connect 身份认证》。
数据加密和完整性
另一个“零信任”原则是，所有通信都必须是安全的，无论参与者位于何处，其保密性和完整性必须得到妥善保护。数据不得被未经授权的各方读取或在传输过程中被篡改。为了满足这一原则，NGINX 解决方案对于用户与服务之间的通信，使用 SSL/TLS 加密；对于服务间通信，使用双向 TLS (mTLS) 身份认证和加密。
如果您的应用架构不涉及 Kubernetes 集群内服务间的通信，NGINX Ingress Controller 则可以满足您的数据完整性需求。有以下两个基本选项：
- 通过 TLS 透传，NGINX Ingress Controller 可直接将 SSL/TLS 加密连接直接路由到服务，而不对它们进行解密或要求访问 SSL/TLS 证书或密钥。
- 通过 SSL/TLS 卸载，NGINX Ingress Controller 可作为反向代理，终止与请求者的 TLS 连接，然后使用 mTLS 或服务端 SSL/TLS 来加密与 Kubernetes 服务（后端和上游服务器）的新连接。
如果您的架构涉及集群内服务间的通信，为了确保数据完整性，您需要结合使用 NGINX Ingress Controller 和 NGINX Service Mesh。NGINX Service Mesh 可确保只有特定的服务被允许相互通信，使用 mTLS 对它们进行身份认证，并对它们之间的通信进行加密。NGINX Service Mesh 支持您以“零接触”的方式实施 mTLS，这意味着开发人员不必为了加装证书而改造应用，甚至不必知道应用正在进行相互身份认证。
有关 Kubernetes 集群内通信防护的更多信息，请参阅我们博客上的《NGINX Service Mesh 中的 mTLS 架构 》。
访问控制和访问策略
访问控制是零信任模式的另一个关键要素。Kubernetes 使用基于角色的访问控制 (RBAC) 来管理不同用户可以使用哪些资源和操作。它决定了用户或用户组如何与集群内的任何 Kubernetes 对象或命名空间进行交互。
NGINX Kubernetes 互联解决方案支持 RBAC，可轻松与企业的安全策略保持一致。借助 RBAC，用户无需提交工单和也无需等待响应，即可利用受控的权限访问完成工作所需的功能。如果没有 RBAC，用户可能会获得他们不需要的或本应无权使用的权限，如果这些权限被滥用，就可能会导致漏洞的出现。
当您在 NGINX Ingress Controller 中配置 RBAC 时，您可以为企业应用开发和交付环境中的不同角色分配相应的权限，来控制数量众多的人员和团队的访问。其精细的访问管理工具支持跨多个团队的自助服务和管理。
如欲了解如何在 NGINX Ingress Controller 中利用 RBAC，请观看我们在 DevNetwork 上的网络研讨会“使用 NGINX Ingress Controller 进行高级 Kubernetes 部署”。从 13:50 开始，我们的专家解释了如何利用 RBAC 和资源分配实现安全保护、自助服务和多租户模式。
可观测性
在零信任的环境中，审计、监控、日志记录、追踪和报告都是关键要素。您能收集到的有关 Kubernetes 应用基础架构状态的信息越多，就越能有效地进行关联、分析和评估，从而改善您的安全态势。
您可能已经在 Kubernetes 部署中部署了监控工具，不需要另外安装了。为了让您全面了解集群内部的运行状态，我们提供了 NGINX Plus API 工具，既可以帮助您轻松将指标导出到任何接受 JSON 的第三方工具，也可以提供预先构建好的模板与 OpenTelemetry、Grafana 和 Prometheus 等热门工具进行集成。您可以通过深度跟踪对应用相关的连接进行针对性洞察，了解请求是如何被端到端处理的。NGINX Ingress Controller 提供了集群内和外部客户端之间连接的观测能力，NGINX Service Mesh 则提供集群内基于微服务的容器化应用和服务之间连接的观测能力
WAF 和 DoS 防御
借助 NGINX App Protect，您可以进一步加强分布式应用的安全性，保护它们免遭 OWASP 十大安全漏洞和七层拒绝服务 (DoS) 攻击等威胁。NGINX App Protect 是端到端 NGINX 安全连接解决方案的一个必要组件，提供灵活的、以应用为中心的安全防护，抵御最先进的威胁——不仅限于基本的特征库。它基于 F5 行业领先、值得信赖的安全专业知识，不会对发布速度和性能造成任何影响。它可以轻松地将安全遥测数据转发给第三方分析和可视化平台，并通过高置信度的特征库和自动化行为分析减少误报。
NGINX App Protect 的模块化设计意味着您可以根据需要在相同或不同的实例上部署 WAF 或 DoS 防御，或者同时部署两者。例如，在集群边缘，基于 NGINX Ingress Controller 进行部署，这对于在整个单一集群中提供一致的精细保护是个理想化的方案。如果需要为集群内的多个应用指定特定的策略，则可以在 service 或 pod 级别部署 WAF 和/或 DoS 进行防护。
有关 WAF 和 DoS 防御部署的更多信息，请参阅我们博客上的《将安全工具左移以提升应用安全性》。
立即开始使用面向 Kubernetes 的 NGINX 零信任安全解决方案
无论您正处于 Kubernetes 之旅的早期阶段，还是已经在生产环境中运行 Kubernetes 一段时间的高级用户，NGINX 都能够根据您的需求为您提供一套全面的工具和构建模块，帮助您改善安全态势。
立即申请 NGINX Ingress Controller 30 天免费试用（带有 NGINX App Protect WAF 和 DoS），并下载始终免费的 NGINX Service Mesh。
