[one-users] Sunstone endpoint for VDC

[Tino Vazquez]

Hi Bill,

On 17 Sep 2013, at 10:03, Tino Vazquez wrote:

> Hi Stefan,
>
> comments inline,
>
> On Tue, Sep 17, 2013 at 2:51 PM, Stefan Kooman <stefan at bit.nl> wrote:
>>
>> Hi list,
>>
>> I'm in the process of testing the OpenNebula oZones / VDC functionality.
>> My setup is as follows:
>>
>> - 2 hosts, with 1 one of them in a cluster "TESTCLUST01", 1 in default
>> cluster.
>> - a zone "TESTZONE01" using resources from "TESTCLUST01"
>> - a VDC "TESTVDC01" within zone "TESTZONE01".
>>
>> I have several apache vhosts (listening on *:443) acting as reverse (SSL) proxy:
>>
>> - ozones (reverse proxying to http://127.0.0.1:6121)
>> - sunstone (reverse proxying to http://172.16.0.183:9869
>> - occi (reverse proxying to http://127.0.0.1:4567)
>>
>> These end points all work correctly (occi API works, sunstone works,
>> ozones web GUI works).


>This is a wise choice. Given that Sunstone and oZones accept and emit authentication credentials in plaintext, it is insane to have those listeners talking to the Internet without a SSL proxy.

It is a reasonable configuration. I just want to point out that
Sunstone can be configured to authenticate using X509 certificates.

>The oZones GUI is not designed to support secure (i.e. proxied) communications with OpenNebula instances, and that is made >obvious lines 349 and 406 of /usr/lib/one/ozones/public/js/plugins/vdcs-tab.js, both of which use literal "http://" strings to build >the links to OpenNebula and use the hostname extracted from zone's ENDPOINT parameter (which is likely to be 'localhost' for i>nstances that are only used to build VDC's in a zone managed on the same host) To make the oZones GUI provide URL's that >work, one must fix the code.

>From a broader perspective, the problem is in the design. It doesn't make any sense for one tool to handle multiple >OpenNebula instances as a collection of Zones that also is the only tool for defining a VDC: a subset of a cluster, which is a >subset of a zone. VDC definition should be moved into OpenNebula proper (oned/one.db) and Sunstone. The oZones server >should only be required or useful for handling multiple zones, it should assume that it needs to be able to communicate with >OpenNebula instances that are behind SSL proxies, and it should be documented to make that assumption clear.

You are mostly right with your arguments. There is much room for
improvement in the oZones component, and we are in for a major
redesign. The VDC functionality is going to be moved from oZones to
Sunstone, as you pointed out, it makes much more sense that way. Users
that would log into Sunstone would be presented with a list of VDCs
she is able to log into.

You can certainly put ONE and Sunstone behind a proxy to enable SSL
traffic between clients and servers. True, oZones redirections with
Apache do not support SSL connections, so this will be revisited as
well. We would probably end up with a SunstoneServer that can access
different OpenNebula instances, this will be prone to have secure
connections between client & Sunstone, as well as Sunstone &
OpenNebula.

Thanks for the feedback, we will we will include your suggestions and
feedback on VDCs and Zones in future releases (including the doc).

Best,

-Tino

>
>
>> You see, the ozones server
>> talks with the apache server via a .htaccess file, where it is
>> dynamically setting reverse proxy rules for each created VDC. So,
>> after creating TESTVDC01, a couple of lines are written in the
>> .htaccess file so apache knows that when a request comes for
>>
>> http://ozones-server/sunstone_TESTVDC01
>>
>> it should redirect to
>>
>> http://sunstone-server:9869
>>
>> where sunstone-server is the Sunstone endpoint defined by the zone
>> that contains TESTVDC01. 9869 is the default Sunstone port, which can
>> be changed as well upon VDC creation.
>
>
> This explanation doesn't much improve on the muddled documentation of the
> oZones server. Maybe a as someone who has come at oZones as an admin instead
> of as a developer I can offer a different angle:
>
> It is important for people deploying the oZones server to understand that it
> performs two weakly related functions:
>
> I. Aggregate access to subsets (VDCs) of multiple OpenNebula instances
> (Zones) through a single host running a web proxy.
> II. Create a templated pattern of users, groups, and ACLs in a zone that
> allows delegated administration & use of VDCs.
>
> It does this using two distinct components:
>
> 1. A Ruby http (Sinatra/Thin) server listening on port 6121 which manages
> the oZones database of zones and VDCs, serves the CLI tools and the web GUI
> as clients, and creates OpenNebula and Apache configurations for VDCs.
> 2. An Apache httpd with a virtual host configured as a dedicated mod_rewrite
> reverse proxy, serving URLs for the XMLRPC and Sunstone interfaces of all
> VDCs in all Zones under a single hostname. This presents users with the
> appearance of all VDCs being in one place.
>
> The linkage between the two is that (1) writes out a new root .htaccess file
> for (2) with a set of 3 mod_rewrite rules for each VDC whenever a VDC is
> created. As far as I can tell, Sunstone and the core one* CLI tools are
> unaware of the VDC paradigm (unless you consider the "vdcadmin" Sunstone
> view awareness) and the creation of a VDC by oZones is nothing more than:
>
> A. The creation of a user, a group, and 11 ACLs associated with them in
> OpenNebula.
> B. The creation of a set of 3 mod_rewrite rules for Apache.
> C. Changes in the oZones database, which is only ever touched by oZones.
>
> Only (A) is critical to the core VDC functionality: delegating
> administrative control of a subset of an OpenNebula instance's resources to
> one user and access to those resources for additional users that the
> delegated admin can create. Any user of the "real" Sunstone and XMLRPC URLs
> gets exactly what he would get via any of the VDC-specific URLs that proxy
> the same zone. Unfortunately, oZones has assumptions embedded in its code
> that make it incompatible with a minimally-secure OpenNebula installation.
> Fortunately, one use what oZones does as a basis for manual configuration of
> Apache and OpenNebula that achieves the same end results.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org