On 31 October 2016 at 22:28, David G. Bingham <dbing...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev