浏览 1k
原文作者：Owen Garrett of F5
原文链接：在 Kubernetes 中部署应用交付服务（第 2 部分）
转载来源：NGINX 中文官网
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
本文是以下系列博文中的一篇：
- 在 Kubernetes 中部署应用交付服务（第 1 部分）解释了为什么因分治而重复使用的应用服务反而可以提高整体效率：因为 NetOps 和 DevOps 团队有不同的要求，所以他们会选择最适合他们特定需求的工具。
- 在 Kubernetes 中部署应用交付服务（第 2 部分）（本文）以 WAF 为例，就应用交付服务在 Kubernetes 环境中的部署位置提供了指导。您可以根据自己的需求，以基于每个 Service 或基于每个 POD 的方式，将 WAF 部署在 Kubernetes 环境的“前门” 或 Ingress Controller上。
在本系列博文的上一篇，我们讨论了 DevOps 在控制应用部署、管理和交付方式方面日益增长的影响力。虽然这可能看似会引发与 NetOps 团队的冲突，但企业需要明白的是，每个团队都有不同的职责、目标和运维模式。要想实现专门化并提高运维效率，关键是要慎重选择负载均衡和 Web 应用防火墙 (WAF) 等应用交付服务的部署位置，在某些情况下还需要重复部署这些应用交付服务。
在确定应用交付服务的部署位置时，需遵循两个主要标准：
- 您希望部署的服务是 (a) 针对特定应用或业务，还是 (b) 通用于所有应用？
- 服务配置是 (a) 属于 DevOps 或 DevSecOps 管理，还是 (b) 属于 NetOps 或 SecOps 管理？
如果您倾向于 (a)，那么最好将服务部署到靠近需要它的应用附近，并将控制权交给负责这些应用运维的 DevOps 团队。
如果您倾向于 (b)，则最好将服务部署到基础架构的前门，并由负责保证整个平台成功运维的 NetOps 团队管理。
此外，如果需要折中时，您还需要考虑技术上的契合度。想要部署的服务是否可以使用 DevOps 或 NetOps 团队熟悉的生态系统工具进行部署和运维？这些相应的工具能否提供必要的功能、配置接口和 API 监控？
Kubernetes 引入了更多选择
在 Kubernetes 环境中，您可以在以下几个位置部署应用交付服务：
- 前门：外部的负载均衡器或代理
- Ingress Controller：Kubernetes 的进入点
- 基于每个 Service 的代理：内部服务的代理层
- 基于每个Pod的代理：针对每个 Pod 的边车型（sidecar）代理
我们以 Web 应用防火墙 (WAF) 为例。WAF 策略会实施先进的安全防护措施来检查和拦截恶意流量，但这些策略通常需要针对特定应用进行调整，以最大程度地减少误报数量。
在前门部署 WAF
当满足以下条件时，请考虑在基础架构的前门部署 WAF 设备和相关策略：
- WAF 策略由中央 SecOps 团队创建和治理。
- WAF 设备是由 NetOps 团队控制的专用设备。
- 所有（或大多数）应用必须受同一 WAF 策略的保护，并且几乎不需要针对特定应用进行调整。
- 您希望能够清楚地显示是否符合安全性和治理策略，并使用单一控制点拦截任何可能的入侵或漏洞。
在 Ingress Controller 上部署 WAF
当满足以下条件时，请考虑在 Ingress Controller 上部署 WAF 应用交付服务：
- WAF 策略由 DevOps 或 DevSecOps 团队指导实施。
- 您希望在基础架构层集中管理 WAF 策略，而不是将它们委派给各个应用。
- 您大范围地使用 Kubernetes API 来管理应用的部署和运维操作。
这种方法仍然支持中央 SecOps 团队定义 WAF 策略。他们能够以一种可以轻松导入到 Kubernetes 中的方式定义 WAF 策略，然后由负责 Ingress Controller 的 DevOps 团队将 WAF 策略分配给特定的应用。
从 NGINX Plus Ingress Controller 1.8.0 版开始，NGINX App Protect WAF 模块可直接部署在 Ingress Controller 上。所有 WAF 配置都使用 Ingress 资源进行管理，并通过 Kubernetes API 进行配置。
基于每个 Service 部署 WAF
您还可以将 WAF 部署为 Kubernetes 内部的代理层，放在需要 WAF 防护的一个或多个特定 Service 的前面。显然，这种方法要求 WAF 必须是以软件形式存在以便能够轻松、高效地部署在容器内。
当满足以下条件时，请考虑按服务将 WAF 部署为代理：
- WAF 策略由 DevSecOps 团队指导实施，并只针对少数几项服务。
- 策略更新可通过合适的容器感知 API 管理，也可通过更新 WAF 代理的 Deployment 来实现。
- WAF 设备在 Kubernetes 环境中正常运行。
例如，带有 App Protect 的 NGINX Plus 就可以通过这种方式轻松完成部署。您可以采取以下操作，使 Deployment 对受其保护的服务和调用它们的客户端都不可见：
- 将需要保护的服务名称从（例如）WEB-SVC 重命名为 WEB-SVC-INTERNAL
- 将 WAF 代理部署到一个名为 WEB-SVC 的新 Kubernetes 服务中
- 将 WAF 代理配置为转发请求至 WEB-SVC-INTERNAL
- 此步骤为可选步骤：使用 Kubernetes 网络策略强制规定只有 WAF 代理可以与 WEB-SVC-INTERNAL通信
基于每个 Pod 部署 WAF
最后，您还可以在 Pod 中部署 WAF，作为 Pod 中运行的应用的入向代理。在这种情况下，WAF 就成为了应用的一部分。
当满足以下条件时，请考虑以这种方式部署 WAF：
- WAF 策略只针对特定的应用。
- 您希望将策略和应用紧密绑定在一起，以便在开发流水线的所有节点上都使用该 WAF 策略部署应用。
- 您可能经常需要把应用频繁地重新部署到不同的集群中，但又不想为每个集群添加 WAF 服务和合适的配置。
如果您拥有需要特定安全策略的传统应用，并且您希望将该应用打包成容器以使其更容易部署和扩展，那么此方法再合适不过了。
关于 Service Mesh 的说明
基于每个 Pod 代理的模式与 Istio、Aspen Mesh、Linkerd、NGINX Mesh 等服务网格推广的边车型（sidecar）代理并不相同：
| 基于每个 Pod 代理 | Sidecar 代理 | |
|---|---|---|
| 注入到 Pod | 在构建时 | 在部署时（自动注入） |
| 流量覆盖范围 | 仅入向 | 入向和出向 |
| 配置的所有者 | 应用开发人员 | DevOps 或网格所有者 |
| 特性 | 功能非常强大 | 通常简易轻便 |
| Deployment | 添加到需要它的 Pod 中 | 由网格基础设施部署到任何位置 |
企业通常很少使用 WAF 检查和保护东西向流量，并且目前还没有服务网格能够支持您在所选的 sidecar 代理中轻松地配置完整的 WAF。Ingress Controller 提供了强大的安全防护边界，针对不受信任的外部客户端，它是为入向流量（南北向流量）提供保护的最有效位置。
结语
现在，您在 WAF 等应用交付服务的部署位置方面拥有了更多选择，这意味着您将有更多的机会将 Kubernetes 平台的运营效率最大化。
| 在前门 | Ingress Controller | 基于每个 Service 的代理 | 基于每个 Pod 的代理 | |
|---|---|---|---|---|
| 可用性 | NGINX App Protect 或其他 WAF 解决方案 | NGINX Plus Ingress Controller 1.8.0 | NGINX App Protect 或类似的软件 WAF | NGINX App Protect 或类似的软件 WAF |
| 受众 | SecOps | SecOps/DevSecOps | DevSecOps | 应用所有者 |
| 范围 | 全局 | 每个 service/URI | 每个 service | 每个 endpoint |
| 性价比 | 良/优（与 ADC 等其他服务整合） | 优（与 Ingress Controller 整合） | 良 | 差（每个 POD 使用专用 WAF） |
| 配置 | nginx.conf | Kubernetes API | nginx.conf | nginx.conf |
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源： 开源社区官网 | 微信公众号
按点赞数排序
按时间排序
各位老师您好，我看到总结中提到基于每个 Pod 的代理的性价比是最差的，如果我们使用的sidecar WAF和业务紧密结合一同拉起，我觉得性价比并不是最差的，并且通过NIM统一管理可以达到快速解耦，快速变更安全策略
赞同0
回复
举报发表于2022-12-01 22:07
点赞 4
浏览 1.7k点赞 2浏览 1k点赞 1浏览 1.2k
微信公众号
加入微信群
