Google Cloud Workload Identity 怎么使用，如何减少应用保存长期凭证的需要

Google Cloud Workload Identity 怎么使用，如何减少应用保存长期凭证的需要

在传统的云应用部署方式中，程序如果需要访问Google Cloud中的存储、数据库或其他API，常见做法是创建一个服务账号，再把JSON格式的服务账号密钥放进服务器、容器或者CI/CD系统。

这种方式虽然简单，但存在一个明显问题：密钥本身就是一项长期有效的凭证。一旦密钥文件被泄露，攻击者就可能利用它访问该服务账号能够访问的云资源。

Google Cloud现在更强调使用工作负载身份和短期凭证，尽量避免长期保存服务账号密钥。需要注意的是，“Workload Identity”并不是单独一种适用于所有环境的认证方式。根据应用运行的位置，Google Cloud提供了附加服务账号、Workload Identity Federation for GKE、Workload Identity Federation以及Managed Workload Identities等不同机制。

为什么应该减少服务账号密钥

假设一台服务器上运行着一个需要访问Cloud Storage的应用。传统做法可能是在服务器上保存一个JSON密钥文件，应用启动以后读取这个文件，再使用服务账号身份调用Google Cloud API。

问题在于，这个文件一旦进入错误的人手中，就可能成为长期访问云资源的钥匙。

如果密钥没有及时撤销，攻击者甚至可能在服务器已经恢复正常以后继续使用它。因此，Google明确建议在有其他可行方案时避免使用服务账号密钥。

Workload Identity的核心思路则不同：应用不需要把一个长期有效的私钥放在代码、服务器或容器里，而是利用自身运行环境已经具备的身份，通过身份验证和令牌交换获得短期凭证。

短期凭证即使被攻击者获得，其有效时间也受到限制，因此相比长期服务账号密钥能够降低凭证长期暴露所带来的风险。Google的服务账号模拟机制同样采用短期凭证，官方文档指出，这类凭证的生命周期通常只有数小时或更短。

不同运行环境使用的方法并不完全一样

这是理解Google Cloud Workload Identity最容易出错的地方。

如果应用运行在Compute Engine虚拟机上，通常不需要另外建立Workload Identity Federation。可以直接给VM绑定一个用户管理的服务账号。运行在VM上的应用通过Google Cloud客户端库访问API时，可以使用这个附加服务账号作为自己的身份。

如果应用运行在Google Kubernetes Engine，也就是GKE中，则可以使用Workload Identity Federation for GKE，让不同的Kubernetes ServiceAccount拥有不同的Google Cloud身份和权限。

如果应用运行在AWS、Azure、本地数据中心，或者GitHub、GitLab等外部环境，则可以使用Workload Identity Federation，把外部身份提供商与Google Cloud建立信任关系。这样，外部工作负载就可以在不保存Google服务账号密钥的情况下访问Google Cloud资源。

因此，实际部署之前首先应该回答一个问题：

应用到底运行在哪里？

不同运行环境对应的身份方案并不相同，不能简单地把所有方案都称为“Workload Identity”。

Compute Engine其实可以非常简单

对于运行在Compute Engine上的应用，一个常见方案就是直接给VM绑定专用服务账号。

例如，一台服务器运行图片处理程序，需要读取Cloud Storage中的文件。

可以创建一个专用服务账号，只授予它访问特定存储资源所需要的权限，然后把这个服务账号绑定到VM。

应用本身不需要保存JSON密钥。

程序通过Google Cloud客户端库进行认证时，可以自动使用VM附加的服务账号身份。

这种设计比“把JSON密钥上传到服务器”更加简单，也减少了密钥文件泄露的风险。

更重要的是，不应该让所有服务器共享一个权限过大的服务账号。Google建议针对不同应用建立独立的服务账号，以避免一个应用的权限影响其他应用。

GKE中的Workload Identity Federation

Kubernetes环境更加复杂，因为一个集群里可能同时运行几十甚至几百个应用。

如果所有Pod都使用节点级别的服务账号，那么不同应用可能共享相同的权限。一旦某个Pod被攻破，攻击者获得的权限可能远远超过这个应用实际需要的范围。

Workload Identity Federation for GKE就是为这种场景设计的。

企业可以为不同应用建立不同的Kubernetes ServiceAccount，然后将这些身份与Google Cloud资源访问权限关联起来。

例如：

图片服务只允许读取Cloud Storage；

日志服务只允许写入Cloud Logging；

某个后台服务允许访问特定Pub/Sub主题；

数据库管理服务则使用另外一套权限。

这样，即使某个应用遭到攻击，攻击者能够利用的Google Cloud权限仍然受到限制。

Google目前推荐使用Workload Identity Federation for GKE，而不是让多个工作负载共享节点默认服务账号。官方文档特别指出，共享节点服务账号容易造成权限过度授予，并不适合多租户集群。

外部服务器如何使用Workload Identity Federation

如果应用并不运行在Google Cloud，而是在AWS、Azure、本地服务器或者支持OIDC的CI/CD平台上，那么Workload Identity Federation就非常有价值。

它的基本过程可以理解成三步。

第一步，应用先从自己的身份提供商获得身份凭证。例如GitHub Actions可以提供OIDC身份令牌。

第二步，应用将这个外部凭证提交给Google的Security Token Service进行交换。

第三步，Google验证身份以后，返回联邦凭证。根据配置，应用可以直接访问相应的Google Cloud资源，也可以进一步模拟一个Google Cloud服务账号，取得短期访问令牌。

整个过程中最重要的一点是：

应用不需要保存Google服务账号的长期私钥。

这也是Workload Identity Federation相比传统JSON密钥认证最大的安全价值之一。

服务账号模拟又是什么

有些Google Cloud API或者具体业务场景并不适合直接给外部身份授予资源访问权限，这时候可以采用服务账号模拟。

简单来说，外部工作负载首先证明“我是谁”，然后获得权限去模拟某一个服务账号。

之后，应用使用这个服务账号的短期凭证访问Google Cloud。

因此，这里面实际上存在两个身份：

一个是原始身份；

另一个是被模拟的服务账号。

Google的审计日志能够在相应场景下记录这两个身份，从而帮助企业追踪究竟是谁通过哪个服务账号访问了资源。

这种设计对于大型企业尤其重要，因为管理员不必给一个外部身份直接授予大量资源权限，而可以通过一个权限经过严格控制的服务账号来完成访问。

权限控制比认证方式更加重要

没有长期密钥并不意味着应用自动变得安全。

如果Workload Identity配置错误，攻击者仍然可能利用应用获得过高的IAM权限。

例如，一个只需要读取Cloud Storage文件的程序，却被授予项目级别的管理员权限，那么即使它使用的是短期凭证，也不能称为合理的安全架构。

因此，Workload Identity应该和最小权限原则结合使用。

Google建议为不同应用使用专用服务账号，并避免把Workload Identity Pool中的所有身份都授予服务账号模拟权限。更合理的方式是只允许明确指定的身份或者符合条件的身份进行访问。

换句话说，真正的安全模型应该是：

身份明确、权限最小、凭证短期、访问可审计。

一个典型的实际场景

假设一家企业在GitHub Actions中自动部署应用。

传统方法可能是把Google Cloud服务账号JSON密钥放进GitHub Secrets。CI/CD任务运行时读取这个密钥，然后调用Google Cloud API。

这种方案最大的问题是，Google服务账号密钥成为一个长期存在的秘密。

如果改用Workload Identity Federation，GitHub Actions可以通过OIDC获得自己的身份，再向Google Cloud进行身份交换。

Google验证该身份以后，允许它直接访问指定资源，或者模拟一个专门用于部署的服务账号。

这样，企业就不需要在GitHub中保存一个长期有效的Google服务账号私钥。

Google官方目前也提供针对GitHub、GitLab、AWS、Azure以及其他外部身份提供商的Workload Identity Federation配置方式。

使用过程中仍然存在几个问题

Workload Identity并不是安装一个组件就结束了。

首先是IAM配置复杂度。

身份池、身份提供商、属性映射、IAM角色以及服务账号模拟权限之间存在关联。任何一个环节配置错误，都可能出现应用无法访问资源的问题。

其次是API兼容性。

Google目前推荐外部工作负载优先采用Workload Identity Federation进行直接资源访问，但官方也明确指出，部分Google Cloud API存在联邦身份方面的限制。在这些情况下，可以改用服务账号模拟。

第三是审计。

企业不能只关心“能不能访问”，还应该记录“谁访问了什么”。

Workload Identity Federation产生的短期凭证可以与Google Cloud的审计日志结合使用，从而帮助管理员追踪身份交换和服务账号模拟行为。

普通企业应该怎样选择

如果应用运行在Compute Engine上，通常优先考虑直接绑定用户管理的服务账号，而不是把JSON密钥放进服务器。

如果应用运行在GKE中，可以优先考虑Workload Identity Federation for GKE，并为不同应用使用独立的Kubernetes ServiceAccount。

如果应用运行在AWS、Azure、本地服务器或者支持OIDC的CI/CD环境中，则可以考虑Workload Identity Federation。

如果确实需要使用服务账号，也应该尽量采用短期凭证或者服务账号模拟，而不是长期保存服务账号密钥。

Google目前的身份认证指南也按照运行环境和身份提供商来区分这些方案，而不是要求所有应用使用同一种认证方式。

从“保存密码”转向“证明身份”

Workload Identity真正重要的变化，并不是增加了一个新的Google Cloud功能，而是改变了应用访问云资源的思路。

过去的模式是：

把钥匙交给应用，让应用拿着钥匙进入云平台。

现在更合理的模式是：

让运行环境证明自己的身份，然后由Google Cloud根据身份和IAM规则临时授予访问权限。

这样做能够减少长期凭证的数量，降低密钥泄露风险，同时让权限控制更加细粒度。

但Workload Identity并不会自动解决所有安全问题。身份验证、IAM权限、服务账号设计、审计以及供应链安全仍然需要同时考虑。

对于现代云原生应用，真正值得避免的不是“所有凭证”，而是那些长期存在、权限过大、难以追踪和难以撤销的凭证。能够让应用在不保存长期密钥的情况下获得恰到好处的临时权限，才是Workload Identity这类技术真正解决的问题。