[openstack-dev] [tripleo] Getting the UI to talk with Undercloud API service endpoints

Dan Trainor dtrainor at redhat.com
Thu Sep 29 16:01:25 UTC 2016


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 <dtrainor at 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-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosorior at gmail.com
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160929/7e6dbe94/attachment.html>


More information about the OpenStack-dev mailing list