Open Stack

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
> 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 |  redhat.com/openstack
650.254.4025        |  dsneddon:irc   @dxs:twitter