Terraform crashing when planning a google compute firewall resource based on module output that do not exists yet

[visheyra]

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

❯ terraform -v
Terraform v1.0.10
on darwin_amd64
+ provider registry.terraform.io/hashicorp/google v4.0.0
+ provider registry.terraform.io/hashicorp/google-beta v4.0.0
+ provider registry.terraform.io/hashicorp/template v2.2.0

Affected Resource(s)

• google_compute_firewall

Terraform Configuration Files

resource "google_compute_firewall" "firewall_prometheus_node" {
  name = "prometheus-node"
  network = google_compute_network.vpc_network.self_link

  # unrelevant part are discarded for clarity
  log_config {
    metadata = "INCLUDE_ALL_METADATA"
  }

  source_ranges = [ module.xxxxxx.satellite_ip ]
}

Debug Output

Panic Output

TestSimplePlan 2021-11-04T09:48:28Z logger.go:66: │ Error: 1 error occurred:
TestSimplePlan 2021-11-04T09:48:28Z logger.go:66: │ 	* one of source_tags, source_ranges, or source_service_accounts must be defined
TestSimplePlan 2021-11-04T09:48:28Z logger.go:66: │ 
TestSimplePlan 2021-11-04T09:48:28Z logger.go:66: │ 
TestSimplePlan 2021-11-04T09:48:28Z logger.go:66: │ 
TestSimplePlan 2021-11-04T09:48:28Z logger.go:66: │   with google_compute_firewall.firewall_prometheus_node,
TestSimplePlan 2021-11-04T09:48:28Z logger.go:66: │   on firewall.tf line 94, in resource "google_compute_firewall" "firewall_prometheus_node":
TestSimplePlan 2021-11-04T09:48:28Z logger.go:66: │   94: resource "google_compute_firewall" "firewall_prometheus_node" {

Expected Behavior

the resource should be planned correctly if the module has not been created yet indicating a "known after apply" value for the source_range

Actual Behavior

Terraform is crashing because he can't know the output of the module not created thus leading to all required argument of the resource google_compute_firewall not being set.

Steps to Reproduce

• create a module that output a IP range
• put that output in the source_ranges field of the google_compute_firewall resource
• run terrform plan

Important Factoids

Nope

References

N/A

[ScottSuarez]

Could you provide a complete minimum configuration so I can debug this scenario?

[michaelgobz]

Am facing the same problem the plan never proceeds it asks for
one of source_tags, source_ranges, or source_service_accounts must be defined
needs address @ScottSuarez

[harmeetsinghgujral]

Recently i am also seeing this issue earlier same set of terraform cmd for .tf file was executing.

resource "google_compute_firewall" "testlogs-test" {
name = "testlogs-automation-${random_string.globalrandom1.result}"
network = "${google_compute_network.testlogs-test-network.name}"

allow {
protocol = "tcp"
ports = ["90", "1100"]
}
}

@ScottSuarez could you please help

[hudson-m]

Had the same problem today, solved by adding source_tags = ["mynetwork"]

resource "google_compute_firewall" "mynetwork-allow-http-ssh-rdp-icmp" {
name = "mynetwork-allow-http-ssh-rdp-icmp"
network = google_compute_network.mynetwork.self_link
allow {
protocol = "tcp"
ports = ["22", "80", "3389"]
}
allow {
protocol = "icmp"
}
source_tags = ["mynetwork"]
}

Source: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_firewall

[dacorredor11]

@hudson-m Dude, adding source_tags = ["mynetwork"] solved the issue. Thank u so much!

[joshgong]

@hudson-m Thank you for the suggested fix. Our terraform plan is now running successfully. Does adding the source_tags = ["xxx"] have any effect on the firewall rule? I see in the official terraform docs https://registry.terraform.io/providers/hashicorp/google/3.90.0/docs/resources/compute_firewall#source_tags "The connection does not need to match both properties for the firewall to apply".

[mrkeyiano]

@hudson-m having the same issue using source "gruntwork-io/network/google//modules/vpc-network"

and i cant just add source_tag

[vankatamarinov]

I am facing the same issue, the code I`m using:

resource "google_compute_firewall" "some_name" {
name = "some-name"
network = "https://www.googleapis.com/compute/v1/projects/...."
allow {
protocol = "tcp"
ports = [
"443",
"80",
"2222"
]
}
source_ranges = [
"${google_compute_address.something-0.address}/32",
"${google_compute_address.something-1.address}/32",
]
target_tags = [
"1",
"2",
]
}

Using terraform-provider-google v4.1.0, the code was working properly with v3.90.0.

The error is

one of source_tags, source_ranges, or source_service_accounts must be defined

and it can be seen that I have source_ranges.

The workaround with adding source_tags is successful but I can not put it in live systems. I hope to be fixed soon.

[bharathkkb]

I was also able to repro this, below is an MCVE. Works fine with v3.90.1 but throws * one of source_tags, source_ranges, or source_service_accounts must be defined with v4.1.0.

locals {
  project_id = "YOUR_PROJECT_ID"
}

resource "google_compute_network" "vpc_network" {
  project                 = local.project_id
  name                    = "test-network"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet" {
  name          = "test-subnet"
  project       = local.project_id
  ip_cidr_range = "10.0.0.0/16"
  region        = "us-central1"
  network       = google_compute_network.vpc_network.id
}

resource "google_compute_address" "address" {
  name         = "test-address"
  project      = local.project_id
  subnetwork   = google_compute_subnetwork.subnet.id
  address_type = "INTERNAL"
  region       = "us-central1"
}

resource "google_compute_firewall" "fw" {
  name      = "test-fw"
  project   = local.project_id
  network   = google_compute_network.vpc_network.id
  direction = "INGRESS"

  source_ranges = ["${google_compute_address.address.address}/32"]
  target_tags   = ["foo"]

  allow {
    protocol = "tcp"
  }
}

[jackwhelpton]

I was wondering if I could help out here, as this is blocking use of the provider in several other modules. I've just been trying to get the existing tests to run, as I was thinking adding something that shows the problem would be a good first start. However, I'm seeing this error:

cannot run Terraform provider tests: unexpected error: openpgp: signature made by unknown entity

Am I missing something, configuration-wise?

Update: aha. I'm running the tests within WSL, so I need to have Terraform installed there. That gets me over this error.

[jackwhelpton]

Some progress: I have a test in place now on my own branch that demonstrates the problem. As suspected, the problematic logic is here:

https://github.com/hashicorp/terraform-provider-google/blob/master/google/resource_compute_firewall.go#L91

If we add the same rangesExist check as we do for tags and sas, the test succeeds. This isn't going to be the correct fix, though, if I understand things correctly: that will return true if the field is populated via interpolation (good, we want that to pass) or computation (bad, because the existing permissive default will then be accepted).

I'm wading through resource_diff.go to see if there's an approach that could distinguish between these two scenarios, but I'm new to this so it's slow work.

Update: perhaps adding this suffices? If I do that and comment out the source_ranges property in the test, I do still get a failure. I'll create a PR for this so I can see how it stands up to the CI process, any thoughts welcome. That PR is here: #10668

[bharathkkb]

@jackwhelpton @slevenick Does GoogleCloudPlatform/magic-modules#5526 fix this? Wasnt sure from the PR description on GoogleCloudPlatform/magic-modules#5526

[jackwhelpton]

@bharathkkb : this looks an upstream/magic modules version of the fix I proposed. As @slevenick notes on that PR, whilst it does appear to address the issue, it has its own problems: it won't throw an error if source_ranges is initially present, but later removed.

I'm not clear if there's a better approach, though... that's a little above my current grasp of the provider code. I was hoping somebody else would volunteer a possible solution to that problem.

[vankatamarinov]

I hope that we will have a fix soon.

[slevenick]

Should be fixed via GoogleCloudPlatform/magic-modules#5526

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.