CI/CD机器身份安全盲区：OIDC信任策略的隐形风险

引言：被忽视的"隐形管理员"

在云原生架构中，安全团队习惯将大量精力投入到人类用户的身份治理上——多因素认证、定期访问审查、离职流程等。然而，一个更隐蔽也更危险的问题正在被系统性地忽视：你系统中权限最高的身份，可能根本没有登录入口。

这里说的正是服务主体（Service Principals）和CI/CD联合身份（Federation）。服务主体是云平台（如Azure AD、AWS IAM、GCP）中为应用程序、服务或自动化工具创建的非人类身份实体。与人类用户账户不同，服务主体通过证书、密钥或令牌进行身份验证，专门用于程序间的自动化交互。联合身份（Federated Identity）则是一种跨信任域的身份验证机制，允许外部身份提供者（如GitHub、GitLab）颁发的令牌在目标云平台中被直接信任，从而无需在云端存储长期凭据。这种机制的核心协议是OpenID Connect（OIDC），它在OAuth 2.0之上增加了身份验证层，使得CI/CD平台可以向云端证明"我是某个特定仓库中运行的某个特定工作流"，而云端则根据预配置的信任策略决定是否授予访问权限。

这些身份不需要密码，不会触发登录告警，也几乎从不出现在季度访问审查的名单上。但正是这些"无脸"的机器身份，往往握有直达生产环境的最高权限。

服务身份为何逃过了访问审查

人类身份与机器身份之间的治理鸿沟

传统的身份治理体系是围绕"人"设计的。员工加入或离开团队时，有明确的入职和离职流程；权限过大时，季度访问审查（Access Review）会将其暴露出来。这套机制经过多年打磨，已经相当成熟。

然而，服务主体和CI/CD管道使用的联合身份，天然地绕过了这些检查点。它们不是"人"，因此：

• 不会被纳入以人为中心的访问审查流程
• 没有交互式登录，不会触发基于登录行为的异常检测
• 生命周期与人类账户脱节，往往在项目结束后仍长期存在

结果就是：一个为了让流水线能自动部署而创建的身份，可能拥有生产环境的写入甚至管理权限，却在数月甚至数年间无人过问。值得注意的是，根据行业报告，机器身份的数量已经以10:1甚至更高的比例超过人类身份，而大多数组织的身份治理工具和流程仍然以人类用户为核心设计，这种数量与治理能力的不对称正在成为云安全的最大盲区之一。

权限累积：机器身份的"温水煮青蛙"

更棘手的是，机器身份的权限往往只增不减。每当一条新的部署需求出现，工程师倾向于给现有的服务主体"再加一个权限"，而不是做精细化拆分。时间一长，一个原本只负责部署某个微服务的身份，最终积累出跨多个生产系统的超级权限。由于缺乏审查机制，这种权限累积几乎不可见。

这种现象在DevOps文化中尤为普遍。工程团队在追求部署速度和自动化效率时，往往以"先让它跑起来"为优先原则，而权限收窄被视为"以后再做"的优化项。然而，"以后"几乎从不到来——因为没有机制提醒任何人回来清理。与人类用户可能因岗位变动触发权限重新评估不同，机器身份一旦被创建并赋予权限，往往处于"设置后遗忘"（set and forget）状态。

真正的访问控制藏在OIDC信任策略里

那串决定安全边界的配置字符串

本文的核心观点在于：对于CI/CD联合身份，真正决定谁能到达生产环境的，是OIDC信任策略（Trust Policy）中的那串配置字符串，而非传统意义上的凭据管理。

以GitHub Actions通过OIDC联合到AWS为例，其工作流程如下：当GitHub Actions工作流运行时，GitHub作为OIDC身份提供者（IdP）会为该工作流签发一个短期JWT（JSON Web Token），其中包含丰富的声明（claims），如仓库名（repository）、分支名（ref）、触发事件类型（event_name）、工作流名称（workflow）、运行环境（environment）等。工作流将此令牌发送给AWS STS的AssumeRoleWithWebIdentity接口，AWS验证令牌签名后，将令牌中的声明与角色信任策略中定义的条件进行逐一比对。只有所有条件都满足时，才会颁发临时的云端凭据。

这种机制消除了在CI/CD系统中存储长期密钥的需要，显著降低了凭据泄露的风险——但安全边界完全转移到了信任策略的条件配置上。以AWS为例，IAM角色的信任策略是一个JSON文档，其中Principal字段指定OIDC提供者的ARN，Action字段设为sts:AssumeRoleWithWebIdentity，而Condition字段则是安全边界的核心，使用StringEquals或StringLike运算符对JWT中的claims进行匹配。Azure和GCP有类似机制，分别通过Federated Credentials和Workload Identity Federation实现。这串条件字符串就是整个安全边界的最后一道，也是唯一一道防线。

OIDC信任策略配置错误的灾难性后果

问题在于，这类信任策略极易写错，而错误往往难以察觉。常见的配置陷阱包括：

• 通配符过于宽松：使用 repo:org/* 而非精确到具体仓库，导致组织内任何仓库的工作流都能获得高权限
• 未限定分支或环境：没有约束 ref 条件，使得任意分支（包括攻击者提交的PR分支）都能触发部署
• 主体匹配的字符串前缀漏洞：条件匹配时未正确锚定，可能被相似命名的资源利用

关于字符串前缀漏洞，值得深入解释其技术细节。在AWS IAM条件中，如果使用StringLike运算符配合通配符，如repo:my-org/my-repo*，攻击者可以创建名为my-org/my-repo-malicious的仓库来匹配该条件。更微妙的是，GitHub OIDC令牌的sub声明格式为repo:org/repo:ref:refs/heads/main，如果条件只匹配到repo:org/repo而未包含完整的ref限定，那么任何分支——包括来自fork的pull_request_target事件触发的工作流——都可能满足条件。业界已有多起因此类配置错误导致的供应链攻击案例，攻击者通过提交包含恶意代码的PR，在CI环境中获取了生产环境的云端凭据。

一旦这串字符串写松了，攻击者无需破解任何密码，只需在符合条件的上下文中运行一段代码，就能"合法地"获得生产环境的最高权限。而这一切不会触发任何登录告警，因为从云平台的视角看，这是一次完全符合信任策略的正常令牌交换——它甚至不会在传统的安全信息和事件管理（SIEM）系统中被标记为异常。

安全团队的应对策略

将机器身份纳入审查范围

首要行动是打破"访问审查只针对人"的思维定式。安全团队应当：

• 建立机器身份的完整清单（inventory），明确每个服务主体和联合身份的用途、权限范围和所有者
• 将这些身份纳入定期审查，识别并回收长期未使用或权限过大的身份
• 为每个身份指定明确的责任人，避免"孤儿身份"长期无人管理

在实施层面，各主要云平台已经提供了辅助工具：AWS IAM Access Analyzer可以分析角色的实际使用情况并生成最小权限策略建议；Azure AD的工作负载身份（Workload Identities）功能支持对服务主体进行条件访问策略和访问审查；GCP的Policy Analyzer则可以审计Workload Identity Federation的配置。然而，工具只是基础，真正的挑战在于将机器身份治理嵌入组织的运营流程和文化中。

把OIDC信任策略当作代码来治理

既然OIDC信任策略是真正的访问控制点，就应当以对待关键代码的严谨态度来管理它：

• 精确化条件：避免通配符，将信任条件收窄到具体的仓库、分支和环境
• 策略即代码（Policy as Code）：将信任策略纳入版本控制和自动化审查，对任何变更进行同行评审
• 持续验证：使用工具定期扫描信任策略，检测过于宽松的配置和潜在的匹配漏洞

策略即代码是将安全策略、合规规则和访问控制配置以可版本化、可测试、可审计的代码形式管理的实践。在OIDC信任策略治理中，常用的工具链包括：HashiCorp Sentinel或Open Policy Agent（OPA）用于定义和执行策略规则，可以编写如"任何信任策略不得包含通配符仓库匹配"这样的自动化检查；Terraform或Pulumi等基础设施即代码工具用于声明式管理信任策略的配置，确保所有变更都通过代码仓库而非控制台手动操作；GitHub/GitLab的代码审查（Code Review）机制确保任何策略变更都经过至少一名安全团队成员的审批；而Bridgecrew/Checkov等工具则可以在CI管道中自动扫描信任策略，在配置变更进入生产之前拦截潜在风险。

最小权限原则在机器身份上的落地

最小权限（Least Privilege）原则同样适用于机器身份，而且执行起来可能比人类身份更有条件做到精细化。为不同的部署任务创建职责单一的身份，而非一个万能的超级角色，可以大幅缩小任何单一配置错误带来的爆炸半径。

具体而言，可以采用"一管道一身份"的策略：为构建、测试、预发布部署和生产部署分别创建独立的服务主体，每个身份只拥有完成其特定任务所需的最小权限集。例如，构建阶段的身份只需要读取源代码仓库和推送容器镜像的权限，而无需任何生产环境的访问权；生产部署身份则只需要更新特定Kubernetes命名空间或特定云资源的权限，而不是整个AWS账户的管理员权限。配合短期令牌（AWS STS临时凭据默认1小时过期）和GitHub Actions环境保护规则（要求人工审批后才能触发生产部署），可以构建出纵深防御的安全姿态。

结语

随着自动化和CI/CD的普及，机器身份的数量正在以远超人类账户的速度增长。它们没有脸，不会登录，却常常握有系统中最致命的权限。忽视这一层面，等于在精心构筑的安全城墙上留下一扇无人看守的后门。

下一次进行安全评估时，不妨先问自己一个问题：我系统中权限最高的那个身份，是否恰恰是那个从来不会登录的？ 而它背后那串OIDC信任策略字符串，你真的审查过吗？