Open Stack

On 31 October 2016 at 22:28, David G. Bingham <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? :-)
>

I think this has come up before [1]. The use case is legitimate, but there
is a couple of ways in which this can be accomplished. As pointed out by
others, FWaaS is the solution we suggested to address this particular need.

[1] https://bugs.launchpad.net/neutron/+bug/1592000


>
> Thanks,
> David Bingham (wwriverrat on irc)
> GoDaddy
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 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/20161101/d09eefca/attachment.html>