Cloud Endpoints能否实现API密钥按微服务权限管控？

首先直接回应你的核心问题：Cloud Endpoints本身并没有开箱即用的细粒度API密钥权限控制能力——它默认仅能控制API密钥是否有权访问整个Endpoints服务，无法直接限定密钥可访问的特定路径、方法或微服务。不过基于你的需求（单用户单密钥、权限可修改、GCP原生工具、预算有限），咱们可以从你提出的方案里挑出最适合的，再补充一些优化细节：

方案1：Cloud Functions代理 + Firestore（最推荐，成本低易维护） #

这个方案完美契合你的需求，而且完全基于GCP原生工具，开发和维护成本都不高，步骤大概是这样：

• 权限存储：在Firestore里创建一个集合（比如api-key-permissions），每条文档对应一个API密钥，字段包含：
  • api_key_hash：用API密钥的哈希值作为文档ID（避免明文存储密钥）
  • allowed_paths：数组，比如["/market-price", "/orders/*"]
  • allowed_methods：数组，比如["GET", "POST"]
  • user_id：关联的用户ID（方便后续管理）
• 请求流程：

  用户请求（带Google API密钥）→ Cloud Endpoints验证密钥有效性 → 转发请求到Cloud Functions代理 → 代理从请求头提取API密钥并生成哈希，查询Firestore校验权限（路径+方法是否匹配）→ 权限通过则转发到对应微服务（Cloud Functions/Cloud Run），不通过则返回403

• 监控与日志：
  • 在Cloud Functions里添加日志，把每个请求的密钥哈希、路径、方法、结果记录到Cloud Logging，后续可以用Cloud Monitoring创建仪表盘，跟踪每个密钥的调用次数、错误率等指标
  • 利用Cloud Audit Logs跟踪Firestore里权限文档的修改记录，确保权限变更可追溯

方案2：自定义ESP适配（灵活性高但开发成本高） #

如果你需要更贴近Endpoints原生的集成方式，可以自定义ESP（Endpoints用的Extensible Service Proxy）：

• ESP基于Envoy代理，你可以编写自定义的Envoy过滤器，在Endpoints完成API密钥验证后，额外添加一个权限校验逻辑（比如从Firestore或Cloud Memorystore读取密钥权限）
• 这个方案的优势是不需要额外的代理层，请求流程更简洁，但需要你有Envoy或Go/C++的开发经验，而且后续ESP版本升级可能需要适配自定义代码，维护成本比方案1高

方案3：自行管理所有认证（不推荐） #

完全自己处理认证和权限的话，工作量会非常大——你需要自己实现密钥的生成、存储、验证、权限校验，还要搭建监控系统，这相当于重复造了Endpoints的轮子，而且很难达到GCP原生工具的安全性和稳定性，所以不建议采用。

额外优化建议 #

• 密钥安全：不要在Firestore里明文存储API密钥，用哈希值作为文档ID是更安全的选择，也可以结合Cloud KMS加密敏感字段
• 权限即时生效：Firestore的查询是实时的，修改权限后下一次请求就会生效，完全满足你“轻松修改权限”的需求
• 批量权限管理：可以结合Cloud Functions写一个简单的后台脚本，批量创建或修改密钥的权限，方便管理大量用户

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