IAM policy for container-engine-robot.iam.gserviceaccount.com appears out of the void

[ctavan]

Terraform Version

0.9.5 (but tested with 0.9.11 as well)

Affected Resource(s)

• google_iam_policy

Terraform Configuration Files

# var.data_project_service_accounts contains:
# [
#   '***@cloudservices.gserviceaccount.com',
#   '***[email protected]',
# ]

data "google_iam_policy" "default" {
  binding {
    role = "roles/pubsub.editor"

    members = "${formatlist("serviceAccount:%s", var.data_project_service_accounts)}"
  }

  # Cloudsql proxy service account:
  binding {
    role = "roles/cloudsql.client"

    members = [
      "serviceAccount:***@***.iam.gserviceaccount.com",
    ]
  }
}

resource "google_project_iam_policy" "default" {
  policy_data = "${data.google_iam_policy.default.policy_data}"
}

Expected Behavior

I'm using the google_iam_policy data source to specify the IAM policies on a gcloud project which is managed 100% through terraform. I'm using container engine in this project.

When I ran terraform plan on this project again yesterday (the previous terraform run was some weeks before) I received several diffs which appeared out of the void.

Here's the output:

~ module.environment.google_project_iam_policy.default
    policy_data: "{\"bindings\":[{\"members\":[\"serviceAccount:***[email protected]\",\"serviceAccount:***@cloudservices.gserviceaccount.com\"],\"role\":\"roles/pubsub.editor\"},{\"members\":[\"serviceAccount:***@***.iam.gserviceaccount.com\"],\"role\":\"roles/cloudsql.client\"},{\"members\":[\"serviceAccount:service-***@container-engine-robot.iam.gserviceaccount.com\"],\"role\":\"roles/container.serviceAgent\"}]}" => "{\"bindings\":[{\"members\":[\"serviceAccount:***@cloudservices.gserviceaccount.com\",\"serviceAccount:***[email protected]\"],\"role\":\"roles/pubsub.editor\"},{\"members\":[\"serviceAccount:***@***.iam.gserviceaccount.com\"],\"role\":\"roles/cloudsql.client\"}]}"

~ module.environment.google_project_services.main
    services.#:          "17" => "11"
    services.1633256984: "appengine.googleapis.com" => "appengine.googleapis.com"
    services.1712537408: "containerregistry.googleapis.com" => ""
    services.2117420113: "pubsub.googleapis.com" => "pubsub.googleapis.com"
    services.238136042:  "cloudapis.googleapis.com" => "cloudapis.googleapis.com"
    services.2471815660: "servicemanagement.googleapis.com" => "servicemanagement.googleapis.com"
    services.2631575801: "sqladmin.googleapis.com" => "sqladmin.googleapis.com"
    services.2966512281: "deploymentmanager.googleapis.com" => ""
    services.3010261123: "replicapool.googleapis.com" => ""
    services.3075019877: "replicapoolupdater.googleapis.com" => ""
    services.3077910291: "resourceviews.googleapis.com" => ""
    services.323125032:  "cloudtrace.googleapis.com" => "cloudtrace.googleapis.com"
    services.3237295688: "monitoring.googleapis.com" => "monitoring.googleapis.com"
    services.3355193353: "logging.googleapis.com" => "logging.googleapis.com"
    services.3731214611: "compute-component.googleapis.com" => "compute-component.googleapis.com"
    services.3740470850: "container.googleapis.com" => "container.googleapis.com"
    services.3875785048: "storage-api.googleapis.com" => ""
    services.932568001:  "datastore.googleapis.com" => "datastore.googleapis.com"

Here's a nicer version of the interesting diff:

 {
   bindings: [
     {
       members: [
+        "serviceAccount:***[email protected]"
         "serviceAccount:***@cloudservices.gserviceaccount.com"
-        "serviceAccount:***[email protected]"
       ]
     }
     ...
+    {
+      members: [
+        "serviceAccount:service-***@container-engine-robot.iam.gserviceaccount.com"
+      ]
+      role: "roles/container.serviceAgent"
+    }
   ]
 }

While I don't really care about the re-ordering of the members in the first binding, I'm wondering where the container-engine-robot.iam.gserviceaccount.com service account came from?

I assume it was created automatically by Google Cloud.

My major question is: How to deal with such a situation? So far I haven't seen a negative impact in simply removing that IAM policy by running terraform apply. However I assume that Google Cloud doesn't create these service accounts just for fun and I'm wondering if it would automatically re-create them in case it really needs them?!

I recall hashicorp/terraform#13004 where there was a similar issue with Google Cloud APIs being enabled out of control of terraform. Is this a similar situation here (and would there be a similar solution)?

[ubschmidt2]

FWIW, for some of my GCP projects, I've received a notification email about Google adding said service account. This service account will be used by Container Engine to manage cluster resources in the project on your behalf. Do not remove/modify this service account if you are using the Container Engine API. Note that the service account will be automatically added back if you disable/enable the Container Engine API.

[danawillow]

There are two ways to handle this:

1. Be mindful when seeing diffs and add things like this into your config
2. Use the (not-yet-merged) google_project_iam_binding / google_project_iam_member resources to allow terraform to control only the ones you explicitly tell it to. You can follow along with Add google_project_iam_binding and google_project_iam_member resources. #171.

[ctavan]

@danawillow thanks for the insights!

For now, I've worked around the issue by changing the datasource to:

# var.data_project_service_accounts contains:
# [
#   '***@cloudservices.gserviceaccount.com',
#   '***[email protected]',
# ]
#
# var.project_id contains the numeric Google Cloud Project ID

data "google_iam_policy" "default" {
  binding {
    role = "roles/pubsub.editor"

    members = "${formatlist("serviceAccount:%s", var.data_project_service_accounts)}"
  }

  # Cloudsql proxy service account:
  binding {
    role = "roles/cloudsql.client"

    members = [
      "serviceAccount:***@***.iam.gserviceaccount.com",
    ]
  }

  # The following binding is always re-enabled by Google, see:
  # https://github.com/terraform-providers/terraform-provider-google/issues/214
  binding {
    role = "roles/container.serviceAgent"

    members = [
      "serviceAccount:service-${var.project_id}@container-engine-robot.iam.gserviceaccount.com",
    ]
  }
}

On the long run I would of course prefer the solution of #171 but the current workaround is also fine for now. Hence I'll close this issue.

Thanks again for the support!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!