fix: fix gcp permissions for gcp relay in terraform module (JIRA https://stacklet.atlassian.net/browse/ENG-5290)

[hiteshmck]

ENG-XXXX

Based on the freshdesk ticket https://stacklet.freshdesk.com/a/tickets/1199, Epsilon is having some issues with gcp relay setup on their side.
I setup my gcp project to setup gcp relay myself and had following observations and some fixes which are would be in the PR.

My Setup :

• I used existing project(hitesh-sanbdox) to replicate customer issue. (didn't create a new project)
• I followed the documentation at https://docs.demo.stacklet.io/how-to/configure-gcp-relay/ and used the terraform provided there.

Observations

• I encountered some permission issues related to service account {project}-compute@developer.gserviceaccount.com
• It may have worked when we originally tested the terraform as {project}-compute@developer.gserviceaccount.com may have Editor or other power privileges so no permission issues at that time.
• I specifically removed any permission from {project}-compute@developer.gserviceaccount.com and then tested the terraform to make sure we give only the least needed permissions to this role per best practices.

Change # 1

• I had to add following roles
  "roles/artifactregistry.writer", --needed for cloudbuild to create cloud run function
  "roles/logging.logWriter", --needed for cloudbuild to write cloudbuild logs
  "roles/storage.objectViewer" --needed to access intermediary bucket created by google cloud to hold source code. documentation link https://cloud.google.com/functions/docs/tutorials/terraform
• Terraform succeeded after this but I was seeing 403 permision errors in clound functions logs..while even invoking the cloud function from the pub/sub event trigger.
• It seems by default gcp uses {project}-compute@developer.gserviceaccount.com to call cloud function from pub/sub trigger since we didn't specifically mention stacklet-relay service account to do this.

Change # 2
So I specifically included stacklet-relay(or var.service_acount) in event trigger.
var.service_account has the roles/cloudfunctions.invoker for the cloud function already in terraform, so its the intended role to call the cloud function.
e.g.
event_trigger {
trigger_region = var.location
event_type = "google.cloud.pubsub.topic.v1.messagePublished"
pubsub_topic = google_pubsub_topic.asset_feed[0].id
retry_policy = "RETRY_POLICY_RETRY"
service_account_email = var.service_account --this line here is added
}

• After this, cloud function moved on and now has expected error related to assuming the aws iam role since I haven't formally onboarded dev or canary account for testing, but looking at the error it should work when i include proper trust in IAM role.

[sontek]

This might only make sense when we have create_project set and so we probably only want to do it when we are creating the project:

terraform-gcp-stacklet-relay/bootstrap/main.tf

Lines 6 to 15 in 90fd290

	resource "google_project" "stacklet_relay" {
	count = var.create_project ? 1 : 0
	name = var.project_name
	project_id = var.project_id
	folder_id = var.folder_id
	billing_account = var.billing_account
	tags = var.project_tags
	deletion_policy = "DELETE"
	}

Otherwise we should just expect the project_id they give us to have proper permissions set and we shouldn't try to modify it.

[hiteshmck]

@sontek If we don't want to use terraform to give their project compute sa any permissions, we should atleast have some documentation sayting this is the minimum permissions we expect on the google compute service account.

And if we are documenting this, why not automate, if we can.

Just some thoughts....

[sontek]

I wouldn't expect us to have access to modify IAM if we don't have access to compute. Most companies lock down IAM more than any other service.

We definitely should have documentation for the permissions necessary though. We shouldn't leave it up to the customer to guess what permissions they need.

But if they are passing in project_id its because they want us to use a project they created without modifications because its most likely controlled by IaC on their end and any changes we make to it will be reverted with the IaC that controls it

[hiteshmck]

Thx for the feedback.
For Epsilon, they are using their own project and still expect the terraform to work out of the box, by giving permission to the service accounts it needs in the terraform itself.

Maybe a middle ground be to add documentation about extra permissions, and at the same time, have a setting in terraform to control , if they want our terraform to give additional permissions as well for their project.

Does it make sense ?

[sontek]

I'm not a big fan of allowing a customer to pass in a project ID but then trying to modify that project after the fact. Most customers will not expect that behavior. Maybe if create_project is false we could use the datasource to verify the proper permissions are there?

Untested but something like:

data "google_project_iam_policy" "project" {
  project = var.project_id
}

output "check_if_role_exists" {
  value = contains([
    for binding in data.google_project_iam_policy.project.bindings :
    binding.role
  ], "roles/compute.admin")
}

with whatever roles are necessary? Although I think documentation attached to the project_id var is enough

[howbazaar]

Can we also run terraform fmt over the files please?

[hiteshmck]

Thx @sontek and @howbazaar , I incoroprated the comments. Please review.
I also updated docs to include section on permissions https://github.com/stacklet/docs/pull/470, please review as well.
Thx.