Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160928/9545ce8e/attachment.html>