Splitting nsxt_policy_security_policy and security_rule in two disctincs resources

[HSoulat]

Is your feature request related to a problem? Please describe.

Current resource structure is not flexible to iterate on firewall rule in a specific security policy.

Current configuration is :

resource "nsxt_policy_security_policy" "policy1" {
  display_name = "policy1"
  description  = "Terraform provisioned Security Policy"
  category     = "Application"
  locked       = false
  stateful     = true
  tcp_strict   = false
  scope        = [nsxt_policy_group.pets.path]

  rule {
    display_name       = "block_icmp"
    destination_groups = [nsxt_policy_group.cats.path, nsxt_policy_group.dogs.path]
    action             = "DROP"
    services           = [nsxt_policy_service.icmp.path]
    logged             = true
  }
}

Describe the solution you'd like

A dedicated firewall_rule resource could permit us to use Terraform Meta-argument for_each or count.

Possible configuration :

resource "nsxt_policy_security_policy" "policy1" {
  display_name = "policy1"
  description  = "Terraform provisioned Security Policy"
  category     = "Application"
  locked       = false
  stateful     = true
  tcp_strict   = false
  scope        = [nsxt_policy_group.pets.path]
}

resource "nsxt_policy_security_rule" "rule1" {
    **security_policy = nsxt_policy_security_policy.policy1.id**
    display_name       = "block_icmp"
    destination_groups = [nsxt_policy_group.cats.path, nsxt_policy_group.dogs.path]
    action             = "DROP"
    services           = [nsxt_policy_service.icmp.path]
    logged             = true
}

Describe alternatives you've considered

Dynamic object can be used to achieve dynamic rule creation. However, passing argument to such module cloud be tricky and need to use experimental terraform feature.

Additional context

No response

[salv-orlando]

Thanks for reporting this enhancement proposal @HSoulat
We will first need to analyze the feasibility as the provider also needs to support scenarios where a security policy is updated with all its rules.

In addition, while I agree it would make it simpler to iterate over firewall rules, I would also like to consider the compatibility impact as existing tf configs will need to be changed to specify rules as independent resource (at first glance I'm not sure how easy it would be have rules used either as attributes of a policy or first-class resources)

[MartiniMoe]

I'd also like to have seperate resources or some other solution. With the current solution diffs generated by terraform plan are basically unreadable when you add another rule to a policy that already contains several rules.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[HSoulat]

still relevant