Terraform plan after apply has additional ACL changes required and never resolves.

[srunix88]

Summary:
After running terraform apply, a subsequent terraform plan indicates it needs to perform additional changes for ACLs even though the plan indicated it completed. (see output samples below).

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

google_service_account.service-account: Refreshing state... (ID: projects/projectname/serviceaccount-dev.iam.gserviceaccount.com)
google_storage_bucket.bucket: Refreshing state... (ID: tfgcpmultitest)
google_storage_bucket_acl.service-account-bucket-acl: Refreshing state... (ID: tfgcpmultitest-acl)

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ google_storage_bucket_acl.service-account-bucket-acl
      role_entity.#: "4" => "1"
      role_entity.0: "OWNER:project-owners-874862373282" => "OWNER:<serviceaccountemail>
      role_entity.1: "OWNER:project-editors-874862373282" => ""
      role_entity.2: "READER:project-viewers-874862373282" => ""
      role_entity.3: "OWNER:<serviceaccountemail>
Plan: 0 to add, 1 to change, 0 to destroy.

If you run apply multiple times afterward, it will appear to perform a change, but plan will still show a change is required.

Terraform Version

Terraform v0.11.1

Affected Resource(s)

~ google_storage_bucket_acl

Terraform Configuration Files

provider "google" {
  version = "~> 1.4.0"
  project = "${var.project}"
  region  = "${var.region}"
}

resource "google_service_account" "service-account" {
  account_id   = "${var.project}-${var.asset_id}-sa"
}

resource "google_storage_bucket" "bucket" {
  name = "${var.bucket_name}"
  storage_class = "${var.storage_class}"
  location = "${var.location}"
  labels   = {
    cost-center = "${var.cost_center}"
    provisioner = "io1"
    asset-id = "${var.asset_id}"
    experience = "${var.experience}"
    requester = "${var.requester}"
  }
}

resource "google_storage_bucket_acl" "service-account-bucket-acl" {
  bucket = "${google_storage_bucket.bucket.name}"

  role_entity = [
    "OWNER:user-${google_service_account.service-account.email}",
  ]
}

Expected Behavior

It should not think it needs to make additional changes after an apply is run.

Actual Behavior

After configuring the ACLs, which work, it thinks it needs to update the ACLs again.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform init -from-module=$GCP_DIR/storage-bucket
2. terraform plan $VARS
3. terraform apply --auto-approve $VARS
4. terraform plan $VARS

Important Factoids

We are using modules and testing by passing values on the command line.

References

none

[rosbo]

Hi @srunix88,

The behavior is definitely wrong and has to be fixed. The original author of this resource even left a comment in the code about it:

// The API offers no way to retrieve predefined ACLs,
// and we can't tell which access controls were created
// by the predefined roles, so...
//
// This is, needless to say, a bad state of affairs and
// should be fixed.

Have you considered using IAM permission on the bucket instead of ACL?
https://cloud.google.com/storage/docs/access-control/lists
https://www.terraform.io/docs/providers/google/r/storage_bucket_iam.html

Thank you

[sl1pm4t]

Hi @rosbo

Have you considered using IAM permission on the bucket instead of ACL?

Just to add my 2c - I also came across this problem recently while trying to set permissions on a bucket for stackdriver logging export/sink. I thought I'd be able to use IAM permissions instead of the legacy ACL's but the log export refused to work unless I added the logging service account to the ACL.

[paddycarver]

I left the comment being referenced there, but I believe it's for a different scenario. That comment specifically refers to the case where a predefined ACL is used (e.g., publicRead) which the API translates into a set of ACLs on the backend. Terraform can't match those anymore. It looks like in this case full ACLs are being used, in the OWNER:user-WHATEVER format, which Terraform should be able to handle...

We had a solution for this at one point.... I think #358 was the solution. It looks like what's happening is that GCS creates certain ACLs automatically for buckets, granting permissions to project owners and editors and viewers. #358 was to overwrite those permissions, I believe. It looks like somehow that has come undone.

[paddycarver]

Ah, 7211463#diff-3fea3b74d283e6b124ef3009fc921ec3 has more information, too.

I believe a possible workaround would be to add OWNER:project-owners-PROJECTNUMBER, OWNER:project-editors-PROJECTNUMBER, and READER:project-viewers-PROJECTNUMBER to your config, which should cause the issue to go away, though it's a less-than-ideal solution.

[paddycarver]

I believe #1692 resolved this. If anyone is still experiencing it, please feel free to reply, and we can reopen this.

[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!