RFE: add multiple public networks (https api) to radosgw
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceph RADOS Gateway Charm |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
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).
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.