Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(modules/vpc-sc) Inconsistent conditional result types #2675

Closed
joelvoss opened this issue Nov 11, 2024 · 1 comment
Closed

(modules/vpc-sc) Inconsistent conditional result types #2675

joelvoss opened this issue Nov 11, 2024 · 1 comment

Comments

@joelvoss
Copy link
Contributor

joelvoss commented Nov 11, 2024

Describe the bug
When defining ingress/egress policies using the ingress_policies/egress_policies variable of the VPC-SC module and by using the factory (defining a policy by creating a data/ingress-policies/my-policy.yaml file), Terraform throws an "Inconsistent conditional result types" error if one policy defines the identities parameter and the other one the indentity_type parameter.

Environment

# terraform -version
Terraform v1.9.8
on darwin_arm64
# git rev-parse --short HEAD
b85711e8

To Reproduce
To reproduce the error, you can modify one of the examples from the VPC-SC readme.

  1. Prepare an access-levels and ingress-policies factory configuration like so:

data/access-levels/geo-it.yaml

conditions:
  - regions:
      - IT

data/ingress-policies/i2.yaml

from:
  access_levels:
    - geo-it
  identity_type: ANY_IDENTITY
to:
  operations:
    - service_name: "*"
  resources:
    - projects/1234567890
  1. Next, use the VPC-SC module like so:
module "repro" {
  source        = "./fabric/modules/vpc-sc"
  access_policy = "12345678"
  factories_config = {
    access_levels    = "data/access-levels"
    egress_policies  = "data/egress-policies"
    ingress_policies = "data/ingress-policies"
  }
  ingress_policies = {
    i1 = {
      from = {
        identities = [
          "serviceAccount:[email protected]",
          "serviceAccount:[email protected]"
        ]
        access_levels = ["*"]
      }
      to = {
        operations = [{ service_name = "*" }]
        resources = ["*"]
      }
    }
  }
  service_perimeters_regular = {
    default = {
      status = {
        access_levels       = ["geo-it"]
        resources           = ["projects/11111", "projects/111111"]
        restricted_services = ["storage.googleapis.com"]
        egress_policies     = []
        ingress_policies    = ["i1", "i2"]
        vpc_accessible_services = {
          allowed_services   = ["storage.googleapis.com"]
          enable_restriction = true
        }
      }
    }
  }
}

Expected behavior
No terraform errors should be thrown when running terraform plan or terraform apply.

Result

Error: Inconsistent conditional result types

  on fabric/modules/vpc-sc/service-perimeters-regular.tf line 217, in resource "google_access_context_manager_service_perimeter" "regular":
 217:         for_each = status.value.ingress_policies == null ? {} : {
 218:           for k in status.value.ingress_policies :
 219:           k => lookup(local.ingress_policies, k, null)
 220:           if contains(keys(local.ingress_policies), k)
 221:         }
    ├────────────────
    │ local.ingress_policies is object with 2 attributes
    │ status.value.ingress_policies is list of string with 2 elements

The false result value has the wrong type: attribute types must all match for
conversion to map.

Additional context
The error is caused by incorrect default values in the VPC-SC module when merging policies in modules/vpc-sc/factory.tf L52 and L72.
Since identities is of type list, the default value when merging should not be null but [] instead.
I will submit a PR with a potential fix and link it here.
PR: #2676

@ludoo
Copy link
Collaborator

ludoo commented Nov 12, 2024

closing this as your PR is now merged, thanks a lot for the debugging and sending in a fix

@ludoo ludoo closed this as completed Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants