在 KMS 中安全地存储应用程序默认凭据答案

【问题标题】：Storing Application Default Credentials securely in KMS在 KMS 中安全地存储应用程序默认凭据
【发布时间】：2020-09-16 22:54:12
【问题描述】：

我们有一个使用 Google Auth 允许使用的 Java 应用程序。该应用程序需要连接到被锁定在 IP 限制之后的 Google Cloud SQL 数据库。

我们需要使用 Cloud SQL Socket Factory 和 Cloud SQL 代理来访问数据库，这需要应用程序默认凭据和环境变量 GOOGLE_APPLICATION_CREDENTIALS 指向服务帐户凭据 JSON 文件。我不确定如何安全地存储此文件，将该文件放在用户的 PC 上显然不安全。

根据https://cloud.google.com/docs/authentication/production 的最佳实践，它说

您可以使用指向应用程序源代码之外的凭据的环境变量，例如 Cloud Key Management Service。

但这并没有继续解释如何做到这一点。如何以只有经过授权的 Google 帐户才能访问的方式安全地将该文件存储在 KMS 或其他方式中？

【问题讨论】：

标签： google-cloud-platform google-cloud-sql google-cloud-kms cloud-sql-proxy

【解决方案1】：

首先，Cloud SQL 代理和 Cloud SQL JDBC 套接字工厂是同一事物的两种不同实现。 Socket Factory 在你的应用程序内部使用，而代理是一个外部进程。没有理由同时使用两者。

其次，如何保护您的应用在很大程度上取决于您计划如何分发和运行它。如果它是一个 Web 应用程序，您可能会创建一个“服务帐户”来表示您希望您的应用程序拥有的权限，然后使用任何有效的方法（防火墙、oauth 等）限制对应用程序前端的访问。

如果您的应用是本地分发到用户平台的东西，那么它会更复杂一些，并且更难保护。问题是，任何有权访问您的应用程序的人都可能访问您的数据库或其他资源。由于您不能使用gcloud，您可以重新实现您自己的具有用户登录名的身份验证层（如gcloud auth application-default login）并生成可用于连接的临时凭证文件。

或者，您可以将凭据包含在应用程序本身中。您可以直接嵌入它们，但如果它受到损害，那么您必须重新分发应用程序。可能更安全的是单独分发凭证文件，并为每个用户创建不同的凭证文件。这样，如果一个人被入侵，您只需要轮换被入侵的帐户。

据我所知，没有办法使用 KMS 来存储服务帐户，因为您仍然需要一些方法来对 KMS 本身进行身份验证。

【讨论】：

【解决方案2】：

你是对的：使用服务帐户密钥文件不是一个好的做法，而且它是一个安全漏洞（除了将它安全地存储在计算机上，你必须每 90 天轮换一次，你可以复制文件，发送它通过电子邮件，甚至在 git repo 上公开提交！！）

但是，对于使用云 SQL 代理，您可以简单地使用自己的凭据。执行gcloud auth application-default login。确保您的用户在数据库上获得授权，仅此而已！

注意：当你启动你的云 sql 代理时，一定不要使用参数 -credential

【讨论】：

只是为了确认 - 这需要我们应用程序的用户安装 Google Cloud SDK 并运行该命令？没有办法只从我们的应用程序代码无缝连接？
是的，用户需要安装它，但它更多的是为开发人员而不是用户。如果您需要在用户计算机上部署独立应用程序，您可以将服务帐户硬编码到您的代码中。无论如何，严格限制服务帐户的角色。如果您在服务之外发送，即使嵌入在您的代码中，您也不确定它不会被入侵者恢复。
由于设备被锁定，我们无法让用户安装 SDK。如果我们要将它们硬编码到应用程序中，您是否对“Cloud SQL Socket Factory”了解很多，它似乎是使用 Java 和 Cloud Proxy 的唯一方法，以及我们如何应用这些凭据？看起来它使用“应用程序默认凭据”，因此手动提供凭据似乎是不可能的。
我只在服务器上部署了应用程序，从不在最终用户计算机上。我认为可以在最终的二进制文件中打包一些东西。我不确定，这取决于用户的操作系统。不是一件容易的事。