Open movitto opened 2 years ago
@movitto thank you so much for the fine grained details that you have kindly provided to the community.
One of the philosophy behind Kubegres is to avoid creating a custom Postgres container containing custom libraries. We are using the official Docker Postgres container. Kubegres can only uses the libraries available in that container.
Before I look into the details, my question is the following: do you think we can implement the feature that you have suggested without creating a custom set of libraries and therefore having to package them in a custom Postgres container?
@alex-arica Thanks for the response. As far as I can tell, the only additional component that is needed here is the 'openssl' command. Having just checked, I verified that yes, openssl is available in the stock postgresql container. Now the only question is do we want to run it there?
There are two possibilities:
Run openssl on the primary postgresql container, then somehow 'export' the the client and server credentials to kubernetes such that secrets can be created, for import into the replicas and client containers.
Run the openssl commands on the user's local system (from which they are issuing the commands to deploy kubegres), and then proceed in the manner described in the steps above.
The benefit of approach one is that all the software is ready out of the box, kubegres can take care of running the existing commands on the container. The only question is that I'm not sure how we export the key and cert files from the primary container so that is available to the other server and client containers.
The downside to the second strategy is that it requires the user to have openssl installed on their local system. The benefit to this though is that it's the standard kubernetes workflow after that, and the key/cert credentials are available locally for backup purposes.
I'd lean towards the second approach as it would be pretty straightforward.
ssl_credentials:
server:
key: // Path to key file
cert: // Path to cert
ca: // Path to CA (can be same as cert)
clients:
- key: // Path to first key file
cert: // Path to first cert file
- key: // Path to second key file
cert: // Path to second cert file
- ...
Alternatively instead of paths, the actual key / certs can be stored (or both option formats supported), though it's probably not advisable to store the keys directly in the kubegres config.
So long answer short, it can be done with the official postgresql containers! :smile:
Personally I'm achieving the same result in terms of SSL configuration declaratively in Kubernetes by using JetStack CertManager with a Self-Signed Issuer to create a private CA using a Certificate resource, and then a CA issuer that depends on that private CA to generate the server certificate and any client certificates I need.
CertManager then automatically handles certificate rotation and generation with a fully declarative configuration that does not require secrets to be stored anywhere. I'm wonder if our use-cases are all that different or perhaps something similar would work for you.
@hxtk Certainly there are many use cases / workflows for certificate management with postgres / kubegres. While there is some overlap with our approaches, ours (self-managed certificates) work for us for the time being as we prefer not to leverage an external use case for both. That being said it would be nice if kubegres supported both, both internally generated certs (managed automatically by the cluster) and externally installed / managed certs.
First of all, thanks for the great project. We've only recently found it but it's already proving to be very useful to setup postgres on kubernetes in a very simple way.
Having recently used kubegres to setup postgres on our Kubernetes cluster, along with SSL support (issue #58 helped us resolve issues with the importing of ssl certificates) we couldn't help but think that it would be nice if kubegres took care of this configuration internally, without users having to go through the hasstle of key/cert management and configuration. Our current workflow is as follows:
Note that we only permit local unix-domain connections, replicator connections, and external ssl connections. Also in the primary_init_script, we connect to postgres via the local unix-domain socket
Apply it and wait for the server to start:
Note how we import the database client key and cert here and the server cert (to use as the certificate authority in the database connection credentials). For reference here is a snippet of our applications database configuration (sequelize based)
Phew that was a hasstle!
TLDR:
Wouldn't it be great if kubegres took care of alot of this for us. Specifically if we could add the following options to our kubegres database config:
With the result being kubergres:
Thoughts?
(And thanks again for the great project and reading this lengthy issue!)