Google Cloud Functions意外部署溯源请求：排查非手动部署来源

1. 深挖Cloud Audit Logs完整记录 #

控制台默认日志可能漏了关键操作，直接查Cloud Audit Logs里cloudfunctions.googleapis.com相关的部署事件，重点找UpdateFunction或CreateFunction操作。用gcloud命令精准过滤时间范围：

gcloud logging read 'resource.type="cloud_function" AND protoPayload.methodName:"google.cloud.functions.v1.CloudFunctionsService.UpdateFunction"' --start-time="2024-03-15T05:30:00Z" --end-time="2024-03-15T05:50:00Z"

日志里会明确显示调用者身份（用户邮箱/服务账号）、请求IP，能直接定位操作来源。

2. 排查自动部署触发源 #

• 查Cloud Build触发器：看看这些函数是否绑定了代码仓库的自动构建触发器，可能是代码自动提交触发了部署，去Cloud Build控制台看对应时间的运行记录。
• 检查基础设施工具：如果用了Terraform、Ansible这类工具，查它们的执行日志，是否在那个时间点自动执行了部署操作。
• 确认平台自动更新：Google会为修复安全漏洞自动升级函数的运行时镜像，这种操作也会更新部署时间，但不会改动你的函数代码，属于正常维护。

3. 验证函数代码完整性 #

对比异常部署前后的代码，确认有没有被篡改：

• 用gcloud functions describe FUNCTION_NAME查看函数的源代码哈希值，和你3月7日手动部署的本地版本哈希对比。如果一致，说明只是部署时间被更新，代码没动，大概率是平台自动操作。
• 如果哈希不一致，结合Audit Logs里的调用者信息，进一步排查权限泄露问题。

4. 检查账号权限与安全告警 #

• 去IAM控制台核对所有有权限部署Cloud Functions的账号，看有没有新增的可疑账号或服务账号，尤其是最近变更过权限的。
• 打开Security Command Center，查看是否有陌生IP登录、权限提升这类异常告警。

安全结论参考 #

• 若排查出是Google自动运行时更新：完全不用担忧，属于平台正常维护，函数核心代码未被修改。
• 若为内部自动化工具触发：确认工具触发逻辑是否正常，比如是不是有意外的代码提交触发了部署。
• 若发现陌生身份的部署操作：立即撤销该身份的相关权限，修改账号密码，进一步排查入侵路径。

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