Re: [openstack-dev] [lbaas][octavia] Security/networking questions

2016-02-09 Thread Eichberger, German 
All,

Some more color on (3) our plan was to allow for multiple management nets (and 
I was advocating strongly for that) but that somehow got lost in the 
implementation. 

For (2) we are still working on our operator API which will include that 
functionality once we get there :-)

German



On 2/8/16, 2:17 PM, "Brandon Logan"  wrote:

>Adding my own input:
>
>1. You should be able to add a specific role that the service accounts
>octavia will have.  Then that role can be added to neutron and nova's
>policy.json.  I have not tested this out but that is just a quick off
>the top of my head solution.
>
>2. What johnsom said.  Not ideal for large deployments but for large
>deployers, custom tooling would probably be written for that.
>
>3. Right now in devstack, the mgmt net is a single tenant network owned
>by the octavia service account.  This means that a lot of deployments
>would be limited to ~250 ports on that network (at least from our own
>experience and other's we have talked to).  Deployers can also specify
>that the mgmt network is a provider network which may not have that port
>restriction.
>
>Alternatively, we could create a mgmt net for each load balancer or each
>tenant.  I feel like this would have scaling issues but I haven't
>thought about it enough honestly.  Oh, one reason would be because,
>right now, all controllers would have to be connected to all the mgmt
>nets.  We've actually talked about how to solve this internally, but it
>was more just impromptu whiteboarding sessions.
>
>Thanks,
>Brandon
>
>On Mon, 2016-02-08 at 12:34 -0800, Michael Johnson wrote:
>> 1. Octavia can run under it's own account with the required roles
>> added to that account.
>> 2. Currently the process would be to update the amphora image in
>> glance and trigger a failover of the amphora.
>> 3. It is required.  It is a private network between the Octavia
>> controller and the amphora.  We would like to put the haproxy instance
>> in it's own namespace be we are not there yet.
>> 
>> Michael
>> 
>> On Mon, Feb 8, 2016 at 7:55 AM, Major Hayden  wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA256
>> >
>> > Hey there,
>> >
>> > I've been doing some work to research how best to implement LBaaSv2 and 
>> > Octavia within the OpenStack-Ansible project.  During that research, I've 
>> > come up with a few questions.
>> >
>> > 1) Is it possible for octavia to operate without providing it with admin 
>> > credentials?
>> >
>> > 2) If a user has amphora LB's deployed and a serious vulnerability is 
>> > released for OpenSSL/haproxy, what should the user do to patch those load 
>> > balancers?
>> >
>> > 3) Is a load balancer management network required?  Putting a LB onto an 
>> > admin tenant network as well as a customer tenant network is challenging 
>> > and bridging those networks could allow an attacker to gain access to 
>> > other things on that admin tenant network.
>> >
>> > Thanks in advance for your time.
>> >
>> > - --
>> > Major Hayden
>> > -BEGIN PGP SIGNATURE-
>> > Version: GnuPG v2
>> >
>> > iQIcBAEBCAAGBQJWuLpuAAoJEHNwUeDBAR+xSF8P/j/KBH2320xB/dGWmy6xOMuJ
>> > DRQCcpEEljIu3O4pU8sF6yGEZX/CIoI3WXGaOBR2g0phWxEus5lhy0DdkPw4ctAa
>> > +UJ7da/s0C7fDbbl09TvWDe3eBoohIunLOm6ABpMT48YipfM0zJLLDEy9kQpDcFg
>> > qg68S5xgtC9zP9CeK1Gvsq5EwjwyX6Mt0a3+G1NMFbUoARLpDDof06YHrNFw73Td
>> > 25AxqToR09yRRXsJfadrjjP9/lGWNBF5f5Oh5WoPnEAiThqN08Ico3geHKIr9s2r
>> > Ift5NueWovCI5MUzOzqwsazKgnVgQXrgaaQwRotl5WdZbstUfWJLO+2If5/z4z8d
>> > AArWLXwsCgIv+I6ZyJ4R3YzJVP3KBY8+8gDswjdMV4Jfy7YV9aragy96ofCEwjuH
>> > p6QOGAKJZASD3cQpOdqVqQt4BaWBXMqm70sNDjfzKRBwweuOZgpNRInluDMbhngs
>> > Yqdj2LGUhuij50gQLa21cYJ5pcuA6yY7KNoiiPLkNbFDJtQo6cjVt/McVFPxN3mu
>> > RKRXpZNBgzf5UAKtrMIyPbw1wioAhbt7lgevfvCOLxHCmu0VxsLzRmOdiON5Exmg
>> > vopL518GJSUx93GhA0cwnqT/ilcTvDxFxPXQrvQK/XPtEQq4U3wBF/kZALK1/4tu
>> > 7hi/GjugHBcixIZGE5sI
>> > =XI9V
>> > -END PGP SIGNATURE-
>> >
>> > __
>> > 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
>
>__
>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] [lbaas][octavia] Security/networking questions

2016-02-08 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey there,

I've been doing some work to research how best to implement LBaaSv2 and Octavia 
within the OpenStack-Ansible project.  During that research, I've come up with 
a few questions.

1) Is it possible for octavia to operate without providing it with admin 
credentials?

2) If a user has amphora LB's deployed and a serious vulnerability is released 
for OpenSSL/haproxy, what should the user do to patch those load balancers?

3) Is a load balancer management network required?  Putting a LB onto an admin 
tenant network as well as a customer tenant network is challenging and bridging 
those networks could allow an attacker to gain access to other things on that 
admin tenant network.

Thanks in advance for your time.

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWuLpuAAoJEHNwUeDBAR+xSF8P/j/KBH2320xB/dGWmy6xOMuJ
DRQCcpEEljIu3O4pU8sF6yGEZX/CIoI3WXGaOBR2g0phWxEus5lhy0DdkPw4ctAa
+UJ7da/s0C7fDbbl09TvWDe3eBoohIunLOm6ABpMT48YipfM0zJLLDEy9kQpDcFg
qg68S5xgtC9zP9CeK1Gvsq5EwjwyX6Mt0a3+G1NMFbUoARLpDDof06YHrNFw73Td
25AxqToR09yRRXsJfadrjjP9/lGWNBF5f5Oh5WoPnEAiThqN08Ico3geHKIr9s2r
Ift5NueWovCI5MUzOzqwsazKgnVgQXrgaaQwRotl5WdZbstUfWJLO+2If5/z4z8d
AArWLXwsCgIv+I6ZyJ4R3YzJVP3KBY8+8gDswjdMV4Jfy7YV9aragy96ofCEwjuH
p6QOGAKJZASD3cQpOdqVqQt4BaWBXMqm70sNDjfzKRBwweuOZgpNRInluDMbhngs
Yqdj2LGUhuij50gQLa21cYJ5pcuA6yY7KNoiiPLkNbFDJtQo6cjVt/McVFPxN3mu
RKRXpZNBgzf5UAKtrMIyPbw1wioAhbt7lgevfvCOLxHCmu0VxsLzRmOdiON5Exmg
vopL518GJSUx93GhA0cwnqT/ilcTvDxFxPXQrvQK/XPtEQq4U3wBF/kZALK1/4tu
7hi/GjugHBcixIZGE5sI
=XI9V
-END PGP SIGNATURE-

__
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

Re: [openstack-dev] [lbaas][octavia] Security/networking questions

2016-02-08 Thread Michael Johnson 
1. Octavia can run under it's own account with the required roles
added to that account.
2. Currently the process would be to update the amphora image in
glance and trigger a failover of the amphora.
3. It is required.  It is a private network between the Octavia
controller and the amphora.  We would like to put the haproxy instance
in it's own namespace be we are not there yet.

Michael

On Mon, Feb 8, 2016 at 7:55 AM, Major Hayden  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hey there,
>
> I've been doing some work to research how best to implement LBaaSv2 and 
> Octavia within the OpenStack-Ansible project.  During that research, I've 
> come up with a few questions.
>
> 1) Is it possible for octavia to operate without providing it with admin 
> credentials?
>
> 2) If a user has amphora LB's deployed and a serious vulnerability is 
> released for OpenSSL/haproxy, what should the user do to patch those load 
> balancers?
>
> 3) Is a load balancer management network required?  Putting a LB onto an 
> admin tenant network as well as a customer tenant network is challenging and 
> bridging those networks could allow an attacker to gain access to other 
> things on that admin tenant network.
>
> Thanks in advance for your time.
>
> - --
> Major Hayden
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWuLpuAAoJEHNwUeDBAR+xSF8P/j/KBH2320xB/dGWmy6xOMuJ
> DRQCcpEEljIu3O4pU8sF6yGEZX/CIoI3WXGaOBR2g0phWxEus5lhy0DdkPw4ctAa
> +UJ7da/s0C7fDbbl09TvWDe3eBoohIunLOm6ABpMT48YipfM0zJLLDEy9kQpDcFg
> qg68S5xgtC9zP9CeK1Gvsq5EwjwyX6Mt0a3+G1NMFbUoARLpDDof06YHrNFw73Td
> 25AxqToR09yRRXsJfadrjjP9/lGWNBF5f5Oh5WoPnEAiThqN08Ico3geHKIr9s2r
> Ift5NueWovCI5MUzOzqwsazKgnVgQXrgaaQwRotl5WdZbstUfWJLO+2If5/z4z8d
> AArWLXwsCgIv+I6ZyJ4R3YzJVP3KBY8+8gDswjdMV4Jfy7YV9aragy96ofCEwjuH
> p6QOGAKJZASD3cQpOdqVqQt4BaWBXMqm70sNDjfzKRBwweuOZgpNRInluDMbhngs
> Yqdj2LGUhuij50gQLa21cYJ5pcuA6yY7KNoiiPLkNbFDJtQo6cjVt/McVFPxN3mu
> RKRXpZNBgzf5UAKtrMIyPbw1wioAhbt7lgevfvCOLxHCmu0VxsLzRmOdiON5Exmg
> vopL518GJSUx93GhA0cwnqT/ilcTvDxFxPXQrvQK/XPtEQq4U3wBF/kZALK1/4tu
> 7hi/GjugHBcixIZGE5sI
> =XI9V
> -END PGP SIGNATURE-
>
> __
> 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

Re: [openstack-dev] [lbaas][octavia] Security/networking questions

2016-02-08 Thread Brandon Logan 
Adding my own input:

1. You should be able to add a specific role that the service accounts
octavia will have.  Then that role can be added to neutron and nova's
policy.json.  I have not tested this out but that is just a quick off
the top of my head solution.

2. What johnsom said.  Not ideal for large deployments but for large
deployers, custom tooling would probably be written for that.

3. Right now in devstack, the mgmt net is a single tenant network owned
by the octavia service account.  This means that a lot of deployments
would be limited to ~250 ports on that network (at least from our own
experience and other's we have talked to).  Deployers can also specify
that the mgmt network is a provider network which may not have that port
restriction.

Alternatively, we could create a mgmt net for each load balancer or each
tenant.  I feel like this would have scaling issues but I haven't
thought about it enough honestly.  Oh, one reason would be because,
right now, all controllers would have to be connected to all the mgmt
nets.  We've actually talked about how to solve this internally, but it
was more just impromptu whiteboarding sessions.

Thanks,
Brandon

On Mon, 2016-02-08 at 12:34 -0800, Michael Johnson wrote:
> 1. Octavia can run under it's own account with the required roles
> added to that account.
> 2. Currently the process would be to update the amphora image in
> glance and trigger a failover of the amphora.
> 3. It is required.  It is a private network between the Octavia
> controller and the amphora.  We would like to put the haproxy instance
> in it's own namespace be we are not there yet.
> 
> Michael
> 
> On Mon, Feb 8, 2016 at 7:55 AM, Major Hayden  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hey there,
> >
> > I've been doing some work to research how best to implement LBaaSv2 and 
> > Octavia within the OpenStack-Ansible project.  During that research, I've 
> > come up with a few questions.
> >
> > 1) Is it possible for octavia to operate without providing it with admin 
> > credentials?
> >
> > 2) If a user has amphora LB's deployed and a serious vulnerability is 
> > released for OpenSSL/haproxy, what should the user do to patch those load 
> > balancers?
> >
> > 3) Is a load balancer management network required?  Putting a LB onto an 
> > admin tenant network as well as a customer tenant network is challenging 
> > and bridging those networks could allow an attacker to gain access to other 
> > things on that admin tenant network.
> >
> > Thanks in advance for your time.
> >
> > - --
> > Major Hayden
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQIcBAEBCAAGBQJWuLpuAAoJEHNwUeDBAR+xSF8P/j/KBH2320xB/dGWmy6xOMuJ
> > DRQCcpEEljIu3O4pU8sF6yGEZX/CIoI3WXGaOBR2g0phWxEus5lhy0DdkPw4ctAa
> > +UJ7da/s0C7fDbbl09TvWDe3eBoohIunLOm6ABpMT48YipfM0zJLLDEy9kQpDcFg
> > qg68S5xgtC9zP9CeK1Gvsq5EwjwyX6Mt0a3+G1NMFbUoARLpDDof06YHrNFw73Td
> > 25AxqToR09yRRXsJfadrjjP9/lGWNBF5f5Oh5WoPnEAiThqN08Ico3geHKIr9s2r
> > Ift5NueWovCI5MUzOzqwsazKgnVgQXrgaaQwRotl5WdZbstUfWJLO+2If5/z4z8d
> > AArWLXwsCgIv+I6ZyJ4R3YzJVP3KBY8+8gDswjdMV4Jfy7YV9aragy96ofCEwjuH
> > p6QOGAKJZASD3cQpOdqVqQt4BaWBXMqm70sNDjfzKRBwweuOZgpNRInluDMbhngs
> > Yqdj2LGUhuij50gQLa21cYJ5pcuA6yY7KNoiiPLkNbFDJtQo6cjVt/McVFPxN3mu
> > RKRXpZNBgzf5UAKtrMIyPbw1wioAhbt7lgevfvCOLxHCmu0VxsLzRmOdiON5Exmg
> > vopL518GJSUx93GhA0cwnqT/ilcTvDxFxPXQrvQK/XPtEQq4U3wBF/kZALK1/4tu
> > 7hi/GjugHBcixIZGE5sI
> > =XI9V
> > -END PGP SIGNATURE-
> >
> > __
> > 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

__
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