NGINX开源社区

使用流量管理工具保护 Kubernetes 的六种方法

原文作者：Jenn Gile - F5 NGINX 产品营销经理

原文链接：使用流量管理工具保护 Kubernetes 的六种方法

转载来源：NGINX 中文官网

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

编者按 —— 本文是以下系列博文中的一篇（共十篇）：

生产级 Kubernetes 助您降低复杂性
如何通过高级流量管理提高 Kubernetes 的弹性
如何提高 Kubernetes 环境的可视性
使用流量管理工具保护 Kubernetes 的六种方法（本文）
Ingress Controller 选型指南，第一部分：确定需求
Ingress Controller 选型指南，第二部分：评估风险和技术前瞻性
Ingress Controller 选型指南，第三部分：开源、默认和商用版本能力对比
Ingress Controller 选型指南，第四部分：NGINX Ingress Controller 选项
如何选择 Service Mesh
NGINX Ingress Controller 在动态 Kubernetes 云环境中的性能测试

您还可以免费下载整套博文集结成的电子书：《Kubernetes：从测试到生产》。

我们曾在《在不影响速度的同时保护云原生应用》一文中探讨过，有三个因素使云原生应用比传统应用更难以保护：

云原生应用交付导致工具泛滥以及不一致的企业级服务
云原生应用交付成本可能非常高且不可预测
SecOps 团队难以保护云原生应用，并与 DevOps 存在分歧

虽然这三点都会影响安全性，但也许是由于第三点涉及到人的因素最多，它可能是最棘手的问题。如果 SecOps 没有能力或没有足够的权限保护云原生应用，那么有些后果很明显（漏洞和违规），有些后果却很隐蔽，例如敏捷性降低、数字化转型停滞不前等。

我们来深入探讨一下这些隐性的代价。企业之所以选择 Kubernetes，是因为它有望提高敏捷性并降低成本。但是当 Kubernetes 环境发生安全事件时，多数企业又会将他们的 Kubernetes 部署挪到生产环境之外。且不说这会减缓事关企业未来发展的数字化转型的步伐，就连投入的工程设计和资金也付诸东流了。从逻辑上来说，如果您希望 Kubernetes 完成从测试到生产的旅程，那么就必须将安全性视为重要的战略组成部分，让企业中的每个人都予以高度重视。

本文介绍了您可以使用 Kubernetes 流量管理工具解决的六个安全用例，该工具允许 SecOps 与 DevOps 和 NetOps 更好地协作保护云原生应用和 API。您可以搭配使用这些技术以构建一套全面的安全战略，从而在保护应用和 API 的同时，最大限度地减少对客户的影响。

快速解决 CVE 漏洞，有效避免网络攻击
抵御 OWASP 十大安全漏洞和拒绝服务（DoS）攻击
将身份验证和授权从应用层卸载下来
设置有“防护栏”的自助服务
实施端到端加密
确保客户端使用可信的强密码

安全防护及身份验证的相关术语

在介绍用例之前，我们先快速了解一下您将在本文中遇到的安全防护及身份验证的相关术语。

身份验证和授权 —— 用于确保只有“正确”的用户和服务可以访问后端或应用组件，是系统必备的功能：

身份验证 —— 验证“身份”，确保发出请求的客户端与自己声称的身份相符。通过 ID 令牌实现，例如密码或 JSON Web Tokens (JWTs)。
授权 —— 验证资源或功能的访问“权限”。通过访问令牌实现，例如会话 cookie、会话 ID、组 ID 或令牌内容等 7 层属性。

通用漏洞披露 (CVE) —— 这是一个漏洞数据库，它公开披露了“软件、固件、硬件或服务组件中可能会遭到利用的漏洞缺陷，这些缺陷会破坏受影响的一个或若干组件的机密性、完整性或可用性” (https://www.cve.org/)。CVE 可能由管理工具的开发人员、渗透测试人员、用户或客户或社区人员（例如漏洞猎人）发现。在公开披露漏洞之前，披露者通常会给软件所有者一定的时间来开发补丁，以免给黑客带来可乘之机。

拒绝服务 (DoS) 攻击 —— 一种网络攻击，恶意请求（TCP/UDP 或 HTTP/HTTPS）犹如洪水般涌向受害网站，目的是让网站瘫痪。DoS 攻击会影响可用性，因此它们造成的主要后果就是受害者的声誉受损。分布式拒绝服务 (DDoS) 攻击是指多个攻击源瞄准同一个网络或服务进行攻击，由于攻击者的潜在网络规模较大，防御起来也更加困难。DoS 防护需要一种可以自适应识别和防止攻击的工具。更多信息请参阅《分布式拒绝服务 (DDoS) 详解》。

端到端加密 (E2EE) —— 对从用户传输到应用和后端的数据全程进行完全加密。E2EE 需要 SSL 证书，可能也需要 mTLS。

双向 TLS (mTLS) —— 一种对客户端和主机都进行身份验证（通过 SSL/TLS 证书）的实践。使用 mTLS 还可以保护在客户端和主机之间传输的数据的机密性和完整性。mTLS 的实施可以细化到 Kubernetes pod 级别、同一集群的两个 service 之间。有关 SSL/TLS 和 mTLS 的详细介绍，请参阅 F5 Labs 的《什么是 mTLS？》。

单点登录 (SSO) —— SSO 技术（包括 SAML、OAuth 和 OIDC）可以简化身份验证和授权的管理。

简化的身份认证 —— SSO 让用户省去了针对每个不同的资源或功能设置唯一 ID 令牌的麻烦。
标准化授权 —— SSO 有助于根据角色、部门和资历设置用户访问权限，无需为每个用户单独配置权限。

SSL（安全套接字层）/TLS（传输层安全） —— 一种用于在联网计算机之间建立经过身份验证和加密的链接的协议。SSL/TLS 证书能够验证网站的身份并建立加密连接。虽然 SSL 协议已经在 1999 年弃用并被 TLS 协议取代，但我们通常仍然将这些相关技术称为“SSL”或“SSL/TLS” — 为了保持一致，本文接下来均使用“SSL/TLS”一词。

Web 应用防火墙 (WAF) —— 一种反向代理，能够检测和拦截针对应用和 API 的复杂攻击（包括 OWASP 十大安全漏洞和其他高级威胁），同时让“安全”的流量顺利通过。Web 应用防火墙能够识破黑客的“奸计”，防止他们窃取敏感数据或劫持系统。有些厂商将 WAF 和 DoS 防护整合到了一种工具中，有些厂商则提供独立的 WAF 和 DoS 防护工具。

零信任 —— 一种经常用于高等安全组织的安全概念，但与每个人息息相关，数据必须在存储和运输的所有阶段都得到保护。零信任意味着企业决定在默认情况下不“信任”任何用户或设备，且所有流量都必须经过全面检查。零信任架构通常会包括一组身份验证工具、授权工具以及 mTLS，并且企业实施端到端加密的可能性很大。

用例：快速解决 CVE 漏洞，有效避免网络攻击

解决方案：使用能够发出及时主动的补丁通知的工具

波耐蒙研究所的一项研究指出，在 2019 年，企业平均有 43 天的“宽限期”来开发和发布重大漏洞或高优先级漏洞的补丁，否则就会有攻击者利用漏洞图谋不轨。F5 NGINX 发现，这个窗口在接下来的几年里明显缩短了（2021 年的 Apple iOS 15 事件甚至连一天也没有），也是出于这个原因，我们建议尽快打补丁。但是，如果在 CVE 发布后的几周甚至几个月内，您的流量管理工具都没有可用的补丁，怎么办？

由社区贡献者（而不是专门的工程团队）开发和维护的工具可能会在 CVE 发布以后滞后几周或几个月，导致企业难以在 43 天内完成打补丁。在之前的一个案例中，OpenResty 花了四个月的时间来应用NGINX 相关的安全补丁。这导致使用基于 OpenResty Ingress Controller 的用户至少在四个月的时间里存在风险，并且对于依赖开源项目的软件来说，通常还要再等一段时间才能获得补丁。

要以最快的速度获得 CVE 漏洞补丁，请在选择流量管理工具时注意以下两个特性：

专门的工程团队 —— 如果有一支工程团队负责工具开发（而非社区志愿者），那么您就知道有一群人会全力保障该工具的健康，并会优先考虑尽快发布补丁。
集成的代码库 —— 只要不依赖外部项目（就像我们在 OpenResty 案例中讨论的那样），打补丁就快速多了。

有关 CVE 漏洞补丁的更多信息，请参阅《NGINX Plus 助您快速轻松地缓解安全漏洞》。

用例：抵御 OWASP 十大安全漏洞和 DoS 攻击

解决方案：部署对 Kubernetes 友好的且灵活的 WAF 和 DoS 防护解决方案

在为 Kubernetes 应用选择合适的 WAF 和 DoS 防护解决方案时，有两个必不可少的考虑因素（除特性外）：

灵活性 —— 某些情况下，在 Kubernetes 内部署工具是最好的选择，这样工具就可以在 Kubernetes 内外灵活运行，而不会受基础架构的限制。通过使用相同的工具支持所有部署，您可以重复使用策略，并降低 SecOps 团队的学习难度。
体量 —— 一款优秀的 Kubernetes 工具通常体量也小，资源消耗恰到好处，能够最大程度地减少对吞吐量、每秒请求和延迟的影响。DevOps 团队通常会拒绝使用安全工具，因为他们先入为主地认为这会降低应用速度，而选择一款小体量的高性能工具无疑会增加使用概率。

一款融合了 WAF 和 DoS 防护的工具看似更有效，实则在 CPU 使用率（由于体量大）和灵活性方面不尽人意，并且即使您不需要，也永远都是两个同时部署。最终，这两个问题会抬升 Kubernetes 部署的总体拥有成本，同时为其他基本工具和服务带来预算方面的挑战。

安全工具不仅要选得好，还要用得好。企业通常可以在以下四个位置部署应用服务，保护 Kubernetes 应用：

前门（在 F5 NGINX Plus 或 F5 BIG‑IP 等负载均衡器上） —— 适用于粗粒度的全局保护，因为它允许您跨多个集群应用全局策略
边缘（在 Ingress controller 上，比如 F5 NGINX Ingress Controller）—— 适用于在一个集群上提供标准的细粒度保护
service（在 NGINX Plus 等轻量级负载均衡器上）—— 当集群中的少量服务对独特的策略有着共同需求时，这种方法必不可少
pod（作为应用的一部分）—— 一种高度自定义的方法，适用于策略具有应用针对性的情形

那么四个选项中，哪个最好呢？这就要视情况而定了。

WAF 的部署位置

WAF 的各个部署选项具有更细微的差别，我们不妨先来看看。

前门和边缘 —— 如果企业更倾向于采用“深度防御”安全策略，那么我们建议在外部负载均衡器和 Ingress Controller 上部署 WAF，以有效平衡全局保护和自定义的保护。
F前门或边缘 —— 如果不采用“深度防御”策略，那么也可以只部署在二者其一的位置上，具体取决于所有权。当传统 NetOps 团队负责管理安全性时，他们可能习惯将 WAF 部署在传统代理（外部负载平衡器）上。但是，熟悉 Kubernetes 的 DevSecOps 团队（更喜欢将安全配置放在集群配置附近）可能会选择在 Ingress Controller 层面上部署 WAF。
按服务 service 或按 pod —— 如果您的团队对服务或应用有着特定的要求，则可以根据需求部署额外的 WAF。但要注意：这些位置的部署成本更高一些。这种方法不仅会拖慢开发速度并增加云预算，而且还会提高与故障排除工作相关的运营成本（例如在排查意外拦截流量的 WAF 时）。

DoS 防护工具的部署位置

DoS 攻击防御起来更直接一些，只需将工具部署在一个位置即可 —— 要么在前门，要么在 Ingress Controller。如果您在前门和边缘都部署了 WAF，那么我们建议您在前门 WAF 的前面部署 DoS 防护工具，因为它的覆盖面最广。如此一来，那些非法流量还没到达 WAF 就被滤除了，能够让您更有效地利用计算资源。

有关这些部署方案的更多信息，请参阅《在 Kubernetes 中部署应用服务，第二部分》。

用例：将身份验证和授权从应用层卸载下来

解决方案：在入口处集中实施身份验证和授权

身份验证和授权是应用和服务中一个常见的非功能性要求。在不需要频繁更新应用的小规模部署环境中，这种做法虽然会增加一定的复杂性，却也是可以控制和接受的。但是在应用发布速度更快、规模更大的环境中，将身份验证和授权集成到应用中是行不通的。让每个应用维护相应的访问协议可能会让应用的业务逻辑变得分散甚至被忽视，并导致信息泄露。虽然 SSO 技术通过一组凭证消除了单独设置各个用户名和密码的需要，提高了安全性，但是开发人员仍然必须在应用中写入与 SSO 系统交互的代码。

对此，我们有更好的解决办法：将身份验证和授权卸载到 Ingress Controller。

由于 Ingress Controller 可以检查进入集群的所有流量并将其路由到相应的服务，在这里集中进行身份验证和授权是一个明智的选择。开发人员不仅可以摆脱构建、维护和复制应用代码逻辑的麻烦，而且还可以使用原生的 Kubernetes API 在入口层快速地使用 SSO 技术。

有关该主题的更多信息，请参阅《借助 Okta 和 NGINX Ingress Controller 实现 Kubernetes OpenID Connect 身份验证》。

用例：设置有“防护栏”的自助服务

解决方案：实施基于角色的访问控制 (RBAC)。

Kubernetes 使用 RBAC 来控制不同类型的用户可用的资源和操作。这是一项重要的安全措施，因为它允许管理员或超级用户确定用户或用户组如何与集群中的任何 Kubernetes 对象或特定命名空间进行交互。

Kubernetes RBAC 在默认情况下呈启用状态，需要注意的是，您的 Kubernetes 流量管理工具也默认启用 RBAC，能够与企业的安全需求保持一致。借助 RBAC，用户无需提交工单，即可利用受控的权限访问完成工作所需的功能。如果不配置 RBAC，用户可能会获得他们不需要或无权使用的权限，而权限滥用就会导致出现漏洞。

配置好 RBAC 的工具可以为多个人员和团队提供服务，Ingress Controller 就是一个典型的例子。通过使用 Ingress Controller 进行细粒度的访问管理（甚至细微到一个命名空间），您可以使用 RBAC 以多租户模式高效利用资源。

例如，以下多个团队可能会使用 Ingress Controller：

NetOps 团队 —— 配置应用的外部入口点（如主机名和 TLS 证书），并将流量控制策略委派给不同的团队
DevOps 团队 A —— 配置 TCP/UDP 负载均衡和路由策略
DevOps 团队 B —— 配置速率限制策略，防止服务请求过多
Identity 团队 —— 管理身份验证和授权组件，同时将 mTLS 策略配置为端到端加密策略的一部分
DevSecOps 团队 —— 设置 WAF 策略

如欲了解如何在 NGINX Ingress Controller 中利用 RBAC，请观看视频“使用 NGINX Ingress Controller 进行高级 Kubernetes 部署”。从 13:50 开始，我们的专家解释了如何利用 RBAC 和资源分配实现安全保护、自助服务和多租户模式。

用例：实现端到端加密

解决方案：使用流量管理工具

在需要处理敏感信息或个人信息的企业中，端到端加密 (E2EE) 成为了一个越来越普遍的要求。无论是财务数据还是社交媒体消息，消费者对隐私保护的期望加之 GDPR 和 HIPAA 等法规的实施都拉升了对这类保护的需求。实现 E2EE 的第一步是让您的后端应用在架构上能够接受 SSL/TLS 流量，或者使用工具将 SSL/TLS 管理从应用上卸载下来（这是分离安全功能、性能、密钥管理等工作负载的首选方法）。然后，您再根据环境的复杂性配置流量管理工具。

最常见的方案：使用 Ingress controller 实现 E2EE

当您的应用只有一个端点（简单的应用或者您直接迁移到 Kubernetes 的单体应用）或没有服务到服务通信时，您可以在 Kubernetes 内使用 Ingress controller 实现 E2EE。

第一步：确保您的 Ingress controller 只允许使用服务端证书或 mTLS 证书加密的 SSL/TLS 通过，理想情况下出入向流量均如此。

第二步：解决典型的默认设置，让 Ingress controller 在将流量发送给应用之前必须先解密并重新加密流量。实现方法有多种，具体取决于您的 Ingress controller 和要求：

如果您的 Ingress controller 支持 SSL/TLS 流量直通，那么它可以根据服务名称指示 (SNI) 标头路由 SSL/TLS 加密连接（无需解密流量，也不要求访问 SSL/TLS 证书或密钥）。
或者，您可以设置 SSL/TLS 终止，即由 Ingress controller 终止流量，然后将其代理到后端或上游 — 要么以明文的形式，要么通过 mTLS 或服务端 SSL/TLS 对 Kubernetes 服务流量重新加密。

不太常见的方案：使用 Ingress controller 和 service mesh 实现 E2EE

如果您的集群中存在服务到服务通信，那么您需要在两个平面上实施 E2EE：使用 Ingress controller 处理出入向流量，并使用 service mesh 处理服务到服务流量。在 E2EE 中，service mesh 的角色是确保只有特定的服务能够安全地与其他服务通信。为 E2EE 设置 service mesh 时，您应该通过两个因素建立零信任环境：服务之间的 mTLS（设置为需要证书）和服务之间的流量访问控制（指定有权通信的服务）。理想情况下，您还可以在应用之间实施 mTLS（由 service mesh 和出入向流量控制器管理），以便在整个 Kubernetes 集群中实现真正的 E2EE 安全性。

有关加密网络通信数据的更多信息，请参阅《NGINX Service Mesh 中的 mTLS 架构》。

用例：确保客户端使用可信的强密码

解决方案：遵守联邦信息处理标准 (FIPS)

在软件行业中，FIPS 通常是指密码学的专刊 FIPS PUB 140-2《加密模块的安全要求》。该文件是美国和加拿大合作的产物，为两国联邦机构都能接受的加密模块（目的是保护敏感信息）制定了测试和认证标准。“等等！”您可能会说， “我不在乎 FIPS，我又不与北美政府机构合作。”不管您处于哪个行业、哪个地区，遵守 FIPS 都是明智之举，因为 FIPS 也是全球加密领域的基准。

遵守 FIPS 并非难事，只是您的操作系统和相关流量管理工具必须也得以 FIPS 模式运行。人们普遍存在一种误解，认为只要在 FIPS 模式下运行操作系统就可以实现 FIPS 合规性。然而即使在 FIPS模式下运行操作系统，客户端在与 Ingress controller 的通信时可能也不使用强密码。在 FIPS 模式下运行时，您的操作系统和 Ingress controller 可以只使用典型 SSL/TLS 密码套件的一个子集。

您可以按照以下四个步骤为您的 Kubernetes 部署设置 FIPS：

第一步：将您的操作系统配置为 FIPS 模式
第二步：验证操作系统和 OpenSSL 是否处于 FIPS 模式
第三步：安装 Ingress controller
第四步：执行 FIPS 状态检查，验证是否符合 FIPS 140-2 标准

在下面的示例中，操作系统和 OpenSSL（使用 NGINX Plus 实现）启用 FIPS 模式后，所有出入 NGINX Plus 的最终用户流量都使用经过验证的支持 FIPS 的加密引擎进行了解密和加密。

有关 FIPS 的更多信息，请参阅《通过 NGINX Plus 实现 FIPS 合规性》。