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 之外安全地存储和访问其他密文。

编码做法

避免通过文件系统或环境变量将密文传递给应用。以下是使用其他方法处理 Secret 的一些原因：

  • 在可以通过文件系统访问密文时，目录遍历攻击等应用漏洞的严重级别可能更高，因为攻击者可能会获得读取密文材料的权限。

  • 在通过环境变量使用密文时，配置错误（例如启用调试端点或包含记录进程环境详细信息的依赖项）可能会泄露密文。

  • 在将密文材料同步到其他数据存储区（如 Kubernetes Secret）时，请评估该数据存储区提供的访问权限控制。请考虑以下事项：

    • 数据存储区是否会扩展密文的访问权限？

    • 是否可以审核 Secret 的访问权限？

    • 数据存储区是否符合静态数据加密和区域化要求？

我们建议您使用某个提供的客户端库，或者按照 REST 或 GRPC 文档操作，直接使用 Secret Manager API。

管理

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

在销毁密文版本或删除密文之前先停用密文版本。通过将密文置于看起来与销毁相同但可逆转的状态，可帮助防止发生中断。也就是说，您可以停用密文版本并等待一周，以确保在永久删除数据之前没有持续存在的依赖项。

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

定期轮替您的密文，以便执行以下操作：

  • 限制密文泄露时的影响。

  • 确保不再需要访问密文的个人无法继续使用之前访问的密文。

  • 降低服务中断的可能性。

使用 Cloud Asset Inventory 监控组织中的密文，原因如下：

  • 帮助识别您的组织中的密文。

  • 识别是否不符合组织要求，例如轮替、加密配置和位置。

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

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

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

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

数据驻留合规性

如果您有严格的数据驻留和主权要求，请选择区域 Secret。借助区域 Secret，您可以在特定地理位置存储敏感数据，从而全面保证数据在静态存储、使用中和传输中的安全，帮助您遵守与数据驻留相关的法律、法规或组织要求。