密钥轮替是指定期更新或替换密码、API 密钥或加密密钥等敏感信息（密钥）的过程。轮替 Secret 有助于最大限度地降低未经授权访问或滥用 Secret 的风险，尤其是在 Secret 遭到破解或泄露的情况下。
定期轮替有助于：
-
限制密文泄露时的影响。
-
确保不再需要访问密文的个人无法使用旧密文值。
-
如果您需要紧急轮替密钥，可最大限度地降低服务中断的风险。
Secret Manager 具有密文、密文版本和轮替时间表概念，为构建支持轮替密文的工作负载奠定了基础。
本页面提供了有关轮替存储在 Secret Manager 中的密文的建议。您将了解如何执行以下操作：
在开始之前，我们建议您先阅读 Platform 概览，以便从整体上了解 Google Cloud。此外，我们还建议您阅读 Secret Manager 产品概览。
将 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 服务以接收轮替通知并执行轮替步骤：
-
在外部系统（例如数据库、API 提供商）中获取或创建新的 Secret。
确保这不会使现有密文失效，从而不会影响现有工作负载。
-
使用新密文更新 Secret Manager。
在 Secret Manager 中创建新的 Secret 版本。这还会更新
latest别名，使其指向新创建的 Secret。
重试和并发
由于轮替流程可能会随时终止，因此 Cloud Run 服务必须能够从其中断的位置重启该流程（必须是可重入）。
我们建议您配置重试，以便能够重新执行失败或中断的轮替。此外，请在 Cloud Run 服务上配置并发请求数上限和实例数上限，以尽可能降低并发执行轮替相互干扰的可能性。
为了构建可重入的旋转函数，您可能需要保存状态以允许旋转进程恢复。Secret Manager 有两项功能可帮助您实现这一点：
-
对密文使用标签，以在轮替期间保存状态。为密文添加标签，以跟踪轮替工作流期间上次成功添加的版本数量（例如
ROTATING_TO_NEW_VERSION_NUMBER=3）。轮替完成后，请移除轮替跟踪标签。 -
使用 ETag 来验证其他流程在轮替工作流期间不会并发修改密文。详细了解密文和密文版本的 ETag。
Identity and Access Management 权限
轮替流程需要 secretmanager.versions.add 权限才能添加新的 Secret 版本，并且可能需要 secretmanager.versions.access 权限才能读取之前的 Secret 版本。
轮替流程需要 secretmanager.versions.add 权限才能添加新的 Secret 版本，并且可能需要 secretmanager.versions.access 权限才能读取之前的 Secret 版本。
默认的 Cloud Run 服务账号具有 Editor 角色，该角色包含添加 Secret 版本的权限，但无法访问 Secret 版本。为了遵循最小权限原则，我们建议不使用默认服务账号。请改为为您的 Cloud Run 服务设置单独的服务账号，并根据需要授予 Secret Manager 角色（可能包括一个或多个）：
-
roles/secretmanager.secretVersionAdder -
roles/secretmanager.secretVersionManager -
roles/secretmanager.secretAdmin -
roles/secretmanager.secretAccessor
将新的 Secret 版本发布到工作负载
现在，已在外部系统中注册了新的有效 Secret 版本并将其存储在 Secret Manager 中，接下来将其发布到您的应用。此发布因密文绑定方法而异，通常不需要人工干预。
清理旧 Secret 版本
所有应用都轮替到新密钥版本后，您就可以安全地清理旧密钥版本了。清理过程取决于密钥的类型，但通常：
-
确保新密钥版本已全面面向所有应用发布。
-
在 Secret Manager 中停用旧密文版本，并验证应用不会中断（如果停用会中断使用方，请等待合理的一段时间以允许人工干预）。
-
从外部系统中移除或取消注册旧 Secret 版本。
-
在 Secret Manager 中销毁旧的 Secret 版本