Google Cloud Service Account 是什么，应用程序为什么需要独立身份

Google Cloud Service Account是什么？理解应用身份、权限和临时凭证的关系

在Google Cloud中，Service Account可以理解为一种供应用程序、虚拟机、容器、自动化任务等非人类主体使用的身份。它与普通用户账号最大的区别在于，用户账号主要代表一个人，而Service Account主要代表一个工作负载或应用程序。

例如，一项自动备份任务需要访问Cloud Storage，一个运行在Compute Engine上的应用需要调用BigQuery，或者一个部署在Google Kubernetes Engine中的服务需要访问其他Google Cloud API，这些场景都不应该依赖某个员工的个人账号，而应该使用适合该工作负载的身份。

Google Cloud目前也提供Workload Identity Federation等机制，使运行在AWS、Azure、GitHub、GitLab或本地环境中的工作负载可以使用外部身份获得短期Google Cloud凭证，而不必长期保存Service Account密钥。

一、Service Account到底是什么

Service Account本身是一种IAM主体，可以被授予Google Cloud资源的IAM角色。

例如，一个负责处理订单的应用可以使用一个专门的Service Account，而另一个负责生成报表的应用使用另外一个Service Account。管理员再分别为这两个身份授予不同的角色。

这样形成的关系可以简单理解为：

应用程序 → Service Account → IAM角色 → 权限 → Google Cloud资源

例如，订单处理服务只需要访问某个Pub/Sub主题，就没有必要给它一个能够管理整个项目的管理员角色。

这种设计的核心价值并不是“给程序一个密码”，而是把工作负载的身份和权限管理从个人账号中独立出来。

二、Service Account并不是一组固定的JWT凭证

原文最大的技术错误之一，是把Service Account描述成由一组JWT凭证标识，并进一步声称“凭证默认有效期为1年”。

这并不准确。

Service Account是一个IAM身份，而不是一个JWT文件。应用在实际调用Google Cloud API时，可以通过不同的认证方式获得凭证。

Google Cloud明确区分了短期凭证和Service Account密钥。使用短期OAuth 2.0访问令牌时，默认有效期通常为1小时；而用户管理的Service Account密钥则属于另一种机制。

尤其需要注意，用户管理的Service Account密钥默认并不是“一年后自动过期”。Google Cloud文档明确指出，这类密钥默认不会自动过期，但企业可以通过组织策略为新创建的密钥设置有效期。

因此，把“Service Account凭证默认有效期为1年”作为普遍规则，是错误的。

三、应用到底怎样使用Service Account

在Google Cloud环境中，一种常见方式是把Service Account附加到Compute Engine等支持的资源上。

应用运行时，可以通过Google提供的身份机制获取短期凭证，然后使用这些凭证访问被授权的Google Cloud资源。

这种方式的优势在于，应用程序不需要把一个长期有效的私钥写进源代码。

例如，一个运行在Compute Engine上的图片处理程序需要读取Cloud Storage中的文件。管理员可以为它创建一个专用Service Account，只授予读取指定存储资源所需的权限，然后把该Service Account关联到计算资源。

应用只需要使用Google Cloud客户端库正常调用Storage API，认证过程由Google Cloud提供的身份机制完成。

这种方式比把JSON密钥文件放在服务器硬盘上更加安全。

四、为什么不应该让所有应用共用一个Service Account

Service Account最重要的安全价值之一，就是实现工作负载之间的身份隔离。

假设一家企业有三个服务：

订单服务负责处理订单。

报表服务负责读取数据。

备份服务负责将数据复制到备份存储。

如果三个服务全部使用同一个拥有大量权限的Service Account，那么其中任何一个服务遭到入侵，都可能获得其他业务所需要的权限。

更合理的做法是分别创建Service Account，并根据实际业务需求授权。

订单服务只获得订单处理所需要的权限，报表服务只获得读取报表数据所需要的权限，备份服务只获得备份任务所需要的权限。

Google目前的安全最佳实践同样建议针对不同应用使用专用Service Account，以降低过度授权风险。

五、Service Account的权限来自IAM，而不是账号本身

Service Account只是身份，真正决定它能做什么的是IAM授权。

例如，可以把某个角色授予Service Account：

Service Account → roles/storage.objectViewer

这意味着它能够执行该角色允许的Storage读取操作。

如果再授予其他角色，它获得的权限范围就会扩大。

因此，Service Account设计不能只关注“创建账号”，更重要的是分析它究竟需要什么权限。

企业应该避免直接给应用授予过大的管理员角色，尤其不要因为“这样最方便”就把Owner、Editor等高权限角色授予普通业务服务。

最小权限原则仍然是最重要的设计原则。

六、Service Account密钥是最需要谨慎处理的部分

很多开发人员第一次接触Service Account时，会下载一个JSON密钥文件，然后把它放进服务器或者项目目录。

这种方法虽然可以工作，但风险很高。

因为Service Account密钥中的私钥一旦泄露，攻击者可能利用它以该Service Account的身份访问Google Cloud资源。

因此，Google目前明确建议，在存在更安全替代方案的情况下，不要优先使用Service Account密钥。对于运行在Google Cloud之外的工作负载，Google推荐优先考虑Workload Identity Federation。

如果确实必须使用Service Account密钥，就必须严格保护私钥，并建立密钥生命周期管理和撤销机制。

七、Workload Identity Federation解决了什么问题

Workload Identity Federation主要解决的是“外部工作负载如何安全访问Google Cloud”的问题。

例如企业的CI/CD系统运行在GitHub、GitLab、AWS或Azure上，但部署任务需要访问Google Cloud。

传统方式可能是创建一个Service Account密钥，然后把私钥放到CI/CD系统中。

这种方式的问题在于，需要长期保存一个高价值秘密。

使用Workload Identity Federation后，外部身份提供商可以与Google Cloud建立信任关系。工作负载首先使用外部身份进行认证，然后通过Google的Security Token Service进行令牌交换，最终获得短期Google Cloud凭证。

这样可以减少长期Service Account密钥的使用。

Google目前明确将Workload Identity Federation作为外部工作负载访问Google Cloud时的优先方案之一。

八、Kubernetes环境也可以避免保存长期密钥

对于运行在Google Kubernetes Engine中的应用，Workload Identity Federation for GKE可以让工作负载使用Google Cloud IAM身份，而不需要把Service Account JSON密钥直接放进Pod。

这对于微服务架构尤其重要。

例如，一个订单Pod只需要访问Pub/Sub，那么就可以为这个工作负载配置相应身份，并只授予它需要的权限。

即使某个应用被入侵，也可以通过权限隔离将影响范围限制在较小范围内。

九、Service Account不是“自动安全”的

Service Account本身并不会自动解决所有安全问题。

如果管理员给一个Service Account授予过多权限，那么它依然可能成为严重的攻击目标。

例如，一个只需要读取Cloud Storage文件的应用，却被授予项目级管理员权限，那么这个Service Account一旦遭到攻击，攻击者可能获得远超业务需求的控制能力。

因此，安全设计应该同时考虑身份、权限、资源范围和凭证生命周期。

对于Workload Identity Federation，还需要特别限制哪些外部身份能够模拟或使用Service Account。Google的安全建议包括限制能够模拟Service Account的外部身份、为不同应用使用专用Service Account，以及避免直接允许整个身份池中的所有成员使用同一个Service Account。

十、审计同样非常重要

Service Account执行的操作需要能够被追踪。

企业应该利用Cloud Audit Logs等机制记录关键资源访问、权限变更以及身份相关操作，并定期检查Service Account实际拥有的权限。

尤其需要关注长期没有使用却拥有高权限的Service Account，以及权限明显超过实际业务需求的身份。

如果一个备份服务只需要访问几个存储桶，却拥有整个项目的大量管理权限，这就是典型的权限过度配置。

十一、Service Account应该怎样设计

一个比较合理的设计原则可以概括为：

一个应用尽量使用独立身份。

一个身份只获得完成任务所需要的权限。

权限尽可能限制在具体资源范围。

优先使用短期凭证。

尽量避免长期Service Account密钥。

外部工作负载优先考虑Workload Identity Federation。

定期审查Service Account权限和实际使用情况。

对能够模拟Service Account的主体进行严格限制。

这套思路的核心不是“Service Account越多越安全”，而是让每个工作负载的身份边界尽可能清晰。

Service Account真正解决的问题，是让Google Cloud知道“到底是哪一个工作负载正在访问资源”，而IAM解决的是“这个工作负载究竟允许做什么”。

因此，可以把整个关系理解成：

身份解决“你是谁”。

IAM角色解决“你能做什么”。

资源策略决定“你能对什么资源做”。

凭证解决“你如何证明自己拥有这个身份”。

理解这四层关系之后，Google Cloud的Service Account就不再只是一个看起来复杂的账号概念，而是一套围绕工作负载身份、权限控制和短期凭证建立起来的安全机制。