我正在使用 Cloud Run 作为我正在进行的项目的后端，部分原因是它的免费套餐很慷慨（每月 200 万个请求，免费）。但这些服务需要一些秘密值（数据库密码、Oauth 密钥等），因此我遵循 Google 的建议将这些值存储在 Google Secret Manager 中，并通过 Cloud Run 将它们加载为环境变量。
但是，Secret Manager 的免费套餐限制要严格得多，每月仅可免费访问 10,000 次。如果 Cloud Run 几乎为每个请求都启动一个容器，那么它似乎也必须以大约这个速率访问机密，从而大大减少了免费套餐配额。
我的问题是，我应该如何为我的 Cloud Run 实例设置环境变量，而不破坏最初使该平台如此有吸引力的免费套餐？简单地将数据库密码等放在环境变量中似乎是个坏主意，但我不清楚这实际上会带来多大的安全风险，因为该项目是一个学生网站，数据库中不包含任何敏感的个人信息，而且考虑到具有 Google Cloud 控制台管理权限的用户无论如何都可以从秘密管理器访问秘密值。
答案1
为 Secret Manager 付费。实现它的硬件安全模块和合规性证明不是免费的。
或者想出不同的解决方案。不同的机密管理软件、不太复杂的纯文本文件中的机密存储、不同的应用程序部署模型。这可能与仅使用托管的 Cloud Run 产品不兼容。
我不清楚这实际上会带来多大的安全风险，因为该项目是一个学生网站，数据库中不包含任何敏感的个人信息
从整体上看，这可能对您的组织来说是一个小风险，但对秘密掉以轻心是一个坏习惯。
每个应用程序，即使是简单合规环境中的小型应用程序，也应该得到一定程度的机密保护。至少要限制访问配置文件。绝对不能嵌入到应用程序代码中。
无论如何，具有 Google Cloud 控制台管理权限的用户都可以从秘密管理器访问秘密值。
向授权管理员隐藏数据并不是机密系统的目的。任何机密的访问或删除都会被记录下来。理论上，这可以捕捉到向攻击者泄露机密的行为，或者在应该轮换的时间之后使用旧版本的行为。
答案2
为了降低成本，您需要弄清楚什么是保持容器正常运行或允许其关闭的最佳方法。
简而言之，Cloud Run 容器最多可以闲置 15 分钟，然后才会关闭。最大化其运行时间往往可以避免向 Secret Manager 发出额外请求。
您可以配置一个监控系统，在访问量最大的时段每 10 分钟向您的应用程序发送一次请求，以保持您的容器正常运行，而在访问量较少的时段不发送任何请求，以便让它在晚上关闭。
这样，您可以最大限度地减少集装箱在营业时间内的启动和冷启动，并允许它们在夜间关闭以节省成本。