Reusable firewall rules

[Charles Bitter]

At Comcast we provide a very large private cloud. Each tenant uses firewall rules to filter traffic in order to accept traffic only from a given list of IPs. This can be done with security groups. However there are two shortcomings with that approach.

First, in my environment the list of IPs on which to manage ingress rules is very large due to non-contiguous IP space, so educating all tenants what these IP addresses are problematic at best.

Second, notifying all tenants when IPs change is not a sustainable model.

We would like to find a solution whereby rules much like security groups (that is, filtering by a combination of IP, protocol, and port) can be defined and tenants can apply these rules to a given port or network. This would allow an admin to define these rules to encompass different IP spaces and the tenants could apply them to their VM or network as they see fit.

We would like to model the authorization of these rules so one role (such as admin) could create update or remove. And then the rule could be shared with a Tenant or all Tenants to consume.

Use Cases:

- As a tenant, I have a heavy CPU workload for a large report. I want to spin up 40 instances and apply the "Reporting Infrastructure" rule to them. This and would allow access only to the internal reporting infrastructure.

- As a network admin, when the reporting team needs more IP space,and I want to add more subnets So I want to update the "Reporting Infrastructure" rule so that any VM that is already using that rule can access the new IP space.

[Manjeet Singh Bhatia (manjeet-s-bhatia)]

You idea is share to share a security-group created by a tenant with all other tenants so that they can choose among existing group and all those rule in group would be applied for all instances of that tenant ?

[Armando Migliaccio (armando-migliaccio)]

Could [1] extended to security groups be fit for your purpose? A simpler solution would be allow admin-owned security groups to be visible to tenants, but what's tricky here is overlapping IP support, but at the same time they should not be allowed to be edited.

[1] http://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html

To be discussed at the drivers meeting.

[Charles Bitter (cbitter78)]

@manjeet-s-bhatia, Yes a admin defined Security Groups that tenants could use would do the trick. I am not married to security-group as the implementation.

@armando-migliaccio, Yes RBA for Security Groups would be a very nice way to implement. In my use case I would restrict defining the Security Group to the admin role and read to the tenants. I am sure others would find other use cases that could be leveraged by this model . +1

[Nate Johnston (nate-johnston)]

Determined that the requirements for this request are a duplicate of the FWaaS API v2.0 spec: https://review.openstack.org/#/c/243873