使用 NGINX 为 Kubernetes 应用构建零信任安全

网络安全攻击的复杂程度和数量呈指数级增长，给部署在本地、混合和多云 Kubernetes 环境中的应用程序带来了巨大的暴露风险。 传统的安全模型是基于边界的，假设如果用户位于环境的安全边界内，那么他们就是值得信任的（并且他们之间的通信是安全的）。 在当今的分布式环境中，边界内安全区的概念已不复存在——来自环境“内部”的通信可能与外部威胁一样危险。

在这篇博客中，我们探讨了采用零信任模型来保护您的 Kubernetes 基础设施的好处，以及 NGINX 如何帮助改善您的安全态势。

什么是零信任？

零信任是一种基于身份而非位置的安全模型。 它假设任何访问应用、数据和设备的请求都可能是一种攻击，无论请求者似乎位于本地、远程还是云端。

为了实现零信任的三大核心原则——永不信任、始终验证、持续监控——每个用户、服务、应用和设备都需要持续提供身份验证和授权证明。 根据动态访问策略和最小特权授予有时间限制的特权。

所有通信都经过加密并通过策略决策/执行点 (PDP/PEP) 进行路由，该点对所有各方进行身份验证并根据动态访问策略授予他们特权。 此外，还具备审计、监控、报告和自动化功能来分析、评估和减轻安全风险。

零信任如何改善您的安全态势

零信任通过多种方式改善您的安全态势：

• 自动阻止未经授权的活动
• 实施访问控制以减少暴露的攻击面
• 检测行为异常和危害指标
• 定义限制访问时间的实时、最小权限策略
• 不断验证和确认身份以阻止正在进行的攻击

零信任对于在 Kubernetes 环境中运行的现代云原生应用尤其重要。 松散耦合且可移植的分布式应用程序和服务被容器化并在无法提供基于位置的安全性的混合多云环境中运行。 安全必然依赖于身份和权限的持续验证、端到端加密和监控。

如何实现零信任安全

为了实现零信任原则，您的 Kubernetes 环境必须为用户、应用和服务提供关键的安全功能，例如身份验证、授权、访问控制、策略、加密、监控和审计。

实现这一目标的一个可能方法是在应用程序本身中构建安全性。 但是，这意味着您的开发人员必须实施多项安全程序——建立和验证信任、管理用户身份和证书、加密和解密所有通信等等。 他们还必须了解并整合第三方技术，如 TLS 和单点登录 (SSO)。 所有这些不仅增加了本已复杂的 Kubernetes 部署的复杂性。 它分散了开发人员的注意力，使他们无法集中精力于他们需要（和想要！）的事情：优化应用程序的业务功能。

不要惊慌——有更好的方法：将安全性和其他非功能性需求转移到您的 Kubernetes 基础设施上！ Kubernetes 集群的连接工具（例如 Ingress 控制器和服务网格）可以为您的应用和服务之间的所有通信提供 PDP 和 PEP - 无论是由用户还是其他应用或服务发起。 这意味着您可以专注于核心业务专业知识和功能，同时更快、更轻松地交付应用程序。

F5 NGINX 如何提供帮助

如下图所示，用于安全 Kubernetes 连接的 NGINX 解决方案包含所有与基础设施无关的组件和工具，可帮助您在任何环境（本地、混合和多云）中大规模、端到端地保护用户、分布式应用、微服务和 API。 该解决方案由世界上最受欢迎的数据平面提供支持，结合了：

• NGINX Ingress Controller作为 Kubernetes 的 Ingress 控制器，以及与第三方身份和 SSO 提供商集成的 PDP/PEP。 NGINX Ingress Controller 基于NGINX Plus ，可处理高级连接、监控和可视性、身份验证和 SSO，并充当 API 网关。
• NGINX 服务网格作为一种轻量级、交钥匙且适合开发人员的服务网格，可确保 Kubernetes 集群内的服务连接。 作为与每个 Kubernetes 服务共置的 PDP/PEP 的企业级 Sidecar 基于 NGINX Plus。
• NGINX App Protect基于 F5 市场领先的安全技术构建，为现代应用程序和 API 提供全面保护。 它采用模块化方法，以实现部署场景的灵活性和最佳资源利用率：
  • NGINX App Protect WAF – 一款强大、轻量级的 WAF，可防御 OWASP Top 10 并提供 PCI DDS 合规性
  • NGINX App Protect DoS – 行为 DoS 检测和缓解，跨云和架构提供一致且自适应的保护

NGINX 解决方案使您能够：

• 在分布式环境中集成强大的安全控制，而不会减慢发布速度或损害性能
• 通过持续的身份验证、身份验证和行为异常检测自动阻止正在进行的攻击
• 实施实时最小权限策略、细粒度访问控制、端到端加密和跨多个团队的治理
• 通过集成的、强大的 WAF 和应用程序级 DoS 防御，安全地将应用程序从代码交付给客户
• 通过精细的实时和历史指标持续评估和改善 Kubernetes 环境的安全态势
• 通过技术整合，简化安全的用户到服务和服务到服务通信的部署和管理

使用 NGINX 实现全面的零信任安全

随着组织规模的扩大，从应用层卸载非特定于应用程序功能的需求（例如零信任安全功能）变得至关重要。 我们上面解释了如何将开发人员从在其应用程序中构建、维护和复制安全逻辑的负担中解放出来；相反，他们可以轻松地在平台级别利用安全技术。 NGINX 通过 NGINX Ingress Controller 在集群边缘为 Kubernetes 提供集中式安全策略实施，并通过 NGINX Service Mesh 在集群内部提供集中式安全策略实施。 您可以根据应用程序的安全要求，使用部署在边缘或集群内的 NGINX App Protect WAF 和 DoS 添加高级应用保护，以抵御复杂的网络攻击。

让我们深入探讨 NGINX 解决方案如何包含为您的 Kubernetes 部署实施全面零信任安全所需的功能。

身份验证和授权

零信任安全的关键原则之一是每个设备、用户、服务和请求都经过身份验证和授权。 身份验证是核实身份的过程——换句话说，确保参与通信的每一方都是其所声称的身份。 授权是验证一方是否有权访问其请求的资源或功能的过程。

为了实现这一原则，NGINX 解决方案提供了多种实现身份验证和授权的选项，包括HTTP 基本身份验证、 JSON Web 令牌 (JWT)和OpenID Connect （通过与 Okta 和 Azure Active Directory (AD) 等身份提供商集成）。 NGINX 解决方案还向服务颁发安全身份（非常类似于以证书形式颁发应用用户身份证明），从而使他们能够通过身份验证并获得授权在 Kubernetes 集群中执行操作。 除了处理工作负载身份之外，NGINX 解决方案还通过与公钥基础设施 (PKI) 和证书颁发机构的内置集成来自动化证书管理。

由于 NGINX Ingress Controller 已经仔细检查进入集群的所有请求并将其路由到适当的服务，因此它是集中用户身份验证和授权以及某些场景中的服务身份验证的最有效位置。

有关更多详细信息，请阅读我们博客上的使用 Okta 和 NGINX Ingress Controller 为 Kubernetes 实现 OpenID Connect 身份验证。

数据加密和完整性

另一个零信任原则是，无论参与者位于何处，所有通信都必须是安全的——保持其机密性和完整性。 数据不得被未经授权的方读取或在传输过程中被修改。 为了满足这一原则，NGINX 解决方案对用户到服务通信使用 SSL/TLS 加密，并对服务到服务通信使用相互 TLS (mTLS) 身份验证和加密。

如果您的应用程序架构不涉及 Kubernetes 集群内的服务到服务通信，NGINX Ingress Controller 可能足以满足您的数据完整性需求。 有两个基本选项：

• 通过TLS Passthrough ，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 服务网格中的 mTLS 架构。

访问控制和访问策略

访问控制是零信任模型中的另一个关键要素。 Kubernetes 使用基于角色的访问控制（RBAC）来规范不同用户可用的资源和操作。 它决定了用户或用户组如何与集群中的任何 Kubernetes 对象或命名空间交互。

NGINX Kubernetes 连接解决方案支持 RBAC，可轻松与您组织的安全策略保持一致。 有了 RBAC，用户就可以获得完成工作所需的功能的访问权限，而无需提交 IT 工单并等待其完成。 如果没有 RBAC，用户可以获得他们不需要或无权获得的权限，如果权限被滥用，则可能导致漏洞。

当您使用 NGINX Ingress Controller 配置 RBAC 时，您可以通过将权限与组织的应用开发和交付环境中的各种角色相结合来控制众多人员和团队的访问。 其细粒度的访问权限管理工具可实现跨多个团队的自助服务和治理。

要了解如何利用 RBAC 和 NGINX Ingress Controller，请观看我们在 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 Top 10 和第 7 层拒绝服务 (DoS)攻击等威胁。 NGINX App Protect 是端到端NGINX 安全连接解决方案的一个组成部分，它提供了敏捷的、以应用为中心的安全性，可以抵御最高级的威胁——远远超出了基本签名。 它利用 F5 领先且值得信赖的安全专业知识，并且不会影响发布速度和性能。 它可以轻松地将安全遥测转发给第三方分析和可视化解决方案，并通过高可信度签名和自动行为分析减少误报。

NGINX App Protect 的模块化设计意味着您可以根据需要在相同或不同的实例上部署 WAF 和 DoS 保护中的一个或两个。 例如，您可能决定在集群边缘使用 NGINX Ingress Controller 进行部署，这对于提供在整个单个集群中一致的细粒度保护非常理想。 如果您需要针对集群中的多个应用程序制定特定于应用程序的策略，则可以在服务或 pod 级别部署 WAF 和/或 DoS 保护。

有关部署 WAF 和 DoS 保护的更多信息，请阅读我们博客上的“将安全工具向左移动以实现更安全的应用程序” 。

开始使用适用于 Kubernetes 的 NGINX 零信任安全解决方案

无论您是刚开始使用 Kubernetes，还是已经在生产中运行 Kubernetes 一段时间的高级用户，NGINX 都能提供一套全面的工具和构建块来满足您的需求并改善您的安全态势。

首先申请 NGINX Ingress Controller 与 NGINX App Protect WAF 和 DoS 的30 天免费试用版，然后下载始终免费的 NGINX Service Mesh。