Add SSL configuration for RGW

[marceloneppel]

Description

Some tools, like pgBackRest, can currently only interact with S3-compatible storages if they work with SSL/TLS. This PR adds the possibility of enabling RadosGW with SSL/TLS enabled.

The main idea is to use the PostgreSQL charms with MicroCeph so users can do backups through pgBackRest in bucket without a cloud service subscription.

Type of change

• [X] New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test, I used the following steps:

1. Generate some SSL files:

   sudo openssl genrsa -out /var/snap/microceph/common/ca.key 2048
   sudo openssl req -x509 -new -nodes -key /var/snap/microceph/common/ca.key -days 1024 -out /var/snap/microceph/common/ca.crt -outform PEM
   sudo openssl genrsa -out /var/snap/microceph/common/server.key 2048
   sudo openssl req -new -key /var/snap/microceph/common/server.key -out /var/snap/microceph/common/server.csr
   sudo nano /var/snap/microceph/common/extfile.cnf # and put the following content: subjectAltName = DNS:localhost
   sudo openssl x509 -req -in /var/snap/microceph/common/server.csr -CA /var/snap/microceph/common/ca.crt -CAkey /var/snap/microceph/common/ca.key -CAcreateserial -out /var/snap/microceph/common/server.crt -days 365 -extfile /var/snap/microceph/common/extfile.cnf

2. Then bootstrap the MicroCeph cluster, enable the RadosGW service with SSL enabled and create a user:

   sudo microceph cluster bootstrap
   sudo microceph disk add loop,4G,3
   sudo microceph enable rgw --ssl-certificate=/var/snap/microceph/common/server.crt --ssl-private-key=/var/snap/microceph/common/server.key
   sudo microceph.radosgw-admin user create --uid test --display-name test

3. To finish, test the access by creating a bucket:

   aws configure # to configure the credentials from RadosGW.
   AWS_CA_BUNDLE=/var/snap/microceph/common/ca.crt aws --endpoint-url=https://localhost s3 mb s3://test --region ""

Contributor's Checklist

Please check that you have:

• [X] self-reviewed the code in this PR.
• [ ] added code comments, particularly in hard-to-understand areas.
• [X] updated the user documentation with corresponding changes.
• [X] added tests to verify effectiveness of this change.

[marceloneppel]

Hey @marceloneppel thanks for this welcome contribution!

I'm wondering about two things regarding parametrization.

One is relatively minor thing, aiui with SSL key material present we'd configure both http/https. Ideally we would have a way to turn off non-SSL service if we configure SSL key material -- maybe the logic could be to configure https if SSL key material is provided, and http if there's no key material. And only configure both if both ports are explicitly provided.

The other is around that key material. In your PR the user has to provide file paths to the key material. However due to snap confinement there's a limited number of places the services can actually read data from, and users would see failing services if the ssl files are not in a suitable place. I'd suggest to check in the CLI part of the code that the file is readable for the snap so users get an early warning, and document the constraints around this. Alternatively, the code could be changed so that the key material itself is used as a parameter (instead of the file names).

It would also be great to have functional tests for this feature.

Thanks again!

Hi, @sabaini! Thanks for the feedback. I'm going to work on those updates.