Secret Manager 最佳实践

本指南介绍了使用 Secret Manager 时的一些最佳做法。该指南并未列出所有建议,在您阅读本指南之前,我们建议您先查看 Platform 概览,以便从整体上了解 Google Cloud 和 Secret Manager 概览

访问权限控制

对 Secret Manager API 的访问受 IAM 保护。向 Secret 授予权限时,请遵循最小权限原则。

必须提供凭据才能向 Secret Manager API 进行身份验证。通过 客户端库都使用类似的策略来查找引用 为“应用默认凭据”。

  • 在本地开发时,请使用 gcloud auth application-default login。这会创建一个文件 由客户端库自动选择。
  • 在 Compute Engine 和其他 Google Cloud 计算平台(例如 Cloud Run 函数,那么客户端库会通过 实例元数据服务器
  • 在 GKE 上,Workload Identity 还通过元数据服务提供凭据。
  • 在 Amazon Web Services 或 Microsoft Azure 等其他平台上,请考虑使用 设置工作负载身份联合,该机制使用 现有身份机制来向 Google Cloud API 进行身份验证。

所有这些方法都优先于导出服务账号凭据,因为它们不需要在 Secret Manager API 之外安全地存储和访问其他密文。

编码实践

通过文件系统或环境将密钥传递给您的应用 变量很常见,但应尽可能避免,原因如下:

  • 在可以通过文件系统访问密文时,目录遍历攻击等应用漏洞的严重级别可能更高,因为攻击者可能会获得读取密文材料的权限。
  • 在通过环境变量使用密文时,配置错误(例如启用调试端点或包含记录进程环境详细信息的依赖项)可能会泄露密文。
  • 在将密文材料同步到其他数据存储区(如 Kubernetes Secret)时,请考虑该数据存储区的访问权限控制,例如:
    • 数据存储区是否会扩展密文的访问权限?
    • 是否可以审核对 Secret 的访问?
    • 数据存储区是否符合静态数据加密和区域化要求?

我们建议直接使用 Secret Manager API(使用某个提供的客户端库,或者按照 RESTGRPC 文档操作)。

但对于某些产品集成(例如无服务器集成), 通过文件系统或环境变量传递密钥。对于 相关信息,请参阅将 Secret Manager 与其他产品搭配使用

管理

创建密文时选择自动复制政策,除非您的工作负载有特定位置要求(可使用 constraints/gcp.resourceLocations 限制条件强制执行)。

通过 Secret 版本号引用 Secret,而不是使用最新别名。使用现有发布流程部署版本号更新。通常,这意味着使用在启动时读取的特定 Secret 版本配置应用。虽然使用最新的别名很方便,但如果 Secret 的新版本出现问题,您的工作负载可能无法使用该 Secret 版本。通过固定到版本号,您可以使用现有的发布流程验证和回滚配置。

在以下日期之前停用密钥版本: 销毁或删除 Secret。通过将密文置于看起来与销毁相同但可逆转的状态,可帮助防止发生中断。也就是说, 您可以停用并等待一周,以确保 依赖项,然后才能永久删除数据。

除非您确定应以不可逆转的方式删除生产密文,否则请勿对生产密文设置过期时间。过期功能最适合自动清理临时环境。请考虑使用基于时间的 IAM 条件来替代过期的密文。

定期轮替您的密钥,以执行以下操作:

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

使用 Cloud Asset Inventory 监控您的组织中的密文,以便执行以下操作:

  • 帮助识别您的组织中的密文。
  • 识别是否不符合组织要求,例如轮替、加密配置和位置。

启用数据访问日志以获取和分析AccessSecretVersion 请求信息。在文件夹或组织级别启用此功能可强制执行日志记录,而无需在每个 Secret 或项目中进行配置。

除了 IAM 控制之外,您还可以通过为您的组织设置 VPC Service Controls 边界来限制对具有基于网络的控制的 Secret Manager API 的访问权限。

您可以使用 constraints/iam.allowedPolicyMemberDomains 组织政策来限制可添加到密文的 IAM 政策中的身份。

估算您的密钥使用高峰(考虑到因服务的并发应用部署或自动扩缩而导致的大量请求),并确保您的项目有足够的配额来处理此类事件。如果增加配额 则可以申请增加配额