[RFE]Role-based access control for neutron fwaas policies

[zhaobo]

[Existing problem]
Now, fwaas just contain the 'shared' field, when it is True, it can be fetched by all tenants. But there is more requirements now, the enterprise who have the strong fw(more legitimate fw-rules/policies) want to share / sell its fw service to some tenants through our cloud system.

[Proposal]
Now neutron can not fulfill this task until import rbac policies in L release. I think we could base on the existing rbac policies mechanism to extend more resources which may have this application scene. We could control the fw shared like existing network shared or maybe more cover.

[What is the enhancement?]
Share FW more sophisticated to other specified tenants

[Mickey Spiegel (emspiege)]

I fail to see the importance of this request, for two reasons:
1) FWaaS 1.0 API is experimental and is going to be replaced by the FWaaS 2.0 API. New features should be targeted at FWaaS 2.0. See the FWaaS 2.0 API spec.
2) The FWaaS 1.0 API has a "shared" attribute on firewall rules and firewall policies. I also see the "shared" attribute on the firewall, but that makes no sense to me and glancing at the code it does not seem like "shared" is populated in the firewall table. For firewall rules and firewall policies, "shared" allows a policy or a rule to be reused in a different tenant's firewall. The actual instantiation and enforcement is always in the context of the firewall's tenant, regardless of the firewall policy's tenant and the firewall rule's tenant, i.e. the contents of the firewall policy will be replicated for each tenant due to separate firewalls per tenant. This is different from network RBAC, where one tenant can actually connect to another tenant's network.

[Armando Migliaccio (armando-migliaccio)]

fwaas v2 [1] has a concept of public attribute that is being used to share firewall policies etc. I believe RBAC was taken into account but dismissed for lack of strong use cases that justified the extra layer of complexity. For this reason, we'll have to reject this for now and reassess later on, when we have some fwaas concrete to chew on.

[1] https://blueprints.launchpad.net/neutron/+spec/fwaas-api-2.0