在Spring应用程序中配置GCP凭据的首选方法是什么

Question

我正在编写一个基于spring引导的微服务，它将部署在GKE上。要配置服务帐户凭据，我确实看到有多个选项可用。什么是最可取的，可能是更安全的选择。我尝试过以下方法，请提出其他方法。

1. CredentialsProvider与spring.cloud.gcp.credentials.location接口
2. spring.cloud.gcp.credentials.encoded-key
3. GCP分泌经理

Answer 1

在云环境中，管理开销最少的最安全和最好的选择是使用来自云提供者的相应服务--在您的例子中，将是秘密经理。当然，如果您不打算将您的应用程序与特定的云提供商捆绑在一起，或者也要迎合or环境，那么您可以使用第三方秘密管理提供商，比如HashiCorp跳台。

但是，即使使用秘密管理器，如果直接与API交互，也必须提供键来调用API，这就产生了另一个问题。一般推荐的解决方案是使用应用程序身份验证作为服务帐户，并像概述的这里那样直接与秘密管理器交互。或者有其他的方法来安装秘密管理器的GKE卷使用CSI驱动程序，如解释的这里。

运行一个安全的集群和容器应用程序是一个关键的需求，而这里是GKE安全强化的进一步建议，这也包括秘密管理。更具体地说，您可以查看"CIS GKE基准建议: 6.3.1“一节中的建议。

Answer 2

尽管@Shailendra为您提供了一个很好的解决方案，但在使用GKE时，您可以将敏感信息存储为库伯奈特的秘密。

库伯内斯和GKE文档都提供了创建秘密的几个示例。

在简单的用例中，您以后可以使用多途径中配置的机密作为应用程序中可以使用的环境变量。请你也看看这篇文章。

Th项目提供了作为财产来源使用这些秘密的支持。

这种方法允许您在本地使用minikube或kind测试应用程序部署，然后将相同的构件部署到云提供商。此外，它是云提供商不可知论的，因为您正在使用的是开箱即用的Kubernetes工件。

恐怕我们太专注于为你们提供更多的替代办法，最后我们实际上没有回答你们的问题。

以前，我会给你使用库伯奈特斯秘密的建议，它仍然是完全好的，但请允许我稍后再谈。

根据您正在尝试的不同性质设置，您正在尝试代表您的应用程序配置凭据，与部署在GCP中的其他服务进行交互。

为此，您首先需要的是一个服务帐户。

简而言之，服务帐户是一个软件构件，它聚集了多个权限。

以后可以将该服务帐户分配给某个GCP资源、某个GCP服务，并且它将允许该资源在与其他GCP资源和服务交互时继承或代理配置的权限。

每个服务帐户都将有一组相关的密钥，用于标识服务帐户--您试图保存的信息。

有不同类型的服务帐户，主要是GCP在启用或使用某些Google服务时创建的默认服务帐户--一个用于计算引擎，另一个用于App -以及用户定义的帐户。

您可以修改与这些服务帐户相关联的权限:要记住的重要事项是始终遵循最小特权原则，只授予服务帐户执行其任务所需的权限，而不授予其他任何权限。

默认情况下，GKE集群将使用默认计算引擎服务帐户和定义的作用域。当您与其他服务联系时，这些权限将由您的荚继承。

因此，一个可能的选择就是为GKE配置一个适当的服务帐户，并在代码中使用这些权限。

您可以使用默认的Compute服务帐户，但是，正如GCP文档在描述如何加强集群安全性时所指出的那样：

每个GKE节点都有一个与其相关联的标识和访问管理(IAM)服务帐户。默认情况下，节点被赋予Compute默认服务帐户，您可以通过导航到云控制台的IAM部分找到该帐户。默认情况下，这个帐户具有广泛的访问权限，这使得它对各种各样的应用程序都很有用，但是它拥有比运行Kubernetes引擎集群所需的更多权限。您应该创建和使用一个最低特权的服务帐户来运行您的GKE集群，而不是使用Compute默认服务帐户.

因此，您可能需要创建一个具有运行群集(和)应用程序最低权限的服务帐户。上述链接提供了所有必要的信息。

作为另一种选择，您可以为您的应用程序配置一个不同的服务帐户，作为一种可能的选择，您可以在这里使用Kubernetes秘密。

请：

• 不要直接提供您自己的CredentialsProvider实现，我认为与其他解决方案相比，它不会给您带来任何额外的好处。
• 如果要使用spring.cloud.gcp.credentials.location配置属性，请创建一个Kubernetes秘密和将其公开为文件，并将该属性的值设置为该文件位置。
• 以非常类似的方式，使用Kubernetes，例如在这篇文章中，您可以在环境变量GOOGLE_APPLICATION_CREDENTIALS下公开服务帐户凭据，春季GCP和不同的GCP客户端库都会查找这个变量以获得所需的凭据。
• 我不会使用配置属性spring.cloud.gcp.credentials.encoded-key，在我看来，这种方法使关键更适合于威胁--可能您必须处理VCS问题，等等。
• 秘密经理..。正如我所说，正如@Shailendra在他的答复中所指出的，这是一个合适的解决方案。
• 纪尧姆提供的选择也很好。

Answer 3

最好的办法是很难回答。取决于你的愿望..。

就我个人而言，我更倾向于保持高度的安全性，这与服务帐户认证有关，而违规可能是一场灾难。

所以，太保守秘密，我宁愿没有秘密。既不是K8S的秘密，也不是秘密的经理！问题解决了！！

您可以通过应用程序默认凭据实现这一点。但是，就这样，ADC使用节点标识。这里的问题是，如果您在同一个节点上运行多个荚，所有节点都将具有相同的标识，从而具有相同的权限。

一个很酷的特性是使用工作负载标识。它允许您将服务帐户绑定到K8S部署中。ADC原则是相同的，只不过它是在荚级而不是在节点级别绑定(创建了一个代理来拦截ADC请求)