google_compute_instance with user-managed service account and empty scopes list results in no SA assignment

[danekantner]

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

1.3.9, 1.3.1 also

Affected Resource(s)

google_compute_instance

Terraform Configuration Files

resource "google_service_account" "foobar_test" {
  account_id   = "dk-sandbox-test"
  display_name = "dk-sandbox-test"
  description  = "compute SA"
}

resource "google_compute_instance" "foobar" {
  name         = "dk-test-perms"
  machine_type = "e2-micro"
  zone         = "us-central1-a"
  
  network_interface {
    network = "default"
    subnetwork = "dk-test"
  
   # access_config {}
  }
  
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-10-buster-v20210512"
    }
  }
  service_account { 
    email  = google_service_account.foobar_test.email
    scopes = []
  }   
}

Expected Behavior

The same cli command with an empty scope and a user-managed SA provided results in the VM being created with the SA you've specified assigned, and no scopes set, as expected.

This command, for example, results in the expected behavior.

gcloud compute instances create dk-manual-test-3 \
    --project=[projectid] \
    --zone=us-central1-a \
    --machine-type=e2-medium \
    --network-interface=subnet=dk-test,no-address \
    --maintenance-policy=MIGRATE \
    --provisioning-model=STANDARD \
    --service-account=dk-sandbox-test@[fooprojectid].iam.gserviceaccount.com \
    --scopes= \                                              
    --create-disk=auto-delete=yes,boot=yes,device-name=dk-manual-test-3,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230206,mode=rw,size=10,type=projects/[fooprojectid]/zones/us-central1-a/diskTypes/pd-balanced \

The resultant SA and assignment by this cli command creation is:

Actual Behavior

The VM is created with no service account and no scopes. This is the same behavior as if you had picked "No Service Account" and no Scopes in the UX.

Steps to Reproduce

1. Set up a resource with email = my-service@[projectid].iam.gserviceaccount.com and scopes = [] in the service_account block.
2. terraform apply

Important Factoids

scopes itself is a required field (as a construct of how it was it was implemented in the provider, not GCP itself) but there is no validation for the plan checking on the count > 1 or similar.

References

b/317497258

[edwardmedia]

The issue: serviceAccount is missing in the playload when scope is empty.

    "serviceAccounts": [
        {
            "email": "issue13807@myproject.iam.gserviceaccount.com",
            "scopes": []
        }
    ]

[ScottSuarez]

@edwardmedia i wasn't able to find the time to fix this last week. Removing assignment

[melinath]

I checked and can confirm this is still an issue. Here's a config to reproduce:

resource "google_service_account" "foobar_test" {
  account_id   = "dk-sandbox-test"
  display_name = "dk-sandbox-test"
  description  = "compute SA"
}

resource "google_compute_instance" "foobar" {
  name         = "dk-test-perms"
  machine_type = "e2-micro"
  zone         = "us-central1-a"
  
  network_interface {
    network = "default"
  }
  
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-10-buster-v20210512"
    }
  }
  service_account { 
    email  = google_service_account.foobar_test.email
    scopes = []
  }   
}

This results in a create request like:

---[ REQUEST ]---------------------------------------
POST /compute/v1/projects/my-project-id/zones/us-central1-a/instances?alt=json&prettyPrint=false HTTP/1.1
Host: compute.googleapis.com
User-Agent: google-api-go-client/0.5 Terraform/1.5.6 (+https://www.terraform.io) Terraform-Plugin-SDK/2.10.1 terraform-provider-google/5.9.0
Content-Length: 482
Content-Type: application/json
X-Goog-Api-Client: gl-go/1.20.11 gdcl/0.152.0
Accept-Encoding: gzip

{
 "canIpForward": false,
 "deletionProtection": false,
 "disks": [
  {
   "autoDelete": true,
   "boot": true,
   "initializeParams": {
    "sourceImage": "projects/debian-cloud/global/images/debian-10-buster-v20210512"
   },
   "mode": "READ_WRITE"
  }
 ],
 "machineType": "projects/my-project-id/zones/us-central1-a/machineTypes/e2-micro",
 "metadata": {},
 "name": "dk-test-perms",
 "networkInterfaces": [
  {
   "network": "projects/my-project-id/global/networks/default"
  }
 ],
 "params": {},
 "scheduling": {
  "automaticRestart": true
 },
 "tags": {}
}

Looking at expandServiceAccounts it doesn't seem like we're doing anything unusual here, so my guess is that this might be a behavior of the Go client library for compute, which is ultimately responsible for the Insert call.