博客 | NGINX

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

NGINX-F5-horiz-black-type-RGB 的一部分
Jenn Gile 缩略图
詹妮弗·吉尔
2021 年 12 月 20 日发布

编辑– 这篇文章是10 篇系列文章的一部分：

  1. 使用生产级 Kubernetes 降低复杂性
  2. 如何通过高级流量管理提高 Kubernetes 的弹性
  3. 如何提高 Kubernetes 中的可见性
  4. 使用流量管理工具保护 Kubernetes 的六种方法（本帖）
  5. 选择入口控制器的指南，第 1 部分： 确定您的需求
  6. 选择入口控制器的指南，第 2 部分： 风险与未来保障
  7. 选择入口控制器的指南，第 3 部分： 开源与…… 默认与…… 商业的
  8. 选择入口控制器的指南，第 4 部分： NGINX 入口控制器选项
  9. 如何选择服务网格
  10. 在动态 Kubernetes 云环境中对 NGINX Ingress 控制器进行性能测试

您还可以下载完整的博客作为免费的电子书 -将 Kubernetes 从测试带到生产。

正如在不损失速度的情况下保护云原生应用程序中所讨论的，我们观察到三个因素使得云原生应用程序比传统应用程序更难保护：

  1. 云原生应用交付导致工具泛滥并提供不一致的企业级服务
  2. 云原生应用交付成本难以预测且高昂
  3. SecOps 团队努力保护云原生应用，但与 DevOps 存在分歧

虽然这三个因素对安全性的影响是相同的，但第三个因素可能是最难解决的问题，也许是因为它是最“人性化”的。 当 SecOps 无法或没有权力保护云原生应用程序时，一些后果是显而易见的（漏洞和违规），但其他后果则是隐藏的，包括敏捷性减慢和数字化转型停滞。

让我们深入挖掘这些隐性成本。 组织选择Kubernetes是因为它具有灵活性和节省成本的优点。 但是，当 Kubernetes 环境中出现安全事故时，大多数组织都会将其 Kubernetes 部署撤出生产。 这会减缓对组织未来至关重要的数字化转型计划——更不用说浪费工程精力和金钱了。 合乎逻辑的结论是：如果您要尝试将 Kubernetes 从测试推向生产，那么安全性必须被视为组织中每个人都拥有的战略组成部分。

在这篇文章中，我们介绍了六个可以使用 Kubernetes 流量管理工具解决的安全用例，使 SecOps 能够与 DevOps 和 NetOps 协作，以更好地保护您的云原生应用程序和 API。 这些技术的组合通常用于创建全面的安全策略，旨在确保应用程序和 API 的安全，同时最大限度地减少对客户的影响。

  1. 快速解决 CVE 以避免网络攻击
  2. 阻止 OWASP Top 10 和拒绝服务攻击
  3. 卸载应用程序的身份验证和授权
  4. 设置带有护栏的自助服务
  5. 实施端到端加密
  6. 确保客户端使用具有可信实现的强密码

安全和身份术语

在我们进入用例之前，这里先快速概述一下您将在本文中遇到的一些安全和身份术语。

  • 身份验证和授权——确保只有“正确的”用户和服务才能访问后端或应用组件所需的功能：

    • 身份验证——验证身份以确保提出请求的客户是其所声称的身份。 通过 ID 令牌（例如密码或 JSON Web 令牌 (JWT)）完成。

    • 授权——验证访问资源或功能的权限。 通过访问令牌完成，例如第 7 层属性（如会话 cookie、会话 ID、组 ID 或令牌内容）。

  • 严重漏洞和暴露 (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 级别，即同一集群中的两个服务之间。 有关 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 Top 10和其他高级威胁），同时允许“安全”流量通过。 WAF 可以防御试图通过窃取敏感数据或劫持系统来损害目标的攻击。 一些供应商将 WAF 和 DoS 保护整合到同一个工具中，而其他供应商则提供单独的 WAF 和 DoS 工具。

  • 零信任——一种经常在安全性较高的组织中使用但与每个人都相关的安全概念，其中数据在存储和传输的所有阶段都必须得到保护。 这意味着该组织决定默认不“信任”任何用户或设备，而是要求对所有流量进行彻底审查。 零信任架构通常包括身份验证、授权和 mTLS 的组合，并且组织很有可能实施 E2EE。

用例： 快速解决 CVE 以避免网络攻击

解决方案： 使用具有及时和主动补丁通知的工具

根据波耐蒙研究所 (Ponemon Institute) 的一项研究，2019 年，从发布针对严重或高优先级漏洞的补丁到组织遭受试图利用该漏洞的攻击之间的平均“宽限期”为 43 天。 在 F5 NGINX，我们看到该窗口在接下来的几年中显著缩小（在 2021 年 Apple iOS 15 的情况下甚至缩小到零日），这就是我们建议尽快修补的原因。 但是，如果在 CVE 发布后数周甚至数月内无法获得流量管理工具的补丁，该怎么办？

由社区贡献者（而非专门的工程团队）开发和维护的工具可能会比 CVE 公告落后数周或数月，因此组织不太可能在43 天内进行修补。 在一个案例中，OpenResty 花了四个月的时间来应用 NGINX 相关的安全补丁。 这使得任何使用基于 OpenResty 的 Ingress 控制器的人至少在四个月内都容易受到攻击，但实际上，依赖于开源项目的软件通常还需要额外的延迟才能获得补丁。

该图显示了第三方 NGINX 发行版可能需要数月才能应用安全补丁

为了获得最快的 CVE 修补，在选择流量管理工具时请注意两个特点：

  • 专门的工程团队——当工具开发由工程团队而不是社区志愿者管理时，您会知道有一群人致力于工具的健康，并可以优先尽快发布补丁。
  • 集成的代码库——无需任何外部依赖（就像我们与 OpenResty 讨论的那样），补丁只需敏捷冲刺即可获得。

有关 CVE 修补的更多信息，请阅读使用 NGINX Plus 快速轻松地缓解安全漏洞。

用例： 阻止 OWASP Top 10 和 DoS 攻击

解决方案： 部署灵活、Kubernetes 友好的 WAF 和 DoS 保护

为 Kubernetes 应用选择正确的 WAF 和 DoS 保护取决于两个因素（除了功能之外）：

  • 灵活性——在某些情况下，最好在 Kubernetes 内部部署工具，因此您需要可以在 Kubernetes 内部或外部运行的与基础设施无关的工具。 对所有部署使用相同的工具使您能够重复使用策略并降低 SecOps 团队的学习曲线。
  • 占用空间——最好的 Kubernetes 工具占用空间小，从而允许适当的资源消耗，同时对吞吐量、每秒请求数和延迟的影响最小。 鉴于 DevOps 团队经常抵制安全工具，因为他们认为这些工具会降低应用程序的速度，因此选择占用空间小的高性能工具可以增加采用的可能性。

虽然整合 WAF 和 DoS 保护的工具似乎更高效，但实际上预计它会在 CPU 使用率（由于占用空间较大）和灵活性方面存在问题。 您被迫同时部署 WAF 和 DoS 保护，即使您不需要两者。 最终，这两个问题都会推高 Kubernetes 部署的总拥有成本，同时给其他基本工具和服务带来预算挑战。

一旦您为组织选择了正确的安全工具，就该决定在何处部署这些工具了。 通常可以在四个位置部署应用服务来保护 Kubernetes 应用程序：

  • 在前门（在外部负载均衡器上，例如F5 NGINX Plus或F5 BIG‑IP ）– 适用于“粗粒度”全局保护，因为它允许您跨多个集群应用全局策略
  • 在边缘（在入口控制器上，例如F5 NGINX 入口控制器）——非常适合提供跨单个集群的“细粒度”保护
  • 在服务端（在轻量级负载均衡器，如 NGINX Plus）——当集群中有少数服务对独特策略有共同需求时，这可能是一种必要的方法
  • 在 Pod 中（作为应用的一部分）——当策略特定于应用程序时，可能会使用一种非常自定义的方法

那么，在这四个选项中，哪一个是最好的？ 嗯...那得看情况！

在哪里部署 WAF

首先，我们将研究 WAF 部署选项，因为这往往是一个更微妙的选择。

  • 前门和边缘——如果您的组织更喜欢“纵深防御”安全策略，那么我们建议在外部负载均衡器和入口控制器上部署 WAF，以有效平衡全局和自定义保护。
  • 前门或边缘——在没有“纵深防御”策略的情况下，单一位置是可以接受的，部署位置取决于所有权。 当传统的 NetOps 团队拥有安全性时，他们可能更愿意在传统代理（外部负载均衡器）上进行管理。 但是，熟悉 Kubernetes（并且更喜欢将其安全配置放在集群配置附近）的 DevSecOps 团队可能会选择在入口级别部署 WAF。
  • 每个服务或 pod – 如果您的团队对其服务或应用程序有特定要求，那么他们可以按单点方式部署额外的 WAF。 但请注意：这些地点的成本更高。 除了增加开发时间和更高的云预算之外，这种选择还会增加与故障排除工作相关的运营成本——例如确定“我们的哪个 WAF 无意中阻止了流量？”

在哪里部署 DoS 保护

针对 DoS 攻击的防护更加直接，因为它只需要在一个位置 - 前门或入口控制器处。 如果您在前门和边缘都部署了 WAF，那么我们建议您在前门 WAF 前面部署 DoS 保护，因为它是最全球化的。 这样，不需要的流量在进入 WAF 之前就会被减少，从而让您更有效地利用计算资源。

有关每个部署场景的更多详细信息，请阅读在 Kubernetes 中部署application服务，第 2 部分。

用例： 卸载应用程序的身份验证和授权

解决方案： 在入口点集中进行身份验证和授权

应用程序和服务内置的一个常见非功能性需求是身份验证和授权。 从小规模来看，这种做法增加了可控的复杂性，当应用程序不需要频繁更新时，这是可以接受的。 但随着发布速度和规模的加快，将身份验证和授权集成到您的应用程序中变得难以实现。 确保每个应用程序维护适当的访问协议可能会分散应用程序的业务逻辑，或者更糟的是，可能会被忽视并导致信息泄露。 虽然使用 SSO 技术可以通过消除单独的用户名和密码并采用一组凭证来提高安全性，但开发人员仍然必须在其应用程序中包含代码以与 SSO 系统交互。

有一个更好的方法：将身份验证和授权卸载到 Ingress 控制器。

该图显示了将 Kubernetes 身份验证和授权卸载到 Ingress 控制器的过程

由于 Ingress 控制器已经仔细检查进入集群的所有流量并将其路由到适当的服务，因此它是集中身份验证和授权的有效选择。 这消除了开发人员构建、维护和复制应用代码中的逻辑的负担；相反，他们可以使用本机 Kubernetes API 在入口层快速利用 SSO 技术。

有关该主题的更多信息，请阅读使用 Okta 和 NGINX Ingress Controller 为 Kubernetes 实现 OpenID Connect 身份验证。

用例： 设置带有护栏的自助服务

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

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

虽然 Kubernetes RBAC 默认处于启用状态，但您需要注意，您的 Kubernetes 流量管理工具也应启用 RBAC，并能满足您组织的安全需求。 有了 RBAC，用户就可以获得完成工作所需的功能的访问权限，而无需等待票证被履行。 但是，如果没有配置 RBAC，用户可以获得他们不需要或无权获得的权限，如果权限被滥用，则可能导致漏洞。

Ingress 控制器是配置了 RBAC 后可以为众多人员和团队提供服务的工具的典型示例。当 Ingress 控制器允许细粒度访问权限管理（甚至细化到单个命名空间）时，您可以使用 RBAC 通过多租户实现资源的有效利用。

例如，多个团队可能会按如下方式使用 Ingress 控制器：

  • NetOps 团队– 配置应用的外部入口点（如主机名和 TLS 证书），并将流量控制策略委托给各个团队
  • DevOps 团队 A – 提供 TCP/UDP 负载均衡和路由策略
  • DevOps 团队 B – 配置速率限制策略以保护服务免受过度请求的影响
  • 身份团队– 管理身份验证和授权组件，同时配置 mTLS 策略作为端到端加密策略的一部分
  • DevSecOps 团队– 制定 WAF 策略

该图展示了具有不同角色的企业团队如何在同一 Ingress 控制器上部署其策略

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

用例： 实施端到端加密

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

对于处理敏感或个人信息的组织来说，端到端加密 (E2EE) 正成为越来越普遍的要求。 无论是财务数据还是社交媒体信息，消费者隐私期望与 GDPR 和 HIPAA 等法规相结合正在推动对此类保护的需求。 实现 E2EE 的第一步是设计您的后端应用程序以接受 SSL/TLS 流量，或者使用可从您的应用程序中卸载 SSL/TLS 管理的工具（分离安全功能、性能、密钥管理等的首选方案）。 然后，根据环境的复杂性配置流量管理工具。

最常见的情况： 使用入口控制器的 E2EE

当您的应用程序只有一个端点（简单应用程序或已“提升并转移”到 Kubernetes 的单片应用程序）或没有服务到服务通信时，您可以使用 Ingress 控制器在 Kubernetes 中实现 E2EE。

步骤 1： 确保您的 Ingress 控制器仅允许使用服务端或 mTLS 证书进行加密的 SSL/TLS 连接，理想情况下对于入口和出口流量都是如此。

第 2 步： 解决典型的默认设置，该设置要求 Ingress 控制器在将流量发送到应用程序之前对其进行解密和重新加密。 这可以通过几种方式实现——您选择的方法取决于您的 Ingress 控制器和要求：

  • 如果您的 Ingress 控制器支持 SSL/TLS 直通，它可以根据服务名称指示 (SNI) 标头路由 SSL/TLS 加密连接，而无需解密它们或需要访问 SSL/TLS 证书或密钥。
  • 或者，您可以设置 SSL/TLS 终止，其中 Ingress 控制器终止流量，然后将其代理到后端或上游 - 以明文形式或通过使用 mTLS 或服务端 SSL/TLS 重新加密到您的 Kubernetes 服务的流量。

不太常见的情况： 使用入口控制器和服务网格的 E2EE

如果您的集群内存在服务到服务通信，则需要在两个层面上实现 E2EE：使用 Ingress 控制器的入口出口流量和使用服务网格的服务到服务流量。 在 E2EE 中，服务网格的作用是确保只有特定的服务才可以相互通信，并且以安全的方式进行通信。 为 E2EE 设置服务网格时，您需要通过两个因素启用零信任环境：服务之间的 mTLS（设置为需要证书）和服务之间的流量访问控制（规定哪些服务被授权通信）。 理想情况下，您还可以在应用（由服务网格和入口出口控制器管理）之间实现 mTLS，以实现整个 Kubernetes 集群的真正 E2EE 安全性。

有关加密在线路上暴露的数据的更多信息，请阅读NGINX 服务网格中的 mTLS 架构。

用例： 确保客户端使用具有可信实现的强密码

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

在软件行业，FIPS 通常指专门关于密码学的出版物FIPS PUB 140-2密码模块的安全要求，这是美国和加拿大共同努力的结果。 它规范了两国联邦机构为保护敏感信息而接受的加密模块的测试和认证。 “但是等等！”你说。 “我不关心 FIPS，因为我不与北美政府实体合作。” 无论您的行业或地理位置如何，遵守 FIPS 都是明智之举，因为 FIPS 也是事实上的全球加密基准。

遵守 FIPS 并不难，但它要求您的操作系统和相关流量管理工具都能在 FIPS 模式下运行。 人们普遍误以为，只要在 FIPS 模式下运行操作系统即可实现 FIPS 合规性。 即使操作系统处于 FIPS 模式，与 Ingress 控制器通信的客户端仍有可能未使用强密码。 在 FIPS 模式下运行时，您的操作系统和 Ingress 控制器可能仅使用典型 SSL/TLS 密码的子集。

为 Kubernetes 部署设置 FIPS 分为四个步骤：

  • 步骤 1： 为 FIPS 模式配置操作系统
  • 第 2 步： 验证操作系统和 OpenSSL 处于 FIPS 模式
  • 步骤3： 安装 Ingress 控制器
  • 步骤4： 通过执行 FIPS 状态检查来验证是否符合FIPS 140-2

在下面的示例中，当 NGINX Plus 使用的操作系统和 OpenSSL 实现都启用了 FIPS 模式时，所有往返于 NGINX Plus 的最终用户流量都使用经过验证的、启用 FIPS 的加密引擎进行解密和加密。

该图展示了使用 NGINX Ingress Controller 和 NGINX App Protect 在 Kubernetes 中实施 FIP

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

使用 NGINX 让 Kubernetes 更加安全

如果您准备实施部分（或全部）安全方法，则需要确保您的工具具有正确的特性和能力来支持您的用例。 NGINX 可以通过我们的一套适用于生产的 Kubernetes 流量管理工具提供帮助：

  • NGINX Ingress Controller -基于 NGINX Plus 的Kubernetes Ingress 控制器，可处理高级流量控制和整形、监控和可见性、身份验证和 SSO，并充当 API 网关。

  • F5 NGINX App Protect – 基于 F5 市场领先的安全技术构建，为现代应用程序和 API 提供全面保护，并与 NGINX Ingress Controller 和 NGINX Plus 集成。 使用模块化方法实现部署场景的灵活性和最佳资源利用率：

    • NGINX App Protect WAF——一款强大、轻量级的 WAF，可防御 OWASP Top 10 及以上的攻击，并且符合 PCI DDS 合规性。

    • NGINX App Protect DoS – 跨云和架构进行行为 DoS 检测和缓解，提供一致且自适应的保护。

  • F5 NGINX 服务网格——轻量级、交钥匙、开发人员友好的服务网格，以 NGINX Plus 作为企业侧车。

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

阅读有关 F5 NGINX 的更多博客文章 ›

“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息，请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”