java在Spring boot应用程序中配置GCP凭据的首选方法是什么
我正在编写一个基于spring boot的微服务,它将部署在GKE上。要配置服务帐户凭据,我确实看到有多个选项可用。可用的最首选且可能更安全的选项是什么。我尝试了以下方法,请建议其他方法
- CredentialsProvider与spring的接口。云gcp。资格证书位置
- 春天。云gcp。资格证书编码密钥
- GCP秘密管理器
你可以在下面搜索框中键入要查询的问题!
我正在编写一个基于spring boot的微服务,它将部署在GKE上。要配置服务帐户凭据,我确实看到有多个选项可用。可用的最首选且可能更安全的选项是什么。我尝试了以下方法,请建议其他方法
# 1 楼答案
尽管@Shailendra为您提供了一个很好的解决方案,但在使用GKE时,您可以将敏感信息存储为Kubernetes secrets
{a2}和{a3}文档都提供了一些创建机密的示例
稍后,您可以在简单用例中使用multiple ways中配置的机密作为environment variables在应用程序中使用。请参见this article
Th Spring Cloud Kubernetes项目支持将这些秘密作为property sources使用
这种方法允许您使用
minikube
或kind
在本地测试应用程序部署,然后将相同的构件部署到云提供商。此外,当您使用现成的Kubernetes工件时,它是云提供商不可知的我担心我们太专注于为您提供更多的选择,以至于最终我们没有回答您的问题
在此之前,我会给你使用库伯内特斯秘密的建议,它仍然是完美的,但请允许我稍后再回来
根据您正在尝试的different properties设置,您正在尝试代表您的应用程序配置凭据,以便与部署在GCP中的其他服务交互
为此,你首先需要的是一个service account
简而言之,服务帐户是一个软件工件,它凝聚了多个权限
此服务帐户稍后可以分配给特定GCP资源,分配给特定GCP服务,它将允许该资源在与其他GCP资源和服务交互时继承或代表配置的权限
每个服务帐户都有一组相关联的密钥,用于标识服务帐户,即您试图确保安全的信息
有不同类型的服务帐户,主要是,默认服务帐户,由GCP在启用或使用某些Google云服务时创建,一个用于计算引擎,一个用于应用引擎,以及用户定义的服务
您可以修改与这些服务帐户关联的权限:要记住的重要一点是始终遵循principle of least privilege,只授予服务帐户执行其任务所需的权限,而不授予其他权限
默认情况下,GKE集群将使用default Compute Engine service account和scopes for it defined。这些权限将在联系其他服务时由您的POD继承
因此,一个可能的选择就是为GKE配置一个适当的服务帐户,并在代码中使用这些权限
您可以使用默认的计算引擎服务帐户,但是,在描述如何加强集群安全性时,如GCP docs中所示:
所以,您可能需要创建一个具有运行集群(和)应用程序的最低权限的服务帐户。上述{a14}提供了所有必要的信息
作为替代方案,您可以为应用程序配置不同的服务帐户,在这里,您可以使用Kubernetes Secrets
请:
不要直接提供您自己的
CredentialsProvider
实现,我认为与其他解决方案相比,它不会为您提供任何额外的好处如果要使用
spring.cloud.gcp.credentials.location
配置属性,请创建Kubernetes secret和expose it as a file,并将此属性的值设置为该文件位置以一种非常类似的方式,使用Kubernetes Secrets,例如在this article中,您可以在环境变量
GOOGLE_APPLICATION_CREDENTIALS
下公开服务帐户凭据,Spring GCP和不同的GCP client libraries将查找该变量以获得所需的凭据我不会使用配置属性
spring.cloud.gcp.credentials.encoded-key
,我认为这种方法使密钥更适合于威胁-可能您必须处理VCS问题,等等秘密经理。。。正如我所说,正如@Shailendra在他的回答中所指出的,这是一个合适的解决方案
纪尧姆提供的选项也非常好
# 2 楼答案
如果您的应用程序在GCP上运行,首选的方法是使用Google GCP客户端提供的默认凭据。使用默认凭据提供程序时,客户端将使用与应用程序关联的服务帐户
# 3 楼答案
首选的方法很难回答。取决于你的愿望
就我个人而言,我更喜欢保持高水平的安全性,这与服务帐户身份验证有关,违反安全性可能是一场灾难
因此,也要保守秘密,我宁愿没有秘密。既不在K8S机密中,也不在机密管理器中!问题解决了
您可以通过ADC (application default credential)实现这一点。但是,像那样,ADC使用节点标识。这里的问题是,如果在同一个节点上运行多个pod,那么所有pod都将具有相同的标识,从而具有相同的权限
一个很酷的特性是使用Workload Identity。它允许您将服务帐户与K8S部署绑定。ADC原理是相同的,只是它是在pods级别绑定的,而不是在节点级别绑定的(创建了一个代理来拦截ADC请求)
# 4 楼答案
在云环境中,一般来说,管理开销最小的最安全和最好的选择是使用云提供商提供的相应服务——在您的情况下是Secret Manager。当然,如果您不打算将您的应用程序与特定的云提供商绑定,也不打算迎合on-prem环境,那么您可以使用第三方机密管理提供商,如HashiCorp Vault
但是,即使使用Secret Manager,如果您直接与API交互,您也必须提供密钥以在某个地方调用API,这会产生另一个问题。一般建议的解决方案是使用应用程序身份验证作为服务帐户,并直接与Secret manager交互,如here所述。或者,也可以使用CSI驱动程序在GKE卷上装载来自Secret Manager的机密,如here所述
运行一个安全的集群和容器应用程序是一个关键的要求,here是GKE安全强化的进一步建议,它还包括秘密管理。更具体地说,您可以查看“CIS GKE基准建议:6.3.1”一节中的建议