Open Stack

Hello David,

The following RFE’s were created in order to address the same use case:

https://bugs.launchpad.net/neutron/+bug/1592000
https://bugs.launchpad.net/neutron/+bug/1592028 (blueprint https://review.openstack.org/#/c/391654)

IMO, These usability issues in the security-group API should be addressed regardless of what FWaaS v2.0 will be capable for.

Thanks,
Roey

On Oct 31, 2016, at 11:28 PM, David G. Bingham <dbingham at godaddy.com<mailto:dbingham at godaddy.com>> wrote:

Yo Neutron devs :-)

I was wondering if something like the following subject has come up:  "Cloud-provider Security Groups”.

*Goal of this email*: Gauge the community’s need and see if this has come up in past.
*Requirement*: Apply a provider-managed global set of network flows to all instances.
*Use Case*: For our private cloud, have need to dynamically allow network traffic flows from other internal network sources across all instances.
*Basic Idea*: Provide an *admin-only* accessible security group ruleset that would persist and apply these "cloud-provider" security group rules to all instances of a cloud. This *may* be in the form of new "provider" API or an extension to existing API only accessible via "admin". When instances are created, this global SG ruleset would be applied to each VM/ironic instance. This feature likely should be capable of being enabled/disabled depending on the provider's need.

*Real example*: Company security team wants to audit consistent security software installations (i.e. HIPS) across our entire fleet of servers for compliance reporting. Each vm/ironic instance is required to have this software installed and up to date. Security audit team actually audits each and every server to ensure it is running, patched and up to date. These auditing tools source from a narrow set of internal IPs/ports and each instance must allow access to these auditing tools.

--- What we do today to hack a "cloud-provider" flow in a private cloud ---
1) We've locked down the default rules (only admins can modify which makes effectively kills a lot of canned neutron tools).
2) We've written an external script that iterates over all projects in our private cloud (~10k projects)
3) For each project:
3a) Fetch default SGs for that project and do a comparison of its default rules against *target* default rules
3b) Create any new missing rules, delete any removed rules
3c) Next project
This process is cumbersome, takes 20+ hours to run (over ~10k projects) and has to be throttled such that it doesn't over-hammer neutron while its still serving production traffic.

--- What we'd like to do in future ---
1) Call Security Group API that would modify a "cloud-provider" ruleset.
2) When updated, agents on HVs detect the "cloud-provider" change and then apply the rules across all instances.
Naturally there are going to be a lot of technical hurdles to make this happen while a cloud is currently in-flight.

Other uses for “Provider SGs":
* We want to enable new shared features (i.e. monitoring aaS) that all our internal projects can take advantage of. When the monitoring team adds/modifies IPs to scale, we'd apply these cloud-provider rules on behalf of all projects in the private cloud without users having concern themselves about the monitoring team's changes.
* We want to allow access to some internal sites to our VPN users on specific ports. These VPN ranges are dynamically changed by the VPN team. Our teams should not need to go into individual projects to add a new rule when VPN team changes ranges.
* This list could go on and on and naturally makes much more sense in a *private cloud* scenario, but there may be cases for public providers.

I’d be happy to create a spec.

Seen this before? Thoughts? Good, Bad or Ugly? :-)

Thanks,
David Bingham (wwriverrat on irc)
GoDaddy
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161102/ec8a3ca3/attachment.html>