provider/openstack: Decouple Security Group Rules from Security Groups

[vlerenc]

Issue #539 was actually about the same subject (two security groups need to refer to each other). It was even more general ("this probably applies to other platforms"), but the issue was closed when a solution for AWS was implemented. However, other platforms/providers still have the problem, most notably OpenStack where security group rules are no top-level resources yet.

[jtopjian]

@vlerenc Do you have a configuration off-hand that can easily produce this issue?

[vlerenc]

Just define two security groups and let them refer to each other. The cycle will be detected and Terraform will abort.

The way this problem is resolved in the AWS provider is to decouple security groups from the actual security rules (that refer to the security groups). I.e. the two groups can be/are created first (no cycle/no problem), then the rules are created (that refer to the groups; again no cycle/no problem for their creation).

[jtopjian]

Just define two security groups and let them refer to each other. The cycle will be detected and Terraform will abort.

Yup, easy enough. I was just being lazy and wondering if you had something readily available. I've created a generic configuration below for reference:

resource "openstack_compute_secgroup_v2" "test_group_1" {
  name = "test_group_1"
  description = "first test security group"
  rule {
    from_port = 2203
    to_port = 2203
    ip_protocol = "tcp"
    from_group_id = "${openstack_compute_secgroup_v2.test_group_2.id}"
  }
}

resource "openstack_compute_secgroup_v2" "test_group_2" {
  name = "test_group_2"
  description = "second test security group"
  rule {
    from_port = 2204
    to_port = 2204
    ip_protocol = "tcp"
    from_group_id = "${openstack_compute_secgroup_v2.test_group_1.id}"
  }
}                                                                     

[ghost]

I need this badly.

In a cluster that is entirely spun from a single terraform apply, it is not today possible to allow "admin complex" security group from the "compute complex" security group (unless perhaps they are in separate private subnets). I think the root of the issue could be that openstack_compute_secgroup_v2 doesn't export "id". See: https://www.terraform.io/docs/providers/openstack/r/compute_secgroup_v2.html ("Attributes Reference").

It would also be great to decouple the rule stanzas from the group itself.

As an aside, how-to configure Egress rules for Openstack security groups is unclear.

[jtopjian]

The Nova API for security groups doesn't support Ingres/Egress, however, the Neutron API does.

It looks like support for Neutron-based security groups is in Gophercloud and only need Terraform resources created. Given Gophercloud already has Groups and Rules decoupled, it makes sense to start there and either leave the Nova implementation as-is or work on it later on.

If anyone wanted to start on the openstack_networking_security_group_v2 and openstack_networking_security_rules_v2 resources, go for it -- I'd be happy to review 😄

[jtopjian]

#6410 was just merged that provides Neutron security groups and rules as two separate resources.

The Nova API-based security groups will continue to have rules and groups coupled. I think there would be significant work to decouple them.

I'm going to consider this closed, but anyone is free to re-open if they feel other wise.

[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 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.