谷歌云waf如何实现 对容器化与微服务环境的保护策略

1. 概述与准备工作

- 目标：在 GKE/Anthos 或带有 Ingress 的微服务上使用 Google Cloud Armor（GCP 的 WAF）实现边缘防护与规则控制。
- 前提：有 GCP 项目、已启用 Compute/Networking APIs、gcloud 已安装并登录、GKE 集群或负载均衡器（HTTP(S) LB）已就绪。

2. 架构与选择点

- 将 Cloud Armor 绑定到 HTTP(S) 负载均衡器的 BackendService 或 URL map；GKE 的 Ingress（GLBC）会创建该 LB。
- 对于 Service Mesh（如 Istio/Anthos），建议在边缘使用 Cloud Armor，再结合网格内 mTLS 与策略。

3. 创建 Cloud Armor 安全策略

- 命令：gcloud compute security-policies create my-waf-policy --description="WAF for GKE services"
- 验证：gcloud compute security-policies list | grep my-waf-policy
- 小贴士：先从预置的GoogleManagedRules着手，后续添加自定义规则。

4. 添加预置与自定义规则

- 添加预置规则集：gcloud compute security-policies rules create 1000 --security-policy=my-waf-policy --action=deny-403 --description="OWASP CRS" --expression="evaluatePreconfiguredExpr('csf:crs/1')"（示例，实际使用需参考官方表达式格式）。
- 自定义规则示例（IP黑名单）：gcloud compute security-policies rules create 1100 --security-policy=my-waf-policy --match-expression="origin.ip == '203.0.113.5'" --action=deny-403 --description="block bad IP"

5. 将策略绑定到后端服务（GKE Ingress）

- 找到 GKE 创建的 BackendService：gcloud compute backend-services list --global
- 绑定策略：gcloud compute backend-services update BACKEND_SERVICE_NAME --global --security-policy=my-waf-policy
- 若使用 GKE Ingress 控制器，确保 ingress 的 backendServiceAnnotations 支持并触发 LB 更新。

6. 针对容器化微服务的细化配置

- 按服务分流：对不同 BackendService 使用不同安全策略（例如管理面/外部接口更严格）。
- API 网关/路径级规则：在 URL map 或 Cloud Armor 中使用基于路径的规则与速率限制。

7. 限流、速率限制与自动化

- 创建速率限制规则：gcloud compute security-policies rules create 1200 --security-policy=my-waf-policy --expression="request.headers['x-forwarded-for']" --action=throttle --rate-limit-threshold=100 --rate-limit-period=60
- 使用 Terraform 管理 security_policy 与 backend_service 以实现可重复部署。

8. 日志、监控与测试

- 打开 Cloud Armor 日志到 Cloud Logging：在安全策略中启用 logging，或在 LB 的 BackendService 设置 logging。
- 测试：使用 curl 模拟攻击与正常请求；示例：curl -H "User-Agent: sqlmap" https://your-service.example.com -I，观察是否被 deny 并在日志中出现。

9. Istio / Anthos 集成建议

- 边缘防护与网格内策略：让 Cloud Armor 负责外部流量过滤，Istio 负责服务间授权与速率控制。
- 若使用 Anthos Service Mesh，配合 Cloud Armor 的预置规则和 Istio Envoy 策略进行纵深防御。

10. 常见故障与排查步骤

- 问题：规则不生效 -> 检查 backend-service 是否已绑定策略；gcloud compute backend-services describe NAME --global。
- 检查日志、LB 配置与 URL map 是否与预期匹配，确认 ingress-controller 是否正确更新 LB。

11. 安全运营建议

- 持续调整：开始以宽松模式（log-only 或预置规则）观察，再逐步封禁。
- 自动化与审计：通过 Terraform / CI 将规则纳入代码治理，并定期审计日志与误报率。

12. 问：Cloud Armor 能否直接保护 Pod 内部流量？

Cloud Armor 作用于边缘 HTTP(S) 负载均衡层，不能直接在 Pod 网络内部过滤，建议结合网格（Istio）或 Network Policy 在集群内做纵深防护。

13. 答：如何快速验证策略是否生效？

使用 curl 或工具模拟恶意请求（如 SQLi 特征），并在 Cloud Logging 中检索 securityPolicyMatched、action 字段；同时观察返错码（403 等）。

14. 问：在多租户微服务场景，如何分配策略？

推荐按 BackendService 或 URL path 做粒度策略，每个租户或租户组对应不同 backend 与 security policy，结合速率限制与自定义规则降低误封风险。