Dustin C. Hatch
22dbc3ebc1
Currently, the certificate authority that issues certificates for PostgreSQL clients is hosted in Kubernetes and managed by _cert-manager_. Certificates it issues are stored in Kubernetes Secret resources, making them easy to consume by applications running in the cluster, but not for anything outside. Since Nextcloud runs on its own VM, we need a way to get the certificate out of the Secret and into a file on that machine. To that end, I've written the `nextcloud-fetch-cert.py` script. This script uses a Kubernetes Service Account token to authenticate to the Kubernetes API and download the contents of the Secret. It runs periodically, triggered by a systemd timer unit, to ensure the certificate is always up-to-date. The obvious drawback to this approach is the requirement for a static token. Since there's not really a way to "renew" Service Account tokens, it needs to be issued with a fairly long duration, to mitigate the risk of being unable to fetch a new certificate once it has expired because the token has also expired. This somewhat negates the advantage of using certificates for authentication, since now the machine needs a static, pre-defined secret. At some point, I may deploy another instance of _step-ca_ to manage the PostgreSQL client CA. Clients can then use e.g. `certbot` or `step ca certificate` to obtain their certificates. I chose not to implement this yet, though for a couple of reasons. First, I need to move the Nextcloud database very soon, so we switch to using `restic` for backups without having to deal with the database. Second, I am still considering moving Nextcloud into Kubernetes eventually, where it will be able to get the Secret directly; since Nextcloud is the only client outside the cluster, it may not be worth setting up _step-ca_ in that case.