Hi, Juan - Actually, the third option is also not an option in the current undercloud > setup, since making the services listen in 0.0.0.0 will break HAProxy. So > when you're deploying with TLS things will break since we use HAProxy to > terminate TLS connections. >
Ah, that's correct, isn't it. > On the other hand, we also don't want services to listen on 0.0.0.0 since > that would become a security concern. We should instead be blocking > everything we don't need to have exposed (as we've done with the > undercloud's database and rabbitmq). > I don't disagree that we want to focus on least privilege, but we do have documentation that talks about how to deal with this. I addressed this in my previous message, even if only to illustrate my understanding that there would be concerns around this. See more comments about this down below... > > Now, as we're trying to move to have more convergence between the > undercloud and the overcloud (trying to deploy the undercloud via heat > also, as Dan Prince has mentioned), I think some aspecs of this will bring > a solution to this problem. for instance, just like we already do in the > overcloud, we could have the undercloud's HAProxy always terminate the > endpoints, which I'm attempting with these two patches: > https://review.openstack.org/#/c/360366 https://review.openstack.org/# > /c/360368 . Furthermore, we could have the public endpoints in HAProxy > listen on a separate network that's accessible externally, also as we do in > the overcloud. That way we don't need to change the actual interfaces the > services are listening on, and rely on HAProxy, getting closer to how we do > things in the overcloud. It seems to me that it would help solve the > problem. > I like that idea. Though, this effectively shifts the process of having these services themselves listen on different IPs/ports and offloads that to HAProxy. Whatever security concerns we have with opening up network communications would still exist, but I think that would be more broadly accepted considering these connections are now managed by HAProxy which *only* listens for SSL connections. Another challenge with isolating this traffic on a separate network is that we introduce a new dependency that's going to take administrative time to set up and configure outside of OpenStack - do we really want that? Thanks! -dant > > On Wed, Sep 28, 2016 at 7:24 PM, Dan Trainor <dtrai...@redhat.com> wrote: > >> Hi - >> >> I want to bring up a subject that needs a little more attention. There >> are a few ideas floating around but it's important that we get this done >> right. >> >> UI is unique in the sense that it operates almost entirely in a browser, >> talking directly to service API endpoints which it either figures out from >> they Keystone service catalog as using the publicURL endpoint for each >> service, or by specifying these API endpoints in a configuration file. >> Though overriding the API endpoints in the UI's local configuration file is >> an option that's available, I understand that we want to move towards >> relying exclusively on Keystone for accurate and correct endpoint >> configuration. >> >> Right now, all of the service API endpoints that UI needs to talk with >> are only listening on the ctlplane network. >> >> We've had several iterations of testing and development of the UI over >> time and as a result of that, three different solutions that work - >> depending on the exact circumstances - have been created which all can >> achieve the same goal of allowing the UI to talk to these endpoints: >> >> - Local SSH port tunneling of the required ports that UI talks to, from >> the system running the UI to the Undercloud, and configuring the UI to talk >> to localhost:NNNN. This method "works", but it's not a solution we can >> recommend >> - Making the interface on which these services already listen on - the >> ctlplane network - routable. Again, this method "works", but we treat this >> interface in a very special manner on purpose, not the least of which >> because of it's ability to facilitate pxebooting >> - Change the public endpoints in the Keystone catalog to be that of the >> existing external, routable interface of the Undercloud for each service >> required by the UI. This also requires configuring each service that UI >> needs to talk with, to listen on the existing, external, routable interface >> on the Undercloud. Some services support a list of interfaces and IPs to >> listen on; others require exactly one argument, in which case the address >> of 0.0.0.0 would need to be used >> >> According to the API Endpoint Configuration Recommendation guide[1], the >> third option seems most viable and one that we can recommend. The document >> briefly describes the security implications of having these services open >> on a public interface but recommends the use of a stringent network policy >> - something we're used to recommending and helping with. The first two >> options, not so much. >> >> Based on discussions I've had with other people, it's my impression that >> the third option is likely the one that we should proceed with. >> >> This concern is largely transparent to how we're currently testing and >> developing the UI because most of that work is done on local, virtualized >> environments. When this happens, libvirt does the heavy lifting of >> creating a network that's easily routable from the host system. If not >> that, then the evolution of instructions for setting up these local >> environments over time have recommended using SSH port forwarding. >> However, neither of these options should be recommended. >> >> Thoughts? >> >> Thanks >> -dant >> >> -- >> >> P.S. and full disclosure: I'm biased towards the third option. >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Juan Antonio Osorio R. > e-mail: jaosor...@gmail.com > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
