Terraform-provider-google: google_project_default_service_accounts Cleaned up the whole IAM

Created on 23 Nov 2020  ยท  11Comments  ยท  Source: hashicorp/terraform-provider-google

Community Note

  • Please vote on this issue by adding a ๐Ÿ‘ reaction to the original issue to help the community and maintainers prioritize this request.
  • Please do not leave _+1_ or _me too_ comments, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.
  • If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

# terraform --version
Terraform v0.13.5
+ provider registry.terraform.io/hashicorp/external v2.0.0
+ provider registry.terraform.io/hashicorp/google v3.48.0
+ provider registry.terraform.io/hashicorp/google-beta v3.48.0
+ provider registry.terraform.io/hashicorp/local v2.0.0
+ provider registry.terraform.io/hashicorp/null v3.0.0
+ provider registry.terraform.io/hashicorp/random v3.0.0
+ provider registry.terraform.io/hashicorp/vault v2.15.0

Affected Resource(s)

google_project_default_service_accounts

Terraform Configuration Files

# Deprivilege default service accounts
resource "google_project_default_service_accounts" "deprivilege_default_service_accounts" {
  project = var.project_name
  action  = "DEPRIVILEGE"
}

Expected Behavior

Remove all privileges from default service accounts only.

Actual Behavior

Maybe I was missing something from the documentation or misunderstood the behavior of the resource, but after applying the plan, it completely cleared up the IAM project policies, except the inherited permissions. Removed every single piece from there, not just from the default service accounts, but revoked the permissions from ALL user/group/service accounts.

After my panic, I was deleting the resource, but the restore doesn't happened. I had to restore the default privileges of all GCP SA accounts:

gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:[email protected] --role=roles/cloudbuild.builds.builder
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:[email protected] --role=roles/editor
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:[email protected] --role=roles/compute.serviceAgent
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:service-$PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com --role=roles/container.serviceAgent
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:service-$PROJECT_NUMBER@containerregistry.iam.gserviceaccount.com --role=roles/editor
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:[email protected] --role=roles/file.serviceAgent
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:service-$PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com --role=roles/dataproc.serviceAgent
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:[email protected] --role=roles/cloudfunctions.serviceAgent
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com --role=roles/cloudbuild.serviceAgent
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-firewallinsights.iam.gserviceaccount.com --role=roles/firewallinsights.serviceAgent
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:[email protected] --role=roles/osconfig.serviceAgent
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:service-$PROJECT_NUMBER@service-networking.iam.gserviceaccount.com --role=roles/servicenetworking.serviceAgent

Before this script (18 projects... Yes, I know, why I was not try in a single one), terrafrom plan is failed. After this script - I was able to run both terraform plan and terraform apply .

Steps to Reproduce

  1. terraform apply
bug

All 11 comments

@Clausewitz45 as doc says, DEPRIVILEGE action can't be reverted. You can use DELETE action if you want IAM policies to be restored upon deletion of the resource.

Doc:
The action to be performed in the default service accounts. Valid values are: DEPRIVILEGE, DELETE, DISABLE. Note that DEPRIVILEGE action will ignore the REVERT configuration in the restore_policy

Config

 resource "google_project_default_service_accounts" "my_project" {
  project = var.project_id
  action = "DELETE"
  restore_policy = "REVERT"
}

@venkykuberan many thanks for the feedback, but this wasn't the main problem. The main problem was that not just the default service accounts were cleaned up, but everything. During the Terraform apply, all users, groups, custom service accounts have been deprivileged which means that either the documentation is inaccurate or something is wrong with the resource. From the documentation:

When certain service APIs are enabled, Google Cloud Platform automatically creates service accounts to help get started, but this is not recommended for production environments as per Google's documentation. See the Organization documentation for more details. ~> This resource works on a best-effort basis, as no API formally describes the default service accounts. If the default service accounts change their name or additional service accounts are added, this resource will need to be updated.

I cannot see here that everything will be deprivileged.

@venkykuberan: Do you mind verifying whether or not you see the same behaviour, where non-default-SA IAM bindings/members are affected?

@rileykarson I don't see any non-default SAs/users are affected on my end by that resource.

I read the code wrong ๐Ÿ˜ž .

This looks like it should work, I'll have to manually test to verify.

To confirm, @Clausewitz45 you're saying that applying the resource with DEPRIVILEGE removes IAM permissions from service accounts that are not default service accounts? The service accounts you are granting permission to look like the default service accounts: gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:[email protected] --role=roles/cloudbuild.builds.builder

@slevenick: The default service accounts this resource covers are specifically the same-project ones of which there are exactly two, I think? GCE and AppEngine: https://github.com/hashicorp/terraform-provider-google-beta/blob/master/google-beta/resource_google_project_default_service_accounts.go#L207-L208

Ah, yeah it looks like we list all service accounts and remove permissions from them: https://github.com/GoogleCloudPlatform/magic-modules/blob/master/third_party/terraform/resources/resource_google_project_default_service_accounts.go#L169

That can't be right

That list gets filtered: https://github.com/GoogleCloudPlatform/magic-modules/blob/master/third_party/terraform/resources/resource_google_project_default_service_accounts.go#L147-L158

While you're in the resource, we could inline a whole bunch of the code to make it clearer to read.

@slevenick Yes, I can confirm, after running terraform apply my IAM was completely cleaned up. Not just GCP service accounts, but user accounts and our own service accounts too.

Yeah, I've got a fix for this coming. There is definitely a bug with DEPRIVILEGE I would recommend not using that action until the fix is available.

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!

Was this page helpful?
0 / 5 - 0 ratings