关于服务帐户"Duality"的说明

Question

我有两个Cloud Run服务。Service U的"未认证访问"对所有用户开放。Service R我想限制访问，这样只有Service A可以调用它

这个要点使用CLI有一个非常简洁的实现。我的服务配置了Terraform，我正在尝试翻译，但也理解:

基于此，我认为我可以通过添加U的服务帐户(我将service_account: [e-mail]添加到服务U的google_cloud_run_service.spec.service_account_name)来允许服务U访问服务R，就像我向所有用户开放访问一样。这里是allUsers:

resource "google_cloud_run_service" "service_r" {
name                       = local.service_name
# ... rest of the service definition
}
resource "google_cloud_run_service_iam_member" "run_all_users" {
service  = google_cloud_run_service.service_r.name
location = google_cloud_run_service.service_r.location
role     = "roles/run.invoker"
member   = "allUsers"
depends_on = [
google_cloud_run_service.service_r,
]
}

我将其修改为仅适用于一个服务帐户:

resource "google_cloud_run_service_iam_member" "run_all_users" {
service  = google_cloud_run_service.service_r.name
location = google_cloud_run_service.service_r.location
role     = "roles/run.invoker"
member = "serviceAccount:[e-mail]
depends_on = [
google_cloud_run_service.service_b,
]
}

这似乎行不通。

但是，添加一个创建策略的数据源似乎确实有效:

data "google_iam_policy" "access_policy" {
binding {
role = "roles/run.invoker"
members = [
"serviceAccount:[e-mail]",
]
}
}
resource "google_cloud_run_service_iam_policy" "cloud_run_policy" {
location    = google_cloud_run_service.service_r.location
project     = google_cloud_run_service.service_r.project
service     = google_cloud_run_service.service_r.name
policy_data = data.google_iam_policy.access_policy.policy_data
}

我在这个SO回答(和其他地方)上读到服务帐户是身份和资源。这就是这里发生的事情吗?也就是说，我没有使用服务帐户[e-mail]作为标识，而是将其作为"资源"附加到服务R。这是什么"政策"吗?是在这种情况下吗?在GCR UI中有什么地方我可以看到这些关系吗?

Answer 1

好的，我会尽量澄清措辞和情况，即使我没有抓住你最近的两段代码之间的变化。

二元性

是的，服务帐户具有两重性:它们是身份和资源。因为它们是资源，所以您可以在其上授予身份(特别是执行模拟)。

<<p>

的访问策略/strong>它只是一个身份和角色之间的绑定。然后，您必须将该绑定应用于资源，以将资源上的角色授予标识。这三个是一个IAM授权策略，或者简称为策略。

服务及业务帐户

你的问题很难理解，因为你把Cloud Run服务和服务帐户混在一起了。

Cloud Run服务有一个身份:运行时服务帐户。

一个云运行服务不能访问另一个云运行服务。但是一个Cloud Run服务的身份可以访问另一个Cloud Run服务。

---

也就是说，你的两段最新代码之间没有区别。事实上，两者是有区别的，但第二个定义比第一个定义更具限制性。

在最新的一个中，您使用....._iam_policy。这意味着你要替换所有的政策。换句话说，access_policy"重写所有现有权限。

在前面的例子中，使用....._iam_member。这意味着您只需向当前资源添加一个策略，而无需更改现有的策略。

这就是为什么，结果是相同的:service-u在service_r上具有Invoker角色。

你能再试一次吗?问题在别处。