轮替时间表简介

本主题介绍了密文轮替的概念。在开始之前，我们建议您先查看 Platform 概览，以便从整体上了解 Google Cloud。此外，我们还建议您阅读 Secret Manager 产品概览。

简介

定期轮替有助于：

  • 限制密文泄露时的影响。
  • 确保不再需要访问密文的个人无法使用旧密文值。
  • 持续执行轮替流程，以降低紧急轮替时发生中断的可能性。

Secret Manager 具有密文、密文版本和轮替时间表概念，为构建支持轮替密文的工作负载奠定了基础。

本主题提供了有关轮替存储在 Secret Manager 中的 Secret 的建议。以下部分将探讨以下各项的优势和权衡：

绑定到 Secret 版本

Secret Manager 中的 Secret 可以有多个 Secret 版本。密文版本包含不可变的载荷（实际的密文字节字符串），并会进行排序和编号。如需轮替密文，请向现有密文添加新的密文版本。

您可以使用 latest 别名引用密文中最近添加的密文版本。虽然 latest 别名可便于开发，但对于某些生产工作负载而言，它可能存在问题，因为错误值可能会立即发布并造成服务范围的中断。以下场景介绍了绑定到密文版本的其他方法。

逐步推出

以下场景适用逐步发布的指导原则。选择较慢的密钥分发速度可降低破坏风险，但恢复时间也会延长。某些 Secret 可能会在外部系统（例如跟踪有效 Secret 值的 API 或数据库）中失效，这些系统可能在您的控制之下，也可能不在您的控制之下，在这种情况下，恢复需要进行发布。

在手动或自动轮替期间可能会发布错误密文。强大的轮替工作流应该能够自动检测中断（例如 HTTP 错误率）并回滚以使用旧密文版本（通过之前的配置部署）。

新密文版本的发布取决于密文与应用的绑定方式。

方法 1：在现有发布流程中解析

解析密文版本并将其与您的应用的版本绑定。对于大多数部署，这涉及将最新密文版本解析为完整的密文版本资源名称，并将其与应用一起作为标志或在配置文件中发布。我们建议在轮替时解析密文版本名称，将资源名称存储在持久位置（例如，提交到 Git），并在推送期间将版本名称拉取到部署配置中以防止部署被阻止。

在应用启动时，使用特定 Secret 版本名称调用 Secret Manager 以访问 Secret 值。

此方法具有以下优势：

  • 您的应用在重启时使用相同的密文版本，从而可提高可预测性并降低运营复杂性。
  • 现有的发布和回滚变更管理流程可以重复用于密文轮替和密文版本部署。
  • 值可以逐步发布，从而可减少部署错误值的影响。

方法 2：在应用启动时解析

在应用启动时提取最新密文载荷，并在应用的生命周期内继续使用该密文。

此方法的优点是，它不需要修改 CI/CD 流水线来解析密文版本，但如果发布了错误密文，则应用将无法在实例重启或服务扩容时启动，并且可能会级联成服务中断。

方法 3：持续解析

在应用中持续轮询最新密文版本，并立即使用新的密文值。

这种方法可能会导致立即发生服务范围的中断，因为无法逐步采用新的密文值。

轮替密文

如果您的 Secret 可以动态更新（例如，验证 Secret 的外部系统提供 Admin API），我们建议您设置定期运行的轮替作业。以下部分概述了常规步骤，并将 Cloud Run 作为示例计算环境。

为密文配置轮替时间表

为您的密文设置轮替时间表。必须在密文上配置 Pub/Sub 主题，才能在轮替密文时接收通知。如需了解如何在密文上配置主题，请参阅事件通知指南。

启动 Cloud Run 以创建新的 Secret 版本

创建和配置 Cloud Run 服务以接收轮替通知并执行轮替步骤：

  1. 在外部系统（例如数据库、API 提供商）中获取或创建新的 Secret。

    确保这不会使现有密文失效，从而不会影响现有工作负载。

  2. 使用新密文更新 Secret Manager。

    在 Secret Manager 中创建新的 SecretVersion。这还会更新 latest 别名，使其指向新创建的 Secret。

重试和并发

由于轮替流程可能会随时终止，因此 Cloud Run 服务必须能够从其中断的位置重启该流程（必须是可重入）。

我们建议您在 Pub/Sub 中配置重试，以便能够重新执行失败或中断的轮替。此外，请在 Cloud Run 服务上配置最大并发和最大实例数，以尽可能降低并发执行轮替相互干扰的可能性。

为了构建可重入的旋转函数，您可能需要保存状态以允许旋转进程恢复。Secret Manager 有两项功能可帮助您实现这一点：

  • 对密文使用标签，以在轮替期间保存状态。为密文添加标签，以跟踪轮替工作流期间上次成功添加的版本数量（即 ROTATING_TO_NEW_VERSION_NUMBER=3）。轮替完成后，请移除轮替跟踪标签。
  • 使用 ETag 来验证其他流程在轮替工作流期间不会并发修改密文。详细了解密文和密文版本的 ETag。

Identity and Access Management 权限

轮替流程需要 secretmanager.versions.add 权限才能添加新的密文版本，并且可能需要 secretmanager.versions.access 才能读取之前的密文版本。

默认的 Cloud Run 服务账号具有 Editor 角色，该角色包括添加 Secret 版本的权限，但无法访问 Secret 版本。为了遵循最小权限原则，我们建议不使用默认服务账号。请改为为您的 Cloud Run 服务设置单独的服务账号，并根据需要授予 Secret Manager 角色（可以是其中一个或多个）：

  • roles/secretmanager.secretVersionAdder
  • roles/secretmanager.secretVersionManager
  • roles/secretmanager.secretAdmin
  • roles/secretmanager.secretAccessor

将新的 SecretVersion 推广到工作负载

现在，已在外部系统中注册了新的有效 SecretVersion 并将其存储在 Secret Manager 中，接下来将其发布到您的应用。此发布因密文绑定方法而异（请参阅绑定到密文版本部分），通常不需要人工干预。

清理旧 Secret 版本

所有应用都轮替到新密钥版本后，您就可以安全地清理旧密钥版本了。清理过程取决于 Secret 的类型，但通常：

  1. 确保新密钥版本已全面面向所有应用发布。
  2. 在 Secret Manager 中停用旧密文版本，并验证应用不会中断（如果停用会中断使用方，请等待合理的一段时间以允许人工干预）。
  3. 从外部系统中移除或取消注册旧 Secret 版本。
  4. 在 Secret Manager 中销毁旧的 Secret 版本。

后续步骤