原文作者：Amir Rawdat
原文链接：零信任安全模型 | 《使用 NGINX 部署和保护 Kubernetes Ingress Controller》章节精选
转载来源：NGINX 开源社区

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

编者按——企业级 Kubernetes 应用和 API 互联指南《使用 NGINX 部署和保护 Kubernetes Ingress Controller》中文版现已正式上线，现可扫描文末二维码免费下载电子版全本。

这本超过 180 页的实践指南适用于平台工程、应用开发以及基础设施和运营团队。它通过提供有关安装和配置、四层和七层负载均衡、流量精分技术、分布式跟踪和监控、单点登录等方面信息，展示了如何将 NGINX Ingress Controller、NGINX Service Mesh 和 NGINX App Protect 等工具集成到您的环境中，以简化 Kubernetes 应用互联。 

本文节选了本书的第 8 章《零信任安全模型》中的精彩段落。

零信任模型增强安全防护

零信任是一种安全模型，可确保基于身份的威胁防护贯穿整个应用使用流程。零信任模型始终假设应用的任何部分随时都可能会遭到攻击。因此，用户与系统中任何服务的交互均需进行适当的身份验证、授权和持续验证。

NGINX Kubernetes 解决方案组件

零信任模型为用户及其云端与本地应用和数据提供保护，尤其适用于现代分布式应用和服务，其中各种服务或数据可能位于不同的环境中。

如今，位置不再是信任的基础。无条件信任内部服务或假设用户已在应用工作流中的特定位置通过身份验证的传统方法已经过时。安全威胁不再只针对应用的端点，现在可以针对任何点。因此，实施零信任模型势在必行。

零信任有哪些关键原则？

零信任有三个关键原则：

1. 永不信任任何人，无论内部还是外部人员。
2. 始终验证所有资源的访问权限。
3. 在收集上下文和数据的同时进行持续监控。

总之，任何人和任何事物皆不可信。因此，必须持续对一切进行身份验证和授权。所有通信都经过加密、予以监控并通过自动跟踪进行审计。配置报告以最大限度地优化洞察能力并实时响应威胁。最后，启用极为具体的访问控制，仅依照最小权限原则授予访问权限，并根据所需访问的资源的时间和范围进一步加以限制。

Kubernetes 中的零信任模型

随着网络安全攻击的复杂性和数量的激增，您部署在本地、混合和多云 Kubernetes 环境中的应用面临着巨大的暴露风险。采用零信任模型来保护 Kubernetes 基础设施，有助于您增强安全防护。

为何选择零信任作为应用的安全模型？

出于众多原因，零信任模型可用于应用开发，以帮助保护应用并使其更加可靠。

以下是零信任模型实现的部分安全防护活动：

• 阻止未经授权的活动
• 通过访问控制缩小可访问的攻击面
• 检测行为异常
• 通过实时最小权限策略限制访问时间
• 使应用安全防护独立于其他所有变量，包括环境和位置
• 阻止正在进行的攻击

下图显示了如何使用 NGINX 将零信任模型集成到应用中。

身份验证和授权

零信任安全模型的两个主要方面是身份验证和授权。

第一步是确保定期对所有用户和服务进行身份验证，即在允许访问受保护资源之前对用户或服务身份进行验证。这是执行任何 API 调用之前的一项要求。

第二步是确保所有用户都获得授权，这意味着每个用户都必须分配一个角色，该角色仅授予对允许访问资源的权限。必须确保每个请求都包含发起者的信息，以识别潜在的攻击者。

NGINX 可以使用哪些身份验证和授权机制？

NGINX Ingress Controller 采用多种身份验证和授权机制：

• BasicAuth — 使用 HTTP 基础身份验证机制对客户端请求进行身份验证
• JWT — 使用 JSON Web Token (JWT) 对客户端请求进行身份验证
• IngressMTLS — 配置客户端证书验证
• EgressMTLS — 配置上游身份验证和证书验证
• OIDC — 将 NGINX Plus 配置为 OpenID Connect 身份验证的中继方

若要使用零信任安全模型，建议启用多重身份验证，以增强用户安全防护。

WAF 和 DoS 防护

在保护 NGINX Ingress Controller 时，NGINX App Protect 凭借其 Web 应用防火墙 (WAF) 和拒绝服务 (DoS) 攻击防护成为第一道防线。这种全面保护可确保应用和 API 免受最复杂的攻击。

WAF 保护在零信任安全模型中是什么角色？

NGINX App Protect WAF 不仅可以保护 API、内部应用及其数据免受应用层攻击和注入攻击，如 SQL 注入、恶意文件执行、跨站请求伪造 (CSRF) 及跨站脚本 (XXS) 攻击，而且还有助于确保合规性。当与 DoS 防护搭配使用时，可阻止恶意流量，以确保环境的稳定性，从而减少声誉和收入损失。

组合使用 NGINX App Protect DoS 和 NGINX App Protect WAF 进行 DoS 和 WAF 防护

NGINX App Protect WAF 的其他功能包括：

• 比基本特征库和攻击向量更进一步的高级安全控制
• 字节码层级的低延迟和强大安全控制
• 来自 F5 Labs 的安全情报和直接从 F5 BIG-IP Advanced WAF 移植的技术
• 威胁检测功能开箱即用且误报率极低，可实现高可信的拦截模式部署

NGINX App Protect DoS 具有哪些关键属性？

NGINX App Protect DoS 提供针对七层 DoS 攻击的安全防护，这种攻击很难使用常用工具进行检测。为了解决这个问题，NGINX App Protect DoS 使用自动化用户和站点行为分析以及主动健康检查，确保有效防范 HTTP(S) Slowloris、Slow POST、Challenge Collapsar (CC) 等攻击。

NGINX App Protect DoS 的其他关键要素包括：

• 零接触配置模式，可简化现代应用的 DoS 安全防护
• 实现跨多种应用部署环境的一致控制
• 与 NGINX 平台的无缝集成，可降低保护和交付现代应用时的复杂性、减少人工监督并阻止工具蔓延

访问控制

下面我们从零信任的角度来看看访问控制。严格的访问控制是零信任的一个关键原则，确保访问控制的主要方法是应用流量策略。

访问控制可用于 NGINX Service Mesh 和 NGINX Ingress Controller 的 Kubernetes 流量。

通过 NGINX Service Mesh，您可以配置以下流量策略以进行访问控制：

• 流量精分 — 实现灰度部署和 A/B 测试
• 流量访问控制 — 定义整个集群的应用访问
• 速率限制 — 对请求速率进行高级控制
• 熔断 — 创建故障切换方案

借助 NGINX Ingress Controller，您可以使用内置机制来执行身份验证和授权。它不仅能够轻松与第三方服务集成，如 Okta、Ping Identity 和 Azure Active Directory (AAD)，而且还可针对证书管理和 ExternalDNS 等域服务进行设置。

动态策略

在零信任模型中，动态策略是对攻击者做出快速响应和迅速进行安全更改的必要条件。通过动态策略，NGINX 可更新已知实例，从而确保客户端始终能够访问最新信息。

为了确保服务器端安全防护，NGINX 还提供了可定制的速率限制和熔断器设置，以满足个性化需求。

更改动态策略配置是一个无缝流程，不会造成服务中断。在应用任何更改之前，NGINX 会验证新配置，以确保顺畅过渡。

加密

为了增强安全防护，零信任安全模型要求对所有数据进行加密。由于数据是现代应用的重要组成部分，因此零信任模型通过在加密云端存储数据之前对静态数据（物理存储的数据）和传输中的数据（通过互联网及其他网络或设备移动的数据）进行加密，可以提供额外的保护。

加密的工作原理

在微服务和多租户 Kubernetes 环境中，仅对服务器的签名进行身份验证远远不够。检查每个客户端以确保它们被允许向特定服务器发出请求已变得至关重要。NGINX Service Mesh 通过双向 TLS (mTLS) 对这些用户进行身份验证，即双方使用传输层安全 (TLS) 协议相互进行身份验证。NGINX Service Mesh 还能定义访问控制策略，以允许访问来自特定客户端的传入请求。

此外，NGINX Service Mesh 还采用 SPIRE 软件作为中央证书颁发机构。SPIRE 可以处理证书的整个生命周期：创建、分发和轮换。随后，NGINX Plus 会使用这些 SPIRE 签发的证书建立 mTLS 会话并加密流量。

在下图中，您可以看到三个主要组件：

1. 作为 Kubernetes StatefulSet 运行的 SPIRE 服务器。
2. 作为 Kubernetes DaemonSet 运行的 SPIRE 代理。
3. 使用 SPIRE 所生成和分发证书的 NGINX Plus sidecar。

NGINX Service Mesh 具有以下模式，具体取决于环境（测试、开发或生产环境）：

• Off — 禁用 pod 之间的 mTLS，用于开发。
• Permissive — 启用 pod 之间的加密，同时允许在无法使用 mTLS 的情况下进行未加密通信。该模式用于评估 NGINX Service Mesh 的生产场景。
• Strict — 启用 pod 之间的加密，只允许发送到注入 pod 的流量。该模式适用于生产环境。

审计与日志记录

在零信任安全模型中，必须监控所有身份以验证访问和权限。日志记录与审计可确保记录用户在访问环境时的所有活动。

为什么审计和日志记录很重要？

审计和日志记录不仅可以收集情报并提供洞察信息，而且还能够在整个环境中持续运行，并在很大程度上实现了自动化。如有攻击者企图非法访问您的环境，适当的审计和日志记录可确保您立即收到通知。由于在连接期间所有用户操作都会被记录下来，因此您还会收到有关任何潜在未来威胁的通知。

NGINX Ingress Controller 提供了一个包含负载均衡和性能指标的仪表盘（默认为启用）。该仪表盘可在端口 8080 上访问。

您可以使用此命令访问仪表盘：

$ kubectl get pods -n nginx-ingress
NAME                 READY  STATUS   RESTARTS  AGE
nginx-ingress-dplmt  1/1    Running  0         21h
$ kubectl port-forward nginx-ingress-dplmt 8080:8080 -n nginx-ingress
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

然后，可以打开浏览器：http://127.0.0.1:8080/dashboard.html。若要通过 API 访问指标，请使用 /api 路径通过 API 访问指标。

NGINX 与日志仪表盘的集成

NGINX Service Mesh 和 NGINX Ingress Controller 都能与 Prometheus、Grafana 及其他仪表盘集成，以导出指标和跟踪数据。借助仪表盘，您不仅可以生成多个实用指标，以便分析流量和性能信息，而且还能够获取洞察信息，从而分析集群内的任何漏洞、稳定性变化及整体性能。

下面是 NGINX 和 Grafana 仪表盘的示例。这些仪表盘提供了请求量、稳定性及环境性能的概览。您既可以导入它们，也可以根据集群的详细情况和要求自行创建。

在 Grafana 仪表盘中，NGINX Ingress Controller 显示日志，可供您确定可能存在的问题。所有日志都会发送到进程的标准输出和错误中。

若要查看 Grafana 仪表盘日志，请执行此命令：

$ kubectl get pods -n nginx-ingress
NAME                 READY  STATUS   RESTARTS  AGE
nginx-ingress-dplmt  1/1    Running  0         21h
$ kubectl logs nginx-ingress-dplmt -n nginx-ingress

默认情况下，该命令包含两种日志：访问日期（可供您查看有关客户端请求的信息）和错误日志（其中包含不同严重程度问题的相关信息）。

审计和日志记录对任何应用和服务都至关重要，因为它们提供了对任何异常情况的可见性、可追溯性和快速响应，包括对可能的预防措施的分析。收集到的所有信息都有助于快速确定可能存在的性能和安全问题，以确保 Kubernetes 环境安全无虞。

立即下载

本指南对任何设置、运行和使用 Kubernetes 环境的团队来说都大有裨益，无论您是 Kubernetes 资深用户还是新手，希望这本电子书能助您顺利开启 Kubernetes 之旅。

扫描下方二维码，前往 NGINX 中文官网免费下载电子版全本。

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源： 开源社区官网 | 微信公众号 | B 站