Open Stack

I would agree with the recent comments.  Being able to separate them out
would be ideal.

On Friday, February 12, 2016, Dan Sneddon <dsneddon at redhat.com> wrote:

> On 02/12/2016 06:04 AM, Steven Dake (stdake) wrote:
> > Hi folks,
> >
> > Unfortunately I won't be able to make it to the Operator midcycle
> > because of budget constraints or I would find the answer to this
> > question there.  The Kolla upstream is busy sorting out external ssl
> > termination and a question arose in the Kolla community around operator
> > requirements for publicURL vs internalURL VIP management.
> >
> > At present, Kolla creates 3 Haproxy containers across 3 HA nodes with
> > one VIP managed by keepalived.  The VIP is used for internal
> > communication only.  Our PUBLIC_URL is set to a DNS name, and we expect
> > the Operator to sort out how to map that DNS name to the internal VIP
> > used by Kolla.  The way I do this in my home lab is to use NAT to NAT
> > my public_URL from the internet (hosted by dyndns) to my internal VIP
> > that haproxies to my 3 HA control nodes.  This is secure assuming
> > someone doesn't bust through my NAT.
> >
> > An alternative has been suggested which is to use TWO vips.  One for
> > internal_url, one for public_url.  Then the operator would only be
> > responsible for selecting where to to allocate the public_url
> > endpoint's VIP.  I think this allows more flexibility without
> > necessarily requiring NAT while still delivering a secure solution.
> >
> > Not having ever run an OpenStack cloud in production, how do the
> > Operators want it?  Our deciding factor here is what Operators want,
> > not what is necessarily currently in the code base.  We still have time
> > to make this work differently for Mitaka, but I need feedback/advice
> > quickly.
> >
> > The security guide seems to imply two VIPs are the way to Operate: (big
> > diagram):
> > http://docs.openstack.org/security-guide/networking/architecture.html
> >
> > The IRC discussion is here for reference:
> >
> http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-02-12.log.html#t2016-02-12T12:09:08
> >
> > Thanks in Advance!
> > -steve
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org <javascript:;>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
> I am not an operator, but I work with large-scale operators to design
> OpenStack networks regularly (more than one per week). In general, the
> operators I work with want a separation of their Public from their
> Internal APIs. This helps with accounting, since tracking accesses to
> the Public API is easier when you don't have to filter out all the
> internal service API calls. I have also seen some operators place the
> Public APIs into a protected zone that required VPN access to get to,
> while the Internal APIs were only accessible from inside the deployment.
>
> Another interesting use case I have seen several times is when a
> service VM needs to connect to the Public APIs. I have seen this when a
> VM inside the cloud was used to host a self-service portal, so that VM
> needs to be able to issue commands against the Public APIs in order to
> provision services. In this case, it would have been difficult to
> engineer a solution that allowed both the VM and the internal services
> to connect to a single API without increasing the attack surface and
> reducing security.
>
> --
> Dan Sneddon         |  Principal OpenStack Engineer
> dsneddon at redhat.com <javascript:;> |  redhat.com/openstack
> 650.254.4025        |  dsneddon:irc   @dxs:twitter
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org <javascript:;>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160212/dfd7c8e7/attachment.html>