On Thu, Dec 3, 2015 at 1:01 PM, Clint Byrum <cl...@fewbar.com> wrote: > Excerpts from Dan Sneddon's message of 2015-12-03 09:43:59 -0800: >> On 12/03/2015 06:14 AM, Sean Dague wrote: >> > For folks that don't know, we've got an effort under way to look at some >> > of what's happened with the service catalog, how it's organically grown, >> > and do some pruning and tuning to make sure it's going to support what >> > we want to do with OpenStack for the next 5 years (wiki page to dive >> > deeper here - https://wiki.openstack.org/wiki/ServiceCatalogTNG). >> > >> > One of the early Open Questions is about urls. Today there is a >> > completely free form field to specify urls, and there are conventions >> > about having publicURL, internalURL, adminURL. These are, however, only >> > conventions. >> > >> > The only project that's ever really used adminURL has been Keystone, so >> > that's something we feel we can phase out in new representations. >> > >> > The real question / concern is around public vs. internal. And something >> > we'd love feedback from people on. >> > >> > When this was brought up in Tokyo the answer we got was that internal >> > URL was important because: >> > >> > * users trusted it to mean "I won't get changed for bandwidth" >> > * it is often http instead of https, which provides a 20% performance >> > gain for transfering large amounts of data (i.e. glance images) >> > >> > The question is, how hard would it be for sites to be configured so that >> > internal routing is used whenever possible? Or is this a concept we need >> > to formalize and make user applications always need to make the decision >> > about which interface they should access? >> > >> > -Sean >> > >> >> I think the real question is whether we need to bind APIs to multiple >> IP addresses, or whether we need to use a proxy to provide external >> access to a single API endpoint. It seems unacceptable to me to have >> the API only hosted externally, then use routing tricks for the >> services to access the APIs. >> > > I'm not sure I agree that using the lowest cost route is a "trick". > >> While I am not an operator myself, I design OpenStack networks for >> large (and very large) operators on a regular basis. I can tell you >> that there is a strong desire from the customers and partners I deal >> with for separate public/internal endpoints for the following reasons: >> >> Performance: >> There is a LOT of API traffic in a busy OpenStack deployment. Having >> the internal OpenStack processes use the Internal API via HTTP is a >> performance advantage. I strongly recommend a separate Internal API >> VLAN that is non-routable, to ensure that no traffic is unencrypted >> accidentally. >> > > I'd be interested in some real metrics on the performance advantage. > It's pretty important to weigh that vs. the loss of security inside > a network. Because this argument leads to the "hard shell, squishy > center" security model, and that leads to rapid cascading failure > (<yoda>leads.. to.. suffering..</yoda>). I wonder how much of that > performance loss would be regained by using persistent sessions. > > Anyway, this one can be kept by specifying schemeless URLs, and simply > configuring your internal services to default to http, but have the > default for schemeless URLs be https.
This is the model I would prefer to use to deploy the API endpoints. I don't like the "squishy" center model either. So, in my case, I think just having one endpoint that is routed or loadbalanced or split-dns differently for internal versus public would be perfectly fine. Thanks, Curtis. > >> SecurityAuditing/Accounting: >> Having a separate internal API (for the OpenStack services) from the >> Public API (for humans and remote automation), allows the operator to >> apply a strict firewall in front of the public API to restrict access >> from outside the cloud. Such a device may also help deflect/absorb a >> DOS attack against the API. This firewall can be an encryption >> endpoint, so the traffic can be unencrypted and examined or logged. I >> wouldn't want the extra latency of such a firewall in front of all my >> OpenStack internal service calls. >> > > This one is rough. One way to do it is to simply host the firewall in > a DMZ segment, setting up your routes for that IP to go through the > firewall. This means multi-homing the real load balancer/app servers to > have an IP that the firewall can proxy to directly. > > But I also have to point out that not making your internal servers pass > through this is another example of a squishy center, trading security > for performance. > >> Routing: >> If there is only one API, then it has to be externally accessible. This >> means that a node without an external connection (like a Ceph node, for >> instance) would have to either have its API traffic routed, or it would >> have to be placed on an external segment. Either choice is not optimal. >> Routers can be a chokepoint. Ceph nodes should be back-end only. >> >> Uniform connection path: >> If there is only one API, and it is externally accessible, then it is >> almost certainly on a different network segment than the database, AMQP >> bus, redis (if applicable), etc. If there is an Internal API it can >> share a segment with these other services while the Public API is on an >> external segment. >> > > It seems a little contrary to me that it's preferrable to have a > software-specific solution to security (internal/external URL in the > catalog) vs. a decent firewall that doesn't let any traffic through to > your non-public nodes, *or* well performing internal routers. Or even > an internal DNS view override. The latter three all seem like simple > solutions, that allow OpenStack and its clients to be simpler. > > The only reason I can see to perpetuate this version of security in > networking is IPv4 address space starvation. And that just isn't a > reason, because you can give all of your nodes IPv6 addresses, and your > API endpoint an AAAA, and be done with that. Remember that we're talking > about "the next 5 years". > >> Conclusion: >> If there were only one API, then I would personally bind the API to a >> local non-routed VLAN, then use HAProxy to reflect those URLs >> externally. This makes the APIs themselves simpler, but still provides >> the advantages of having multiple endpoints. This introduces a >> dependency on a proxy, but I've never seen a production deployment that >> didn't use a load-balancing proxy. In this case, the Keystone endpoint >> list would show the internal API URLs, but they would not be reachable >> from outside. >> > > I think we agree on "this is how we'd do it if we had to", but I wrote > all of the above because I don't really understand what you're saying. > If the catalog showed only internal API's, how would external clients > reach you at all? > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Blog: serverascode.com _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
