Add granular VPC Service-Control resource

[morgante]

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 the 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 the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

Currently, we have support for VPC Service Controls via the google_access_context_manager_service_perimeter. This work fairly well in small organizations but can be challenging in large ones where project definitions happen across many parts of the Terraform configuration: all those project IDs have to be separately collected and added into this one central resource.

It'd be great if we had a google_access_context_manager_service_perimeter_resource resource which acted similarly to our IAM member resources and allowed you to add a single project into an existing perimeter. This would allow us to do things like adding VPC-SC to project factory.

We'd also have to update the google_access_context_manager_service_perimeter to allow excluding the status.resources parameter.

New or Affected Resource(s)

• google_access_context_manager_service_perimeter
• google_access_context_manager_service_perimeter_resource

Potential Terraform Configuration

resource "google_access_context_manager_access_policy" "test-access" {
  parent = "organizations/123456789"
  title  = "my policy"
}

resource "google_access_context_manager_service_perimeter" "service-perimeter" {
  parent      = "accessPolicies/${google_access_context_manager_access_policy.test-access.name}"
  name        = "accessPolicies/${google_access_context_manager_access_policy.test-access.name}/servicePerimeters/restrict_all"
  title       = "restrict_all"
  status {
    restricted_services = ["storage.googleapis.com"]
  }
}

resource "google_access_context_manager_service_perimeter" "my-project" {
  perimeter = google_access_context_manager_service_perimeter.service-perimeter.name
  resource = "projects/my-protected-project"
}

[morgante]

@danawillow I'd be curious on your thoughts here. This could be a very useful enhancement for VPC-SC management.

[danawillow]

That makes sense to me. If you wouldn't mind filing it internally, I can put it in our Q4 planning.

[morgante]

@danawillow Done, thanks!

[calbach]

My team has a similar need which I think would likely already be covered by this ticket but wanted to include here explicitly. In our case, the perimeter projects are managed entirely outside of Terraform, but we still want to manage the other status fields with Terraform (e.g. restrictedServices).

Ideally we could specify:

resource "google_access_context_manager_service_perimeter" "service-perimeter" {
...
  status {
    resources           = []
    restricted_services = [ ... ]
    access_levels = [ ... ]
  }
  lifecycle {
    ignore_changes = [
      status["resources"]
    ]
  }

but when I last checked the only level of granularity supported for ignoring was status (which means we cannot apply changes to the other status subfields).

[danawillow]

@calbach I don't think having a fine-grained google_access_context_manager_service_perimeter_resource would solve that need, since the only extra behavior it would add is allowing an association between a project and a service perimeter.

Just to check, do either of these work?

ignore_changes = ["status.0.resources"]

ignore_changes = ["status.resources"]

[calbach]

🤦‍♂️ Thank you @danawillow ! Both of these work as desired:

ignore_changes =  [status[0].resources]

ignore_changes =  ["status[0].resources"]

Admittedly I don't understand why I'm indexing into an apparently non-repeated field, but I'll take it. I suspect this is what tripped me up when I last tried it.

[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 👉 hashibot-feedback@hashicorp.com. Thanks!