This semester featured MongoDB in a couple of classes. I’m guessing professors are gravitating to it because it’s relatively easy to get up and running with a cloud account on Atlas. I really enjoyed working with it, and I will probably toy with a local deployment. However, I wanted to deploy a PostgreSQL database to the homelab. I’m still learning, but as with the rest of my lab, it will use Flux for a GitOps-based deployment. I upload it to GitHub. GitHub deploys it to my server.
Github Repo: https://github.com/OMTut/lab
This database should be inward-facing. The intention is for the database to only be accessible from apps inside our LAN. In fact for security, it will only be accessed from inside our Kubernetes cluster. Welcome to WeylandCorp. Ok, not really, but the database is called weylandcorp. Let’s go.
For security purposes the database is exposed as a ClusterIP service which allows access only for internal components of the cluster. Credentials are securely retrieved through external secrets that have been SOPS encrypted. To further isolate it, we’re using an individual namespace and privilege escalation is prevented. However, nothing is ever truly secure. I mean, you have to access the database somehow. That’s your point of risk.
pgAdmin4
In order to administer the database, I’ve set up a pgAdmin4 deployment as a Load Balancer service. This deployment also uses SOPS encryption for credentials, an isolated namespace, and prevents privilege escalation. If you are within the LAN, you have access to the app. Eternal traffic is blocked. However, I would like to take this one step forward and block all internal access as well with the exception of one or two ip addresses.
Hiccups
My main hiccup was trying to dump a local project’s database and restore it within the Kubernetes cluster. It’s simple enough, but I had a time trying to figure out how to get the file into the cluster. Because the app lives within its own pod and namespace, it’s isolated. I eventually figured it out, and it’s up and running.