利用流量管理工具保护Kubernetes安全的六种方法

NGINX | 2021年12月20日

编者：本文是一个共10篇的系列文章之一：

还可以免费下载包含全套博客文章的电子书《推动Kubernetes从测试走向生产》。

正如在不影响速度的情况下保护云原生应用安全中所述，我们观察到，有三个因素使云原生应用比传统应用更难保护：

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

虽然这三个因素对安全的影响可能同样显著，但第三个因素或许最难解决，因为它最具“人为”属性。当SecOps团队没有能力或未获授权保护云原生应用时，部分后果显而易见（漏洞和安全事件），但也有一些隐性影响，包括敏捷性下降和数字化转型停滞。

下面深入分析这些隐性成本。组织选择Kubernetes，是因为它有望提高敏捷性并节省成本。但当Kubernetes环境中发生安全事件时，大多数组织会将其Kubernetes部署撤出生产环境。这会拖慢对组织未来至关重要的数字化转型计划，更不用说还会浪费工程投入和资金。因此，若要推动Kubernetes从测试环境进入生产环境，就必须将安全视为一项战略要素，由组织内所有人共同负责。

本文将介绍可使用Kubernetes流量管理工具解决的6个安全用例，帮助安全运维团队与开发运维和网络运维团队协作，更好地保护云原生应用和API。这些技术通常会结合使用，以制定全面的安全策略，在保护应用和API的同时，尽量减少对客户的影响。

快速修复CVE，避免网络攻击
阻止OWASP十大风险和拒绝服务攻击
从应用卸载身份验证和授权
设置有防护机制的自助服务
实施端到端加密
确保客户端使用采用可信实现的强密码算法

安全与身份术语

在介绍用例之前，先简要了解一下本文中会出现的一些安全和身份术语。

身份验证和授权：确保只有“适当的”用户和服务才能访问后端或应用组件所需的功能：
- 身份验证：验证身份，确保发出请求的客户端与其声称的身份一致。通过密码或JSON Web Token（JWT）等身份令牌实现。
- 授权：验证访问资源或功能的权限。通过访问令牌实现，例如会话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级别，用于同一集群中两个服务之间的通信。有关SSL/TLS和mTLS的详细介绍，请参阅什么是mTLS？（F5 Labs）。
单点登录（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可防御试图通过窃取敏感数据或劫持系统来危害目标的攻击。一些供应商将WAF和DoS防护整合到同一工具中，另一些供应商则分别提供WAF和DoS工具。
零信任：一种常用于安全要求较高的组织、但适用于所有组织的安全理念，要求数据在存储和传输的各个阶段都得到保护。这意味着组织决定默认不“信任”任何用户或设备，而是要求对所有流量进行全面验证。零信任架构通常结合使用身份验证、授权和mTLS，采用这种架构的组织也很可能会实施E2EE。

用例：快速修复CVE，避免网络攻击

解决方案：使用可及时主动发送补丁通知的工具

根据Ponemon Institute的一项研究，2019年，从关键或高优先级漏洞的补丁发布，到组织发现有人试图利用该漏洞发起攻击，平均有43天的“宽限期”。F5 NGINX发现，在随后的几年中，这一时间窗口显著缩短（甚至缩短至2021年Apple iOS 15事件中的零日）。因此，我们建议尽快安装补丁。但如果CVE公布后数周甚至数月，流量管理工具的补丁仍未发布，该怎么办？

由社区贡献者（而非专门的工程团队）开发和维护的工具，其补丁可能会在CVE公布数周甚至数月后才发布，因此组织不太可能在这43天的窗口期内完成修补。在一个案例中，OpenResty用了4个月才应用与NGINX相关的安全补丁。这意味着所有使用基于OpenResty的Ingress控制器的用户都面临了至少4个月的漏洞风险。实际上，依赖开源项目的软件通常还需要更长时间才能获得补丁。

为尽快修补CVE，选择流量管理工具时应关注以下两个特征：

专职工程团队：如果工具开发由工程团队而非社区志愿者负责，就意味着有一支团队专门维护工具的健康状态，并能优先安排尽快发布补丁。
集成式代码库，由于不依赖任何外部组件（如前文讨论的OpenResty），只需一个敏捷冲刺周期即可发布补丁。

要详细了解CVE修补，请阅读《使用NGINX Plus快速轻松地缓解安全漏洞》。

用例：阻止OWASP十大安全风险和DoS攻击

解决方案：部署灵活且适用于Kubernetes的WAF和DoS防护

为Kubernetes应用选择合适的WAF和DoS防护时，除功能外，还需考虑两个因素：

灵活性：在某些场景下，更适合在Kubernetes内部部署工具，因此需要不受基础设施限制、可在Kubernetes内部或外部运行的工具。所有部署使用同一工具，便于重复使用策略，并降低安全运营团队的学习门槛。
占用空间：合适的Kubernetes工具占用空间小，能够合理消耗资源，并尽量减少对吞吐量、每秒请求数和延迟的影响。DevOps团队往往认为安全工具会拖慢应用，因此不愿采用。选择占用空间小的高性能工具，可以提高采用的可能性。

整合WAF和DoS防护的工具看似效率更高，但实际上可能会在CPU使用率（因占用空间较大）和灵活性方面出现问题。即使不需要同时使用这两项功能，也必须一并部署WAF和DoS防护。最终，这两个问题可能会增加Kubernetes部署的总体拥有成本，并挤占其他必要工具和服务的预算。

为组织选择合适的安全工具后，下一步是确定这些工具的部署位置。通常可在以下四个位置部署应用服务，以保护Kubernetes应用：

在入口处（位于外部负载均衡器上，例如F5 NGINX Plus或F5 BIG‑IP），适合提供“粗粒度”全局保护，因为可跨多个集群应用全局策略
在边缘位置（在Ingress控制器（例如F5 NGINX Ingress Controller）上），非常适合在单个集群中提供标准化的“细粒度”保护
在服务层（在NGINX Plus等轻量级负载均衡器上），当集群中有少量服务共同需要使用特定策略时，这可能是必要的方法
在Pod层面（作为应用的一部分），这是一种高度定制的方法，适用于策略专门针对该应用的情况

此图显示了在Kubernetes中部署应用服务的4个位置：前端入口、Ingress控制器、每服务代理和每Pod代理

那么，这四种方案中哪一种更合适？这要视情况而定！

WAF的部署位置

首先，我们来了解WAF的部署选项，因为这通常需要更细致地权衡。

前端入口和边缘：如果贵组织倾向于采用“纵深防御”安全策略，建议在外部负载均衡器和Ingress控制器上均部署WAF，以有效兼顾全局防护和自定义防护。
前端入口或边缘：如果未采用“纵深防御”策略，可以仅在一个位置部署，具体位置取决于安全职责的归属。由传统NetOps团队负责安全时，该团队可能更习惯在传统代理（外部负载均衡器）上管理WAF。而熟悉Kubernetes的DevSecOps团队（并且希望将安全配置与集群配置放在相近位置）则可以选择在Ingress层部署WAF。
按服务或Pod：如果团队对其服务或应用有特定要求，可以按需部署额外的WAF。但请注意，在这些位置部署WAF的成本更高。除了增加开发时间和云预算外，这种选择还可能增加与故障排除相关的运营成本，例如需要确定“我们的哪个WAF意外阻止了流量？”

在何处部署DoS防护

DoS攻击防护的部署更为简单，因为只需部署在一个位置，即前端入口或Ingress控制器。如果在前端入口和边缘均部署WAF，建议将DoS防护部署在前端入口WAF之前，因为该位置覆盖范围最广。这样可以在不需要的流量到达WAF之前将其过滤掉，从而更高效地利用计算资源。

要详细了解这些部署场景，请阅读《在Kubernetes中部署应用服务（第2部分）》。

用例：从应用卸载身份验证和授权

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

应用和服务通常会内置身份验证和授权这一非功能性要求。在规模较小且应用无需频繁更新时，这种做法增加的复杂性尚在可控范围内。但随着规模扩大和发布速度加快，将身份验证和授权集成到应用中会变得难以为继。确保每个应用都采用适当的访问协议，可能会分散对应用业务逻辑的关注；更严重的是，这项工作可能被忽视，进而导致信息泄露。虽然单点登录（SSO）技术以一组凭据取代各自独立的用户名和密码，有助于提升安全性，但开发人员仍需在应用中加入与SSO系统对接的代码。

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

Ingress控制器已在检查进入集群的所有流量，并将其路由到相应的服务，因此非常适合用于集中式身份验证和授权。这样，开发人员无需在应用程序代码中构建、维护和复制相关逻辑，而是可以使用原生Kubernetes API，在入口层快速利用SSO技术。

要进一步了解此主题，请阅读《使用Okta和NGINX Ingress Controller为Kubernetes实施OpenID Connect身份验证》。

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

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

Kubernetes使用基于角色的访问控制（RBAC）来控制不同类型的用户可访问的资源和可执行的操作。这是一项重要的安全措施，管理员或超级用户可借此确定单个用户或用户组与集群中的任何Kubernetes对象或特定命名空间进行交互的方式。

虽然Kubernetes默认启用RBAC，但仍需确保Kubernetes流量管理工具也启用了RBAC，并能满足组织的安全需求。配置RBAC后，用户可以按权限访问工作所需的功能，无需等待工单处理。但如果未配置RBAC，用户可能会获得不需要或无权拥有的权限；一旦这些权限被滥用，可能会产生安全漏洞。

配置RBAC后，Ingress控制器便是可服务众多人员和团队的典型工具。当Ingress控制器支持精细化访问管理，甚至可细化到单个命名空间时，便可利用RBAC通过多租户机制提高资源使用效率。

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

网络运维团队：配置应用的外部入口点（例如主机名和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管理从应用中卸载（在安全功能分离、性能和密钥管理等方面，这是更合适的选择）。然后，根据环境的复杂程度配置流量管理工具。

常见场景：使用Ingress Controller实现E2EE

如果应用只有一个端点（例如简单应用，或通过“直接迁移”方式迁移到Kubernetes的单体应用），或者不存在服务间通信，则可以使用Ingress控制器在Kubernetes中实现端到端加密。

步骤1：确保Ingress控制器仅允许使用服务端证书或mTLS证书的加密SSL/TLS连接，最好同时涵盖入站和出站流量。

步骤2：处理常见的默认设置。该设置要求Ingress控制器先解密流量并重新加密，再将其发送到应用。可通过以下几种方式实现，具体方法取决于Ingress控制器和实际需求：

如果Ingress控制器支持SSL/TLS直通，则可以根据服务器名称指示（SNI）标头路由SSL/TLS加密连接，而无需解密连接，也无需访问SSL/TLS证书或密钥。
或者，也可以设置SSL/TLS终止，由Ingress控制器终止流量，然后将其代理到后端或上游。流量可以采用明文形式，也可以通过mTLS或服务端SSL/TLS重新加密后发送到Kubernetes服务。

较少见的场景：使用Ingress控制器和服务网格实现端到端加密

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

要详细了解如何加密在线路上传输的数据，请阅读《NGINX Service Mesh中的mTLS架构》。

用例：确保客户端使用由可信实现提供的强加密算法

解决方案：遵循联邦信息处理标准（FIPS）

在软件行业，FIPS通常指专门针对密码学的出版物，即《FIPS PUB 140-2 密码模块安全要求》。该标准由美国和加拿大共同制定，规范了两国联邦机构认可的密码模块测试与认证，以保护敏感信息。“但等等！”您可能会说，“我不关心FIPS，因为我不与北美政府机构合作。”无论身处哪个行业或地区，实现FIPS合规都可能是明智之举，因为FIPS也是全球公认的事实密码学基准。

遵循FIPS并不一定很困难，但操作系统和相关流量管理工具都必须能够在FIPS模式下运行。一个常见的误解是，只要让操作系统在FIPS模式下运行，就能实现FIPS合规。即使操作系统已在FIPS模式下运行，与Ingress控制器通信的客户端仍可能未使用强加密套件。在FIPS模式下运行时，操作系统和Ingress控制器可能只能使用常见SSL/TLS加密套件中的一部分。

为Kubernetes部署配置FIPS需要完成以下4个步骤：

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

在以下示例中，当操作系统和NGINX Plus使用的OpenSSL实现均启用FIPS模式时，所有进出NGINX Plus的最终用户流量都会使用经过验证且已启用FIPS的加密引擎进行解密和加密。

使用带有NGINX App Protect的NGINX Ingress Controller在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十大风险及其他威胁，并符合PCI DDS合规要求。
- NGINX App Protect DoS，基于行为的DoS检测与缓解，可跨云和架构提供一致且自适应的防护。
F5 NGINX Service Mesh，一款轻量级、开箱即用且对开发者友好的服务网格，采用NGINX Plus作为企业级边车代理。

申请30天免费试用，开始体验集成NGINX App Protect WAF和DoS的NGINX Ingress Controller，并下载永久免费使用的NGINX Service Mesh。