1.6.8.1. BridgeCrew Yor

Yor 是由 Bridgecrew（已被 Palo Alto Networks 收购） 开发并开源的一款基础设施即代码（IaC）自动标签工具。它能够在 Terraform、AWS CloudFormation 以及 Serverless Framework 等模板中自动为云资源添加一致且有意义的标签。这些标签包含了资源归属和变更追踪的信息，例如代码所属的团队或人员、资源唯一标识等。Yor 的基本原理是在代码层面为每个基础设施资源块注入标签元数据，然后这些标签会在资源部署到云端时传递到实际的云资源上，实现从“代码到云”的信息携带和追踪。通过这种“代码即标签”的方式，Yor 为基础设施提供了统一的标识策略。

Yor 可以作为 GitHub Action、预提交（pre-commit）钩子或者独立的命令行工具使用，方便地集成到开发者现有的 CI/CD 工作流程中。当开发者将代码提交到版本库时，Yor 能自动为修改的 IaC 模板片段添加标签；这些标签无需开发者手工干预，就会从模板文件传递到部署后的云资源上。结果就是开发者无需执行繁琐的手动标记工作，却能让安全和运营团队获得一致、准确的资源标记用于审计和管理。

1.6.8.1.1. 治理痛点：为何需要 Yor？

在大型 Terraform 模块和多云环境中，实现一致的资源标签命名和归属标记是一个常见的治理难题。以往各云供应商和团队往往有不同的标签标准，给成本分摊、访问控制、运维支持以及安全审计带来挑战。传统做法下，给每个基础设施资源手动添加标签既繁琐又容易出错，而且很难保证跨团队、跨项目的一致性。当发生安全误配置或云资源异常时，缺少统一标签会导致定位责任人和问题源头十分困难。

Yor 正是为了解决这些治理和可追踪性痛点而生的。Palo Alto Networks 的首席架构师 Barak Schoster 指出，有效的基础设施标签对于跟踪成本、访问权限、运维以及云上安全至关重要，但之前完全是人工过程且标准不一。通过自动化和标准化标签，Yor 提供了从 IaC 配置到生产环境云资源的可见性和可追溯性。具体而言：

• 全面归属追踪：Yor 默认为每个资源块添加一系列标签信息，包括 Git 代码仓库组织、仓库名称、IaC 定义文件名、最后一次修改提交的哈希和时间、修改者列表，以及一个唯一的追踪标识符 yor_trace。这些信息使云上资源可以直接对应到产生它的代码和开发者。例如，如果运行时环境出现配置错误，通过资源上的 yor_trace 唯一ID就能追溯到代码库中的具体资源定义。同样，通过资源上的 git_last_modified_by 等标签可以确定最后修改代码的人员和时间。这使安全团队能够迅速找到负责的开发者并协同修复问题。
• 一致的成本与权限标记：Yor 自动沿用并补充既有的环境、业务等标签，确保所有资源都打上统一格式的标签，方便财务进行成本分摊分析以及运维团队依据标签来设置资源分组和访问控制。统一的标签体系好比提供了一种跨团队的公共语言，让不同部门（开发、运维、安全）都能根据标签快速识别资源归属、用途，从而改进协作效率。
• 减少人为失误：有了 Yor，开发者不再需要记忆和手动添加各种标签标准，减少了遗漏和拼写错误的可能性。Yor 在代码提交时自动插入规范标签，大大降低了因人为因素导致标签不完整或不准确的情况。这不仅改善了治理，还减轻了工程师的负担，使他们可以专注于核心业务逻辑而非琐碎的标记工作。

简而言之，Yor 将过去繁琐易错的云资源标记流程自动化，将基础设施的每个模块都纳入可追踪的治理范围，实现了规模化环境下资源的统一标识和责任追溯。

1.6.8.1.2. 第 14028 号美国总统行政令与 SBOM：Yor 支持供应链透明度

第 14028 号美国总统行政令（2021年5月发布）聚焦于提升国家网络安全，其中一项核心要求是：联邦机构在采购软件时必须获取该软件的软件物料清单（SBOM，Software Bill of Materials），以提高软件供应链的透明度和可控性。SBOM 通常指一份机器可读的清单，详细列出一个软件产品所包含的所有组件、库和模块及其来源。通过 SBOM，使用方可以追踪软件成分、识别其中的漏洞，从而加强供应链的风险管理。行政令 14028 的发布使得SBOM成为美国联邦政府软件采购的强制要求。这一举措反映出在经历 SolarWinds 供应链攻击和 Log4j 漏洞事件后，政府对软件组件透明度的高度重视。

尽管 Yor 针对的是基础设施即代码而非传统应用软件，它所实现的代码到云资源追踪与 SBOM 旨在实现的供应链可见性有着异曲同工之妙。SBOM 关注的是软件组件清单，而在云基础设施领域，我们同样需要了解“是谁、通过哪段代码、在什么时候”创建了哪些云组件。Yor 自动注入的标签正提供了这样的“基础设施清单”信息：

• yor_trace 等标签为每个基础设施资源提供了一个可溯源的身份标识，可视作基础设施层面的部件清单条目。
• git_org/git_repo/git_commit 等标签则揭示了每个资源背后的代码来源和版本，就像 SBOM 列出软件依赖组件的版本一样。
• 通过这些元数据，一个组织可以编制出其 IaC 部署的“资源物料清单”，清楚知道其云环境由哪些代码模块构成、最近的变更来自何处，从而在出现漏洞或合规要求时快速定位受影响的基础设施部分。

举例来说，行政令 14028 要求的软件供应链安全措施之一是及时响应已知组件漏洞。若发现某版本的 Terraform 模块存在安全隐患，利用 Yor 标签，运维和安全团队可以在云上搜索所有带有对应 git_commit 或 yor_trace 的资源，迅速找出受影响的资源清单并采取补救措施。这类似于 SBOM 帮助定位受某漏洞影响的软件组件的原理。可以说，Yor 为基础设施即代码引入了供应链追溯能力：在云基础设施层面实现“从运行资源回溯到源代码”的链路，为满足行政令 14028 关于软件成分透明度的要求提供了支持。

当然，Yor 本身并不是 SBOM 生成工具，二者侧重点有所不同。SBOM 更关注软件包和库层面的依赖透明，而 Yor 关注的是基础设施层面的部署透明。但在 DevSecOps 的大背景下，这两者相辅相成：Yor 确保了每个基础设施变更都有迹可循，这种强大的可追踪性正是安全供应链所需要的要素之一。这也使得在实施行政令 14028 的过程中，组织可以更自信地回答“我们的云基础设施组件来自哪里，由谁维护”这些问题。总的来说，Yor 提高了基础设施代码的可审计性和清单化程度，有助于组织满足包括 SBOM 在内的合规需求和强化自身的供应链安全。

1.6.8.1.3. 使用 Yor：方法、配置与命令

基本用法： Yor 提供了命令行界面用于扫描目录并给其中的 IaC 模板批量打标签。安装完成后，只需运行类似命令即可应用标签：

yor tag --directory ./terraform/

上述命令会对./terraform/目录下的所有 Terraform 配置文件添加预设的标签。Yor 默认启用所有内置标签（包括 yor_trace 追踪ID、所有 Git 历史相关标签等）以及用户定义的自定义标签。如果需要只应用某一类标签或跳过某些标签，可以使用命令行选项进行控制。例如：

• 跳过特定标签：yor tag --directory terraform/ --skip-tags git_last_modified_by,yor_trace 会跳过添加 yor_trace 和 git_last_modified_by 两类标签。支持使用通配符跳过一组标签，如 --skip-tags git* 可以跳过全部 Git 信息相关的标签。
• 仅应用特定标签组：yor tag --tag-group git --directory ./terraform/ 将只添加 Git 信息相关的标签组，而不添加其它类型的标签。类似地，有内置的 “tracing” 标签组等可供选择。

集成方式： 在实践中，Yor 往往被集成到CI/CD流程或开发者工具链中，从而实现标签的持续自动化注入。常见的集成方式包括：

• 预提交钩子（Pre-commit）： 将 Yor 配置为代码库的 pre-commit 钩子，确保每次开发者提交代码前自动为修改的 IaC 文件加上标签。配置方法是在项目的 .pre-commit-config.yaml 中添加 Yor 钩子，使其对 Terraform 文件执行 yor tag 命令。这样在提交（commit）时就已经完成标签注入，提交记录中会体现标签的增加。
• CI 平台集成： Yor 提供了 GitHub Action 和 GitLab CI 模板，可以在 Pull Request 或流水线中运行。比如，在 GitHub Actions 中使用官方的 bridgecrewio/yor-action，能在每次PR创建或合并前自动执行 Yor 打标签。GitLab CI 中也可以在流水线中加入 Yor 步骤，使每次合并代码时自动提交带有标签更新的更改。这保证了主分支代码始终保持标签最新、一致。
• Docker 和本地 CLI： 如果不想直接在本机安装 Yor，也可以使用官方 Docker 镜像运行。通过 docker run -v <本地IaC目录>:/data bridgecrew/yor tag --directory /data 即可在容器中执行标签添加。对于一次性大规模给现有配置加标签，也可以本地运行 yor tag 命令并通过 Git 提交结果。Yor 还支持 --dry-run 模式预览将添加哪些标签而不真正修改文件，方便在实际应用前审查变更。

配置与扩展： Yor 带有内置标签（如前述 yor_trace 和 Git 信息）之外，也允许用户定制额外的标签策略，以满足特定组织的治理需求。扩展方式包括：

• 环境变量配置简单标签： 通过设置环境变量 YOR_SIMPLE_TAGS，可以一次性为所有资源注入静态的键值对标签。例如：

export YOR_SIMPLE_TAGS='{"team": "devops", "env": "prod"}'
yor tag --tag-groups simple --directory terraform/dev/

这将为每个资源添加 team=devops 和 env=prod 两个标签。适用于希望统一添加组织级别标签（如部门、环境）而不需要每次在代码中重复的场景。

• Golang 插件扩展： 对于更高级的定制，Yor 允许使用 Go 语言编写自定义 Tagger 插件，实现复杂逻辑的标签生成，然后编译进 Yor 中运行。这适合对Yor二次开发，或者 Bridgecrew 官方尚未支持的标签方案。
• Inline 注解跳过： 除了命令行跳过指定标签或目录外，开发者还可以在模板代码中加入特殊注释来跳过某些资源的标签注入（例如在 Terraform 配置中加入特定注释标识此资源不需要 Yor 打标签）。这对于少数不希望被自动标记的资源提供了灵活性。

通过以上多种配置与扩展机制，Yor 能适配不同团队的要求，实现标签策略的灵活定制。例如，一个组织可以预先规定所有资源都要打上 cost_center 标签并将规则固化在Yor配置中，则开发者不管在任何项目、任何模块部署资源，都会自动得到符合组织要求的标签，而无需人工检查。

1.6.8.1.4. 标签注入示例：Terraform 模块前后对比

为了更直观地理解 Yor 自动打标签的效果，下面给出一个Terraform 代码示例，展示使用 Yor 前后的差异。假设我们有一个 Terraform 模块定义了某云资源，并且事先仅包含基本的环境标签：

# 执行 Yor 标记前的 Terraform 模块片段
module "remote_module" {
  source  = "Azure/avm-res-resources-resourcegroup/azurerm"
  tags = {
    env = var.env
  }
}

上面代码中，tags 只定义了环境标签 env。现在我们运行 yor tag 对其进行自动标记，Yor 将在代码中注入多个新标签键值对：

# 执行 Yor 标记后的 Terraform 模块片段（Yor 自动注入了额外标签）
module "remote_module" {
  source  = "Azure/avm-res-resources-resourcegroup/azurerm"
  tags = {
    env                  = var.env
    yor_trace            = "d835d6de-7aa7-4a1e-bbe5-8f5ee206e1d0"
    git_repo             = "example"
    git_org              = "bridgecrewio"
    git_file             = "applyTag.md"
    git_commit           = "COMMITHASH"
    git_modifiers        = "bana/gandalf"
    git_last_modified_at = "2021-01-08 00:00:00"
    git_last_modified_by = "bana@bridgecrew.io"
  }
}

如上所示，Yor 为模块的 tags 字段添加了一系列 git_* 前缀的标签以及唯一的 yor_trace 标签。这些标签记录了代码来源和变更历史：Git 仓库组织和名称、资源定义所在的文件路径、最近一次提交的哈希值、修改该资源的所有开发者标识、最后修改时间和修改者邮箱等。通过这些标签，可以直接在云平台的资源标签界面上看到是哪个项目的哪个文件在何时被谁修改后创建了此云资源。Yor 通过分析 Git Blame 信息判断上一次 Git 提交改动了哪些代码行，涉及到哪些 Terraform 块，然后将 Git 版本信息以 Tags 的形式写入到代码中。

值得注意的是，Yor 添加的新标签不会覆盖已有的标签（如示例中的 env 保持不变），而是补充额外信息。开发者仍然可以在代码中定义业务相关的标签（如 Name、Environment 等），Yor 只负责注入追踪和归属类标签，做到与现有标签体系兼容。这些附加标签将伴随 Terraform 模块应用到实际的云资源上，使运维人员在云控制台中也能看到相同的信息，从而实现代码与云资源之间的双向追溯。例如，运维人员在云上发现一个未经备案的资源，只要查看其标签中的 yor_trace 或 git_repo 等信息，就能追溯回对应的代码仓库和模块位置，极大缩短排查定位时间。

通过 Yor 的标签注入，上例中的 Terraform 模块不仅对资源做了功能上的定义，还隐含地记录了元数据，相当于把基础设施“是谁在何处何时创建”附着在了资源本身上。这种做法强化了 Terraform 模块治理：在数百上千的模块和资源构成的大规模环境里，每个资源的来龙去脉都有据可查。正如业内评论所说，Yor 自动添加的标签“简化了将活动云资源连接回创建它们的代码的过程”，大幅提升了云资源管理的可见性。

1.6.8.1.5. 优点与缺点

作为一个开源项目，Yor 自推出以来在基础设施和 DevOps 社区中获得了相当的关注和反馈。总体而言，社区对 Yor 的评价是正面的，认为它填补了 IaC 治理中的一个空白，但也提出了一些改进建议和注意事项。

正面评价： 很多 Terraform 用户和云架构师将 Yor 视为自动化标签管理的“利器”。它显著简化了云资源标签的管理流程，通过自动标签系统大幅提高了资源的可管理性和追踪性。社区文章指出，Yor 可以无缝集成到主流 IaC 平台，在不改变现有工作流程的情况下，为开发和运维团队提供强大的标签管理功能。这种特性让跨团队协作更容易——标签成为统一的语言，不同职能的人都能从中快速获取所需信息，减少了沟通成本。另外，Yor 支持用户自定义标签规则，被称赞为具有很高的灵活性，能够满足不同组织的特定需求。许多用户分享的经验是：过去在大规模环境中推动一致的标签策略非常困难，而引入 Yor 之后，不但节省了大量人工时间，还减少了人为错误，实现了“持续的标签合规”。在实际运维场景中，Yor 帮助团队在出现告警时更快地定位责任人和相关代码，大大缩短故障响应时间。社区博客也将 Yor 列为实践 AWS 最佳标签策略的优秀工具之一，认可其在多云、复杂环境下提供一致性和可追踪性的价值。从 GitHub 开源社区指标看，Yor 项目拥有活跃的贡献者和用户基础（定期有 issue 讨论和改进提交），显示出业内对自动化标签治理的浓厚兴趣。

负面评价和不足： 尽管优点突出，一些用户也指出了 Yor 在实际使用中需要注意的地方。首先，有人担心向代码中插入大量标签可能造成代码可读性下降。对于资源块很多的大型 Terraform 代码库，自动注入的标签行会显著增加文件行数，某种程度上“污染”了原有的代码结构。不过也有用户反馈称，Yor 在注入标签时比较克制，并没有过度干扰原本的配置，只要在评审时折叠标签部分影响不大。这方面见仁见智，但可以通过 Yor 的跳过机制来部分缓解：团队可以配置跳过某些模块或某些标签的注入，以避免不需要的信息填充代码。其次，引入新工具的集成成本也是讨论焦点之一。对于已有成熟流程的团队，增加 Yor 需要花时间调整 CI 流程、培训开发者使用 pre-commit 等。有些团队最初对在流水线中加入自动提交标签的做法持谨慎态度，担心可能影响现有审核流程（例如自动生成的标签提交可能与手动提交交叉）。为此，有实践者建议在试点阶段启用 Yor 的 --dry-run 模式或仅对特定项目应用，逐步推广以获得团队认可。

Yor 的另外一个问题是，在开源的可复用 Terraform 模块中通过 Yor 添加的标签，模块的使用者无法选择不使用这些标签。这对某些对资源标签有更复杂的限制的团队来会造成麻烦。

还有部分社区成员提到项目维护的活跃度问题：Yor 发布以来功能逐渐完善，但在某些时期更新频率降低，提问的Issue处理速度不如预期。这引发了对项目长期维护性的疑虑，有人开始探讨类似功能的替代方案（如 env0 的 Terratag 工具）。例如，Terratag 专注于 Terraform 代码的批量标签，但没有 Yor 跨多种框架和提供丰富追踪信息的优势。Yor 的多云多框架支持和 Git 溯源标签功能仍是其独特卖点，不过社区也希望看到 Yor 持续迭代，支持更新的 IaC 类型（如 Kubernetes 原生清单、Pulumi 等）以及提供更丰富的文档和使用案例。

另外，如果要用 Yor 在标签中添加标签，你会需要两次 Git 提交，第一次是用户对代码进行变更，第二次是 Yor 根据上一次的版本信息，修改标签信息，然后再提交。假如我们通过 CI 平台自动运行 Yor，那么会要求其有直接修改代码并 Push 到主干的权限，这在一些对变更流程有严格管控的项目中是被禁止的。

总的来说，Yor 的优点在社区看来非常明显：它降低了大规模环境中实行标签治理的门槛，提高了资源可追踪性，帮助团队实现了更高水平的基础设施可见性和合规。而其缺点主要集中在工具本身带来的一些额外开销上，如代码冗长度增加、引入流程的复杂性，以及对特定场景可能的不完全覆盖。这些不足往往可以通过配置和流程调整来减轻。随着越来越多的组织意识到标签在云治理中的重要性，Yor 所代表的自动化标签方案正获得广泛认可。社区期望在未来的发展中，Yor 能持续演进，吸收反馈，进一步完善功能，使其在大规模 Terraform 模块治理中发挥更不可或缺的作用。