利用工作负载身份联合清除GCP中长期有效的凭据

我不断遇到的一个问题 每当我部署新的持续集成和持续部署（CI/CD）工具，或者向第三方授予 GCP 项目的访问权限时，最终都需要做同样的事情：导航到身份与访问管理（IAM）页面，创建一个服务账户，下载一个 JSON 密钥，然后将其粘贴到某个地方。虽然这样能行得通，但我总觉得哪里不对劲。 你可以为服务账户密钥设置过期日期；为了提高安全性，你应该这样做。但这又会引发新的问题。每次密钥过期时，你都必须为同一个服务账户生成一个新的密钥，然后追踪所有使用旧密钥的系统和团队，并将新密钥分享给他们。实际上，这种运维开销相当大，以至于许多团队干脆完全跳过过期设置，让密钥永久有效，而这显然是一个更糟糕的解决方案。无论是否设置过期时间，密钥都存储在密钥库和环境变量中。有时候，如果有人操作失误，甚至会出现在版本控制系统中。虽然可以审计何时使用了哪个密钥，但这取决于是否预先启用了审计日志。如果密钥泄露，通常只有在仔细查阅这些日志后，才能了解其影响范围。 当我第一次接触 Workload Identity Federation "（WIF）时，我是持怀疑态度的。又一个 IAM 抽象层？但在将其部署到多个生产工作负载中，并将 Harness 管道、GitHub Actions 工作流以及亚马逊云科技的 Lambda 函数与 GCP 连接起来之后，我确信这是机器间身份验证的正确模型。 本文并非又一篇关于“什么是 WIF”的概述。相反，本文将探讨在大规模推行该方案时的实际情况究竟如何，包括我的组织如何在六个月内将基于 WIF 的项目的数量从零提升至 120 个以上；在多组织 Harness 部署中需要警惕的范围界定失误；我们为何选择“模拟身份”而非谷歌推荐的默认“直接访问”方式；以及当 AWS 安全令牌服务（STS）在后台向 GCP 验证身份时，其内部机制究竟是如何运作的。 Workload Identity Federation 究竟是什么 我最初怀疑是因为 WIF 的设计形式：必须存在三个独立的对象，系统才能正常运行。单个对象本身并不能发挥任何实际的作用。与下载一个 JSON 密钥相比，似乎这种设计为了达到相同的效果增加了许多繁琐的步骤。 我之所以改变看法，是因为我意识到这些繁文缛节本身就是其关键所在。服务账户密钥是一个你现在拥有而且必须永久保护的密钥。WIF 取代了这种设计，转而采用一种信任关系——你只需要声明一次，此后便无需再进行任何操作。 其机制非常简单。与其将凭据交给外部系统，不如提前告知 GCP 你信任哪些外部身份提供商以及在什么条件下信任它们。当外部工作负载需要访问权限时，它会向 GCP 的安全令牌服务（STS）提交其原生令牌。GCP 会根据你的配置验证该令牌，若验证通过，则签发一个短效的 GCP 访问令牌。任务执行完毕后，令牌即失效，没有任何数据被存储，也无需进行轮换。该配置包含三个组成部分。 工作负载身份池 这是 GCP 项目中的一个命名容器，用于将外部身份配置进行分组。你可以将其视为一个存放信任配置的文件夹。它本身并不执行任何操作。 提供商 该连接器位于身份池内，并定义了实际的信任关系。你需要针对每个外部身份系统配置一个提供商。提供商会告知 GCP 令牌的来源、验证方式、如何将令牌的声明映射到 GCP 可识别的属性，以及允许哪些特定的身份通过。 服务账户绑定 这是最后一步。当外部身份通过验证后，它就需要实际的 GCP 权限。你将特定身份池中的身份绑定到服务账户，对应的工作负载便会临时继承该服务账户的 IAM 权限。 Workload Identity Federation 并非 GCP 独有的概念。例如，Microsoft Entra Workload ID 在 Azure 中实现了相同的理念，利用基于 OpenID Connect (OIDC) 的联合凭据，消除了外部工作负载中存储的密钥。其底层的信任关系模型是一样的，即输入外部令牌、输出短效平台令牌。本文所述的机制（包括身份池、提供商、属性条件及其通用表达式语言（CEL）语法）均特定于 GCP 的实现。 你可以将 Workload Identity Federation 用于以下场景：使用 X.509 客户端证书 "进行身份验证的工作负载；运行在 AWS 或 Azure " 上的工作负载；本地 Active Directory "； GitHub 和 GitLab " 等部署服务；以及任何 支持 OpenID Connect 或安全断言标记语言 (SAML) V2.0 的身份提供商 (IdP) "。 我们是如何采用 WIF 的 我们并没有进行迁移。这一点有必要直截了当地说明一下，因为“淘汰环境中的所有密钥”是一个与本文截然不同且难度大得多的课题。 我们的环境中存在着数百个未设置过期时间的服务账户密钥，其中一些已有数年之久。要对这些密钥进行追溯处理，需要协调所有持有密钥副本的团队和系统，每个步骤都存在服务中断的风险，而且无法明确证明某个密钥是否确实已经失效，还是仅仅在那一周未被使用。 因此，我们转而在密钥创建环节划定了界限。作为更广泛的云现代化计划的一部分，WIF 成为每个新建 GCP 项目的强制要求。任何新项目都不会获得服务账户密钥。部署通过使用联合身份认证的 Harness 管道进行。这一要求在项目配置阶段就已经强制执行，而非交由各团队自行选择是否采用。在六个月内，已有超过 120 个项目采用这种方式进行身份验证。 旧密钥并没有消失，但它们不会再持续扩散。这就把一个原本“不断扩张”的问题，转化成了一个“规模固定且持续收缩”的问题，让整个风险治理工作变得可控。 在早期，强制推行这一变更还带来了一项我未曾预料到的好处。由于每个项目都继承了相同的模式，范围界定规范在项目伊始就已经确定了，而非在各团队之间各行其是。在接入前几个服务提供商之后，每一项新集成都只是在复制我们已经信任的配置，而非重新做出设计决策。 OIDC 连接器：教 GCP 读取外部 Token 大多数现代 CI/CD 平台都支持 OIDC。当工作流或管道运行时，平台会为这次运行自动生成一个短效的 JSON Web Token（JWT）。该令牌由平台自身的 OIDC 签发者进行加密签名；其中包含描述身份的声明，例如这次运行源自哪个存储库、哪个组织或哪个管道账户。 OIDC 连接器是让 GCP 理解这些令牌的关键。当你在池中配置 OIDC 类型的提供商时，需要定义以下三项内容。 签发者 URL 这是外部平台的 OIDC 端点。GCP 会从该 URL 获取该平台的公钥，并利用这些公钥验证传入的令牌是否真实且未被篡改。 属性映射 这是一个转换层。GCP 本身无法识别 Harness 声明名称或 GitHub 声明名称。这些映射告诉 GCP：“当你在令牌中看到 assertion.account_id 时，将其识别为 attribute.account_id”。预留映射关系 google.subject = assertion.sub 是必需的，并将作为主体身份标识。 属性条件 这是一个充当安全门的 CEL 表达式，用于过滤实际有哪些身份可以通过。如果没有这个表达式，来自签发者的任何有效令牌都将