App Engine 服务的自定义服务帐号

Question

我在我们项目的 GCP（谷歌云平台）App Engine 上运行了多个微服务。 在我们的例子中，最好在每个服务的基础上最小化权限。 目前，我们将所有凭证文件保存在 Keybase 中，并按团队成员划分秘密。 因此，如果我正在开发一个 App Engine 服务，我无法看到另一个团队的 App Engine 服务的秘密。 我们一直在为其他机密做些什么，例如带有密码和秘密令牌的配置文件，我们赋予应用引擎服务帐户 kms 解密权限，并简单地从 firestore 拉取配置文件的加密副本并解密。 但是我们不想到处使用默认的应用引擎服务帐户，因为使用相同服务帐户的不同团队可以访问每个人的秘密。 因此，我们希望在开发中的每个应用引擎服务的每个服务基础上转移到服务帐户。

从我在 Google 文档中可以看出，他们希望您在我们部署应用程序时上传凭证文件，这可以工作，但是，从云控制台，似乎很难锁定谁可以查看部署到服务的文件，任何有权访问的人都可以简单地复制/粘贴所有凭据。

如果您在字典中有配置，则执行以下操作：

from google.oauth2 import service_account
from google.cloud import kms_v1
d = {'type': 'service_account',
     'project_id': 'my-awesome-project',
     'private_key_id': '074139282fe9834ac23401',
     'private_key': '-----BEGIN PRIVATE KEY----\n supersecretkeythatnobodyknows==\n-----END PRIVATE KEY-----\n',
     'client_email': 'my-cool-address@my-awesome-project.iam.gserviceaccount.com',
     'client_id': '1234567890',
     'auth_uri': 'https://accounts.google.com/o/oauth2/auth',
     'token_uri': 'https://oauth2.googleapis.com/token',
     'auth_provider_x509_cert_url': 
     'https://www.googleapis.com/oauth2/v1/certs',
     'client_x509_cert_url': 'https://www.googleapis.com/robot/v1/metadata/x509/my-cool-addres%40my-awesome-project.iam.gserviceaccount.com'}

credentials = service_account.Credentials.from_service_account_info(d)
kms_client = kms_v1.KeyManagementServiceClient(credentials=credentials)

这行得通，但是我们如何将字典“d”放入程序中，而不会出现在代码中并被广泛的人访问？

Answer 1

如果您的 AppEngine 环境中的每个服务都必须有自己的身份，那么 AppEngine 就不可能。 较新的服务如 Cloud Function 或 Cloud run 可以做到这一点，但非常旧的服务（云时代）AppEngine（超过 10 年）不能。

您拥有所有 AppEngine 服务的服务帐户。 您可以使用它来解密其他服务帐户密钥文件，每个服务并在适当的服务中使用它们，但根授权保留默认的 App Engine 服务帐户，因此所有服务/所有团队都可以访问它（以及所有加密的服务帐户密钥文件）。

也许解决方案是重新设计应用程序并为每个团队创建一个项目？

Answer 2

guillaume blaquiere 在他的回答中所说的是正确的，我也同意他关于每个团队都有一个项目的想法。 您不能为 App Engine 的每项服务创建不同的服务帐户。

尽管您想要实现的目标可能在 App Engine 中以某种方式成为可能。 好的，所以您无法找到一种方法，只允许某个团队提供某些服务，而其他团队提供另一个服务。 您可以做的（但我认为您不希望这样做，我也不推荐）是通过使用防火墙控制您的访问来阻止某些 IP。 您可以创建自己的防火墙规则并允许来自一个地方的请求，而不是来自另一个地方的请求。

这只是一个技巧，可能对您有用，也可能对您无效。 真正的建议是，如果您真的想使用更多服务帐户干净、正确地实施您描述的系统，您应该考虑迁移到Cloud Run 。