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