RFE: add multiple public networks (https api) to radosgw

[Andre Ruiz]

This is a feature request. Before starting, some notes:

1 - This comes from a customer, so while the reasoning and goal can be discussed and questioned, it will ultimately boil down to implementing the feature as asked within reason.

2 - This is probably a more general problem, and not specific to RadosGW, since IIRC this functionality is in the common libraries and not in the charm itself -- so it could even be a general feature for any charm. But it's opened in radosgw charm because it's the one where the feature is needed now.

Now to the problem:

The charms allow for two https endpoints, one "internal" and one "external" or "public". It will set up SSL certificates for those two and configure api endpoints accordingly in the openstack side.

This support is limited to those 2 IPs. You can have other IPs in the server/unit, you can even have more VIPs on those interfaces controlled by hacluster but you cannot have them listening in HTTPS because they will not be configured.

The customer wants to have one internal and multiple "public" networks, on the radosgw units to completely segregate different networks consuming radosgw services in separate layer 2 networks.

The problem is that adding clients to the same layer 2 network as the public network is a security issue (the client will have access to all services APIs while they want to limit access to radosgw) and routing clients from other networks poses a performance problem because they expect a high throughput, and they can't find commercial systems that will sustain performance when enabling firewall for controlled access.

So this bug report has two objectives:

1 - Ask for a possible workaround for having more public networks manually configured until this is solved (in a charm friendly way)
2 - Ask for implementing support for multiple networks (one of them can still be the official one for openstack endpoint, but all of them would be available for clients S3/swift consumption).

[Billy Olsen (billy-olsen)]

Since this is all HTTP traffic, this could likely be implemented today using an apache or haproxy front end proxy on the various networks that the user is interested in.

[Andre Ruiz (andre-ruiz)]

Ok, a fresh look on this revealed a few interesting aspects of the problem. This is not about SSL, and not about libs (as stated in the OP). It can be much simpler with haproxy (hacluster) just binding to the wildcard address and letting everything not explicitly ACL'd to go to the official public backend (which will enter radosgw through the only SSL configured public network therefore not requiring changes to the SSL part).

The problem today is that although the haproxy config _is_ binding to *:443, the default backend is the internal endpoint and not the public one. Is there a reason for this? From a security standpoint it seems even worse. But there may be a not obvious reason for having it there.

If there is not, then changing haproxy default backend would be the easiest solutions for this.

[Billy Olsen (billy-olsen)]

Per the code in the charm-helpers library setting up the haproxy configuration (https://github.com/juju/charm-helpers/blob/master/charmhelpers/contrib/openstack/context.py#L911), this should be influence-able by binding the 'cluster' network space when deploying the application.

[Andre Ruiz (andre-ruiz)]

An update on this:

- the cluster bind can be changed to control the default rule in haproxy
- new networks can be added in netplan and applied, haproxy will pick them because it's bound to 0.0.0.0
- new vips can be manually added to pacemaker using crm create resource, the charm will not wipe them when changing options (tested)
- DNS name for the new vips on other networks have to mimic dns name for official public one if you expect certificate to be automatically accepted

This should be enough to manually configure it until official support is implemented.