Creation of PSC Service Attachment Failing for Secure Web Proxy

[smartyr73]

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 a user, that user is claiming responsibility for the issue.
• Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Terraform Version & Provider Version(s)

Terraform v1.11.3
on darwin_arm64

• provider registry.terraform.io/hashicorp/google v6.27.0
• provider registry.terraform.io/hashicorp/google-beta v6.27.0
• provider registry.terraform.io/hashicorp/random v3.7.1

Affected Resource(s)

google_compute_service_attachment

Terraform Configuration

Terraform Configuration

data "google_compute_subnetwork" "psc_subnet" {
  name    = "xxxxxxxxx
  region  = "europe-west2"
  project = "xxxxxxxxxxxxx"
}

resource "google_compute_service_attachment" "this" {

  provider    = google
  name        = "swp-service-attachment"
  region      = "europe-west2"
  description = "PSC Service Attachment for SWP"
  enable_proxy_protocol = true
  connection_preference = "ACCEPT_AUTOMATIC"
  nat_subnets           = [data.google_compute_subnetwork.psc_subnet.id]
  target_service        = "xxxxxxxxx"
}

Debug Output

https://gist.github.com/smartyr73/4325d9a33871f5aa6a9b70c99d785e8c

Expected Behavior

Resource should be successfully created on running terraform apply based on the following plan:

Terraform will perform the following actions:

  # google_compute_service_attachment.psc_swp_service_attachment will be created
  + resource "google_compute_service_attachment" "psc_swp_service_attachment" {
      + connected_endpoints         = (known after apply)
      + connection_preference       = "ACCEPT_AUTOMATIC"
      + description                 = "PSC Service Attachment for SWP"
      + enable_proxy_protocol       = true
      + fingerprint                 = (known after apply)
      + id                          = (known after apply)
      + name                        = "swp-service-attachment"
      + nat_subnets                 = [
          + "projects/<PROJECT_NAME>regions/europe-west2/subnetworks/<SUBNET_NAME>",
        ]
      + project                     = "<PROJECT_NAME>"
      + propagated_connection_limit = (known after apply)
      + reconcile_connections       = (known after apply)
      + region                      = "europe-west2"
      + self_link                   = (known after apply)
      + target_service              = "<TARGET_SERVICE>"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Actual Behavior

Terraform crashes on attempting to run terraform apply

Steps to reproduce

1. Generate a successful terraform plan to create a PSC service attachment point to a secure web proxy as per the above terraform configuration and listed in the expected behaviour
2. Run a terraform apply based on the above plan

Important Factoids

1. Identical behaviour is observed with both the main and the beta provider.
2. This is to create a PSC service attachment for an existing secure web proxy

References

No response

b/408197802

[ggtisc]

Hi @smartyr73

After testing the google_compute_service_attachment resource based on your code, the below example was created (which is based on the basic terraform registry example (link here)), everything works as expected without bugs. I suggest you check the Google Cloud documentation (link here) and terraform registry documentation (link here) to compare your code.

data "google_project" "project" {}

resource "google_compute_network" "vpc_22169" {
  name                    = "vpc-22169"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet_22169_a" {
  name          = "subnet-22169-a"
  ip_cidr_range = "10.0.0.0/16"
  network       = google_compute_network.vpc_22169.id
  region        = "us-central1"
}

resource "google_compute_subnetwork" "psc_subnet_22169" {
  name          = "subnet-22169"
  ip_cidr_range = "10.1.0.0/16"
  network       = google_compute_network.vpc_22169.id
  region        = "us-central1"
  purpose       =  "PRIVATE_SERVICE_CONNECT"
}

resource "google_compute_health_check" "health_check_22169" {
  name                = "health-check-22169"
  check_interval_sec  = 1
  timeout_sec         = 1

  tcp_health_check {
    port = "80"
  }
}

resource "google_compute_region_backend_service" "backend_service_22169" {
  name          = "backend-service-22169"
  region        = "us-central1"
  health_checks = [google_compute_health_check.health_check_22169.id]
}

resource "google_compute_forwarding_rule" "producer_forwarding_rule_22169" {
  name                  = "forwarding-rule-22169"
  region                = "us-central1"
  load_balancing_scheme = "INTERNAL"
  backend_service       = google_compute_region_backend_service.backend_service_22169.id
  all_ports             = true
  network               = google_compute_network.vpc_22169.name
  subnetwork            = google_compute_subnetwork.subnet_22169_a.name
}

resource "google_compute_service_attachment" "service_attachment_22169" {
  provider              = google
  name                  = "service-attachment-22169"
  region                = "us-central1"
  description           = "something"
  enable_proxy_protocol = true
  connection_preference = "ACCEPT_AUTOMATIC"
  nat_subnets           = [google_compute_subnetwork.psc_subnet_22169.id]
  target_service        = google_compute_forwarding_rule.producer_forwarding_rule_22169.id
}

resource "google_compute_address" "compute_address_22169" {
  name          = "compute-address-22169"
  region        = "us-central1"
  subnetwork    = "default"
  address_type  = "INTERNAL"
}

resource "google_compute_forwarding_rule" "consumer_forwarding_rule_22169" {
  name                  = "consumer-forwarding-rule-22169"
  region                = "us-central1"
  target                = google_compute_service_attachment.service_attachment_22169.id
  load_balancing_scheme = "" # need to override EXTERNAL default when target is a service attachment
  network               = "default"
  ip_address            = google_compute_address.compute_address_22169.id
}

If after this you continue with issues please share with us your full code to see what is happening, or specify which values need to be changed.

IMPORTANT: It is important to share your logs and/or error message to identify the mistakes or bugs you are having

[smartyr73]

Hi @ ggtisc,

Thanks for the prompt response - greatly appreciated. I've been doing some further testing and I think I've found the root cause, but I need to do some more testing to validate this. I believe this error is occurring when I used a malformed value for the target service. I'll run more tests this week to validate this. It might be a case of looking at what input validation is being used for the target service value, which is causing it to crash.

One thing to note though is that this scenario also needs to be tested with a different target service (In this case the secure web proxy (SWP), with a malformed reference.

The main challenge I had is one around documentation. There isn't really any good documentation on which form the target service should take for the secure web proxy with PSC. The terraform registry example doesn't give any examples of using SWP as a target service. The only references I found were the issue and PR where it is referenced, and one generic boilerplate reference in the google docs, which uses gcloud commands.

#18710
GoogleCloudPlatform/terraform-google-conversion#3219
https://cloud.google.com/secure-web-proxy/docs/deploy-service-attachment#deploy-service-attachment

[ggtisc]

Sounds reasonable @smartyr73 I'm going to forward this issue as a request for a documentation enhancement, and if you found something please contact us again referencing this issue