I don't think we can rely on the Undercloud as an API proxy unless we address the lack of HA on the Undercloud.
Wouldn't this be better implemented as as a single, name-based HAProxy instance running SSL on port 443 on the overcloud Public VIP? Then we could have the same endpoint for Horizon and every other API. I actually implemented this scheme in Havana before I joined Red Hat. At the time, we had to have a complex HAProxy config and patch the end points to support name-based URLs. I think some work has been done in OpenStack now to support this model, but I'm not sure where it stands. >> Dan Sneddon | Principal OpenStack Engineer | dsned...@redhat.com > On Sep 30, 2016, at 9:44 AM, Dan Trainor <dtrai...@redhat.com> wrote: > > Hi - > > I re-read your email a few times and like a few of the things that I see, but > I'd love some more clarification. As I read it, a few of these things > conflict. I believe you're suggesting that we don't make these services > listen on a public interface due to security concerns (and of course, > enabling SSL would break this because haproxy would listen on these > interfaces/ports), but this approach would be acceptable if HAProxy was > listening on these ports, terminating SSL, and sending them to each > respective service backend. Am I correct i understanding this? > > Are you suggesting that these endpoint ports would still be externally > accessible on the primary (public) interface of the Undercloud, but just > managed by HAProxy? I think that's an acceptable approach. Even if these > endpoints are, like you suggested, listening on a separate network or IP as > the Undercloud's primary interface, at least then it would be easier for > organizations to enforce network access policies to these ports, and > subsequently, these services that UI needs to talk to directly. > > I'm also perfectly fine with suggesting that if UI is installed, then this > forces the Undercloud to be SSL enabled. This would be a good way to move > the idea of a secured, by default SSL-enabled Undercloud forward a little > more, which is something we'd definitely like to see more. > > Thoughts? > > Thanks > -dant > > > >> On Thu, Sep 29, 2016 at 9:01 AM, Dan Trainor <dtrai...@redhat.com> wrote: >> 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:unsubscribe >>>> 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
__________________________________________________________________________ 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
