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

vlambda
2022-04-13

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

Jenn Gile

职位：NGINX产品营销经理

公司：F5

编者按——本文介绍了您可以使用 Kubernetes 流量管理工具解决的六个安全用例，该工具允许 SecOps 与 DevOps 和 NetOps 更好地协作保护云原生应用和 API。限于篇幅，我们将分为上下两篇发布。

有三个因素使云原生应用比传统应用更难以保护：

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

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

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

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

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

抵御 OWASP 十大安全漏洞和拒绝服务（DoS）攻击

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

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

实施端到端加密

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

用例1

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

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

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

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

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

专门的工程团队

如果有一支工程团队负责工具开发（而非社区志愿者），那么您就知道有一群人会全力保障该工具的健康，并会优先考虑尽快发布补丁。

集成的代码库

只要不依赖外部项目（就像我们在 OpenResty 案例中讨论的那样），打补丁就快速多了。

有关 CVE 漏洞补丁的更多信息，请参阅。

用例2

抵御 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，以有效平衡全局保护和自定义的保护。

前门或边缘

如果不采用“深度防御”策略，那么也可以只部署在二者其一的位置上，具体取决于所有权。当传统 NetOps 团队负责管理安全性时，他们可能习惯将 WAF 部署在传统代理（外部负载平衡器）上。但是，熟悉 Kubernetes 的 DevSecOps 团队（更喜欢将安全配置放在集群配置附近）可能会选择在 Ingress Controller 层面上部署 WAF。

按服务service 或按 pod

如果您的团队对服务或应用有着特定的要求，则可以根据需求部署额外的 WAF。但要注意：这些位置的部署成本更高一些。这种方法不仅会拖慢开发速度并增加云预算，而且还会提高与故障排除工作相关的运营成本（例如在排查意外拦截流量的 WAF 时）。

DoS 防护工具的部署位置

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

用例3

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

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

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

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