请求量达阈值后跳转reCaptcha的Cloud Armor配置问询

一、直接用Cloud Armor WAF规则实现全站请求量阈值触发重定向是否可行？ #

不可行。原因在于：

• Cloud Armor的速率限制规则默认基于单个客户端IP/会话这类维度做限制，无法直接关联全站总请求量设置触发条件。
• 虽然Cloud Armor支持将规则动作设为redirect到reCaptcha Enterprise，但规则条件无法绑定全站总请求量的阈值，没法实现“全站请求达300req/s就触发重定向”的逻辑。

二、指标告警+Pub/Sub+Cloud Function方案的可行性与注意事项 #

这个方案是可行的，是当前实现需求的合理路径，但需要注意以下细节：

核心流程要点 #

1. 指标选择：使用Cloud Armor的compute.googleapis.com/security_policy/request_count指标，按你的安全策略维度聚合，以此获取全站总请求量数据。
2. 告警配置：在Cloud Monitoring中创建基于该指标的告警，设置阈值为300req/s，触发时将事件推送到指定Pub/Sub主题。
3. Cloud Function逻辑：
   • 编写函数监听Pub/Sub主题事件，收到“请求量超标”的告警事件时，调用Cloud Armor API启用针对0.0.0.0/0的重定向规则（动作设为跳转至reCaptcha Enterprise）。
   • 收到“请求量恢复正常”的事件时，调用API禁用该规则，恢复正常访问。
4. 权限配置：给Cloud Function绑定的服务账号授予compute.securityPoliciesEditor权限，确保它能修改Cloud Armor的安全策略规则。

关键注意事项 #

• 延迟问题：Cloud Monitoring的告警存在分钟级延迟，该方案无法应对瞬时流量尖峰，更适合处理持续高流量场景。
• 规则优先级：需将重定向规则的优先级设得高于正常业务规则，确保启用后能优先匹配生效。
• 恢复逻辑：必须配置告警的恢复通知，否则请求量回落规则会一直处于启用状态，导致用户无法正常访问。
• 测试验证：提前测试告警触发、Pub/Sub消息推送、Cloud Function调用API修改规则的全链路，确保各环节正常工作。

内容的提问来源于stack exchange，提问作者Rodehoed