Secure Source Manager webhook加入服务账号认证：短期身份令牌接入受保护端点
2026年9月29日，Google Cloud宣布Secure Source Manager的webhook开始支持服务账号授权。启用后，平台为仓库服务账号生成Google签名的OpenID Connect（OIDC）ID令牌，并以Bearer令牌发送给目标端点。对把仓库事件接到受保护Cloud Run服务或函数的团队，这提供了短期身份认证路径，减少长期共享密钥的人工管理。
配图为AI生成的概念插图，表现携带短期身份凭证的事件投递，不是真实产品界面。
共享密钥与服务身份，维护方式不同
原有敏感查询字符串机制适合在URL参数中接收共享密钥、API key或令牌的目标。官方说明这些字符串通常是静态、长期有效的，需要自行创建、轮换和验证。新的服务账号方式使用短期令牌，适合能通过IAM验证Google OIDC ID令牌的端点。
因此，选择并不只取决于发送端有没有新开关。若目标系统只能识别原有查询参数，直接改为Bearer令牌可能导致所有事件被拒绝；若目标支持身份校验，则可以结合权限管理改进长期凭证维护。迁移前应先确认接收端的认证能力与所需受众，而不是把任意第三方webhook都视为兼容。
同样，受保护Cloud Run服务的身份验证与网络可达性是不同条件。令牌证明调用身份，不能自动建立一条原本不存在的网络路径。应分别检查目标地址、入口策略和调用权限，避免把连接超时误诊为令牌问题。
发送方能生成令牌，接收方也要认可身份
配置文档涉及Service Account User、服务代理生成令牌的相关权限，以及目标为Cloud Run时的Invoker权限。实际绑定应依据仓库服务账号、平台服务代理与接收服务分别核对，不能只给某个管理员更高权限便认为运行路径已经完成。
对接收服务而言，认证成功之后还要决定该仓库能触发哪些业务行为。一个可以接收事件的服务，未必应允许所有仓库执行部署、更新生产数据或发布通知。本文建议把仓库来源、事件类型和允许动作写入接收端的规则，令牌与业务授权共同发挥作用。
日志中也应避免完整记录Bearer令牌或共享密钥。调查通常只需请求标识、事件类型、仓库标识和验证结果；把凭证留进日志会扩大泄露面，抵消改用短期身份的一部分收益。
事件筛选应在接入时就收窄
Secure Source Manager现有webhook可以响应Push、拉取请求状态变化和拉取请求评论事件；这次新增的是认证路径，不是这些事件全部在9月29日首次上线。Push还可按Git引用的glob规则过滤分支，配置为空或星号时会覆盖所有分支。
这一默认范围值得专门核对。例如一个原本只希望对主分支构建的接收服务，如果没有限制分支，就可能收到开发分支事件。认证越可靠，系统越容易信任来自平台的消息，但“消息确实来自仓库”仍不等于“这条消息符合发布条件”。
在正式接入之前，可以先用只记录、不执行高影响动作的接收模式验证事件内容，确认不同触发条件产生的负载符合预期，再启用具体处理。该步骤是本文的部署建议，不应被描述为平台已经替用户实施的安全策略。
投递成功需要与业务完成分别检查
官方提供Test delivery入口，测试会把占位事件加入投递队列，可能数秒后才出现在历史中；Recent deliveries可以检查请求与响应。真实Push或合并操作也可用于验证，而最终还应检查下游服务中的构建或处理记录。
测试端点返回成功，只能说明这次接收过程达到相应状态。如果下游异步处理失败，或者同一事件被重复消费，业务结果仍可能不符合预期。接收方应使用可追踪的事件标识和幂等策略，区分“已接收”“处理中”“已完成”以及“需要人工处理”。
这次更新让仓库事件更容易接入基于云身份的受保护服务。其实际收益在于减少静态秘密管理，并把调用身份纳入统一权限体系；事件范围、动作授权和结果核对仍需要应用团队认真设计，才能形成可信的自动化链路。
