On 03/03/16 23:12, Jonathan Proulx wrote:
To go a little further down my wish list I'd really like to do be able
to offer a standard selection of security groups for my site no tjust
'default', but that may be a bit off this topic. Briefly my
motivation is that 'internal' here includes a number
On 2016-03-03 09:35:54 -0500 (-0500), sridhar basam wrote:
[...]
> As other have said elsewhere in this thread, you already have the
> ability to not use the firewall driver in neutron.
I'm still struggling to find documentation on how a tenant^Wproject
can disable the firewall driver in Neutron w
Mathieu Gagné wrote:
> We had issue with GRE but unrelated to the one mentioned above.
>
> Although security group is configured to allow GRE,
> nf_conntrack_proto_gre module is not loaded by iptables/Neutron and
> traffic is dropped. We had to load the module manually.
>
Let's put together a bu
On 2016-03-03 12:53 PM, Sean M. Collins wrote:
> sridhar basam wrote:
>> This doesn't sound like a neutron issue but an issue with how the
>> conntrack module for GRE changed in the kernel in 3.18.
>>
>>
>> http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/47705
>>
>> Sri
>
sridhar basam wrote:
> This doesn't sound like a neutron issue but an issue with how the
> conntrack module for GRE changed in the kernel in 3.18.
>
>
> http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/47705
>
> Sri
Oooh! Wicked nice find. Thanks Sri!
--
Sean M. Colli
Hi Jon,
As part of our FWaaS V2 efforts [1] we have been rethinking FWaaS and Security
Groups. The idea is that eventually to augment Security Groups with some richer
functionality and provide a default FWaaS policy to add to the (vm) port.
Furthermore there is a way to “share” Firewall rules w
On Wed, Mar 02, 2016 at 02:05:40PM -0600, Monty Taylor wrote:
:(try writing an idempotent ansible playbook that tries to make your
:security group look exactly like you want it not knowing in advance
:what security group rules this provider happens to want to give you
:that you didn't think to exp
On Wed, Mar 02, 2016 at 11:36:17AM -0800, Gregory Haynes wrote:
:Clearly, some operators and users disagree with the opinion that 'by
:default security groups should closed off' given that we have several
:large public providers who have changed these defaults (despite there
:being no documented wa
On Wed, Mar 02, 2016 at 10:19:50PM +, James Denton wrote:
:My opinion is that the current stance of ‘deny all’ is probably the safest bet
for all parties (including users) at this point. It’s been that way for years
now, and is a substantial change that may result in little benefit. After all
On Wed, Mar 2, 2016 at 1:46 PM, Clark Boylan wrote:
> On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote:
> > Kevin Benton wrote:
> > > * Neutron cannot be trusted to do what it says it's doing with the
> security
> > > groups API so users want to orchestrate firewalls directly on their
> >
Salvatore Orlando wrote:
On 3 March 2016 at 10:38, Ihar Hrachyshka wrote:
Kevin Benton wrote:
Hi,
I know this has come up in the past, but some folks in the infra channel
brought up the topic of changing the default security groups to allow all
traffic.
They had a few reasons for th
On 3 March 2016 at 10:38, Ihar Hrachyshka wrote:
> Kevin Benton wrote:
>
> Hi,
>>
>> I know this has come up in the past, but some folks in the infra channel
>> brought up the topic of changing the default security groups to allow all
>> traffic.
>>
>> They had a few reasons for this that I will
Kevin Benton wrote:
* Neutron cannot be trusted to do what it says it's doing with the
security groups API so users want to orchestrate firewalls directly on
their instances.
If that’s really a reason for someone, then they should just use ’noop'
firewall_driver. Or port_security port
Kevin Benton wrote:
Hi,
I know this has come up in the past, but some folks in the infra channel
brought up the topic of changing the default security groups to allow all
traffic.
They had a few reasons for this that I will try to summarize here:
* Ports 'just work' out of the box so the
On 03/02/2016 02:46 PM, Mike Spreitzer wrote:
Kevin Benton wrote on 03/02/2016 01:27:27 PM:
> Does it at least also include the UUID, or is there no way to tell
> from 'nova show'?
No direct way to tell, as far as I can see.
Yep. Best I can find is:
neutron port-list -- --device_id
then
Kevin Benton wrote on 03/02/2016 01:27:27 PM:
> Does it at least also include the UUID, or is there no way to tell
> from 'nova show'?
No direct way to tell, as far as I can see.
__
OpenStack Development Mailing List (not
hanks,
Kevin
From: Jeremy Stanley [fu...@yuggoth.org]
Sent: Wednesday, March 02, 2016 1:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] - Changing the Neutron default security
group rules
On 20
My opinion is that the current stance of ‘deny all’ is probably the safest bet
for all parties (including users) at this point. It’s been that way for years
now, and is a substantial change that may result in little benefit. After all,
you’re probably looking at most users removing the default r
On 2016-03-02 21:25:25 + (+), Sean M. Collins wrote:
> Jeremy Stanley wrote:
> > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote:
> > [...]
> > > In my mind, the default security group is there so that as people
> > > are developing their security policy they can at least start with
>
Clark Boylan wrote:
> On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote:
> > Kevin Benton wrote:
> > > * Neutron cannot be trusted to do what it says it's doing with the
> > > security
> > > groups API so users want to orchestrate firewalls directly on their
> > > instances.
> >
> > This on
Jeremy Stanley wrote:
> On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote:
> [...]
> > In my mind, the default security group is there so that as people
> > are developing their security policy they can at least start with
> > a default that offers a small amount of protection.
>
> Well, not a
On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote:
[...]
> In my mind, the default security group is there so that as people
> are developing their security policy they can at least start with
> a default that offers a small amount of protection.
Well, not a small amount of protection. The ins
On 03/02/2016 01:53 PM, Andrew Laski wrote:
On Wed, Mar 2, 2016, at 02:36 PM, Gregory Haynes wrote:
Clearly, some operators and users disagree with the opinion that 'by
default security groups should closed off' given that we have several
large public providers who have changed these defaults (d
On 03/02/2016 01:04 PM, Xav Paice wrote:
On 3 March 2016 at 07:52, Sean Dague mailto:s...@dague.net>> wrote:
On 03/02/2016 01:46 PM, Armando M. wrote:
> IMO, I think that's a loophole that should be closed. We should all
> strive to make OpenStack clouds behave alike.
>
On Wed, Mar 2, 2016, at 02:36 PM, Gregory Haynes wrote:
> Clearly, some operators and users disagree with the opinion that 'by
> default security groups should closed off' given that we have several
> large public providers who have changed these defaults (despite there
> being no documented way
Clearly, some operators and users disagree with the opinion that 'by
default security groups should closed off' given that we have several
large public providers who have changed these defaults (despite there
being no documented way to do so), and we have users in this thread
expressing that opinio
On 3 March 2016 at 07:52, Sean Dague wrote:
> On 03/02/2016 01:46 PM, Armando M. wrote:
>
> > IMO, I think that's a loophole that should be closed. We should all
> > strive to make OpenStack clouds behave alike.
>
> It might be a loophole. But it's also data. People are doing that thing
> for a
No, there haven't been vulnerabilities where the rules you expressed in the
API were not rendered as requested (unless there was a denial of service in
which case the whole dataplane would fail to wire). The issues were people
being able to escape their own anti-spoofing filtering so they could do
On 03/02/2016 01:46 PM, Armando M. wrote:
> IMO, I think that's a loophole that should be closed. We should all
> strive to make OpenStack clouds behave alike.
It might be a loophole. But it's also data. People are doing that thing
for a reason based on customer feedback. If the general norms are
>From one operator's standpoint, some comments below.
I can't imagine having to tell my customer base that we've just changed the
'default' security group from not allowing anything inbound, to allowing
everything. That would mean they would all have to strip the default group
from all their inst
On 1 March 2016 at 14:52, Kevin Benton wrote:
> Hi,
>
> I know this has come up in the past, but some folks in the infra channel
> brought up the topic of changing the default security groups to allow all
> traffic.
>
> They had a few reasons for this that I will try to summarize here:
> * Ports
Hi,
I understand that it's more user-friendly to enable by default all traffic
to VMs,
but it seems clearly unsecure to enable by default all traffic to VMs
(including ssh from internet!!!),
as it increases the VM exposition surface on internet and reduces its
security.
Cédric/ZZelle
On Tue
On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote:
> Kevin Benton wrote:
> > * Neutron cannot be trusted to do what it says it's doing with the security
> > groups API so users want to orchestrate firewalls directly on their
> > instances.
>
> This one really rubs me the wrong way. Can we pl
"Sean M. Collins" wrote on 03/02/2016 01:16:52 PM:
> Meaning your users are creating new security groups and naming them
> "default" - so you have the "default" default (heh) and then the one
> that they created named default?
>
> Are security group names in Nova-Net unqiue? I seem to recall tha
Does it at least also include the UUID, or is there no way to tell from
'nova show'?
On Wed, Mar 2, 2016 at 10:01 AM, Mike Spreitzer wrote:
> "Sean M. Collins" wrote on 03/02/2016 12:38:29 PM:
>
> > I think that the default security group should be left as is - and users
> > should be trained t
Mike Spreitzer wrote:
> Could we at least make it less difficult to figure out which security
> group is attached to a Nova instance? Right now `nova show` says only
> that the security group is named "default" and guess what --- they are
> *all* named default! An admin looking at this is lost
"Sean M. Collins" wrote on 03/02/2016 12:38:29 PM:
> I think that the default security group should be left as is - and users
> should be trained that they should bring/create security groups with the
> appropriate rules for their need.
Could we at least make it less difficult to figure out whic
Kevin Benton wrote:
> * Instances without ingress are useless so a bunch of API calls are
> required to make them useful.
This is not true in all cases. There are plenty of workloads that only
require outbound connectivity. Workloads where data is fetched,
computed, then transmitted elsewhere for
Yeah, the only thing this will due will change the default rules that are
generated for a user's default security group. They will still be visible
via the normal security groups API and users will be able to modify them.
On Mar 2, 2016 08:22, "Dean Troyer" wrote:
> On Wed, Mar 2, 2016 at 10:10 A
On Wed, Mar 2, 2016 at 10:10 AM, Fawad Khaliq wrote:
> Neutron security groups APIs should already allow discovery of what
> default gets created. This should work or are you suggesting something
> else?
>
So the default here for an allow all would be to include a single rule to
do that? That's
On Wed, Mar 2, 2016 at 7:52 AM, Dean Troyer wrote:
> On Tue, Mar 1, 2016 at 4:52 PM, Kevin Benton wrote:
>
>> Second, would it be acceptable to make this operator configurable? This
>> would mean users could receive different default filtering as they moved
>> between clouds.
>>
>
> If you must
On Tue, Mar 1, 2016 at 4:52 PM, Kevin Benton wrote:
> Second, would it be acceptable to make this operator configurable? This
> would mean users could receive different default filtering as they moved
> between clouds.
>
If you must do this, please make it discoverable by the user/instance via
a
Thanks for brining this up.
On Tue, Mar 1, 2016 at 2:52 PM, Kevin Benton wrote:
> Hi,
>
> I know this has come up in the past, but some folks in the infra channel
> brought up the topic of changing the default security groups to allow all
> traffic.
>
> They had a few reasons for this that I wil
Hi,
I know this has come up in the past, but some folks in the infra channel
brought up the topic of changing the default security groups to allow all
traffic.
They had a few reasons for this that I will try to summarize here:
* Ports 'just work' out of the box so there is no troubleshooting to
e
44 matches
Mail list logo