I would agree with the recent comments. Being able to separate them out would be ideal.
On Friday, February 12, 2016, Dan Sneddon <[email protected]> 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 > > [email protected] <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 > [email protected] <javascript:;> | redhat.com/openstack > 650.254.4025 | dsneddon:irc @dxs:twitter > > _______________________________________________ > OpenStack-operators mailing list > [email protected] <javascript:;> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
