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

Brandon Logan brandon.logan at RACKSPACE.COM
Mon Feb 8 22:17:00 UTC 2016


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 <major at mhtx.net> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list