Early in my cybersecurity journey, I believed my value lay in finding vulnerabilities, maintaining detection capabilities, and keeping adversaries at bay. The work was enjoyable, and it let me focus on technical skills while building a strong foundation for problem solving and analytical thinking.
I've never been great at uncomfortable conversations. Not at work, and not at home.
There was always something in me that zeroed in on the uncomfortable aspects and amplified my anxiety. I'm sure there are plenty of explanations I could research to understand why but that's not the aim of this post (maybe another time).
Every tough discussion felt like a minefield and I couldn't help but want to avoid them altogether. As I got older, and wiser, I learned that the difficult, challenging parts of life are where real growth happens. I began exploring ways to practice and overcome this tendency.
I know it can be tedious and more of a time sink to read through API reference or schema. But it is absolutely worth it, especially if you also take notes for yourself.
Let me explain. I have been wrapping my head around how I can get up and running with using CloudNativePG for my databases. Starting with Linkding, but have plans to expand it to a half dozen other self-hosted apps.
I didn't want to just copy someone else's manifest, or ask GenAI to create a manifest for me. I took the time to read what each field was for, and went down the rabbit hole reading first the Cluster reference, then ClusterSpec and several deeper fields within that.
This is part 3 of my series detailing a transition of my Homelab architecture to using Kubernetes with Proxmox. You can check out the previous parts here:
In part 3, I’ll explore my implementation strategy for Kubernetes and how it has transformed my homelab.
Kubernetes has become the logical next step for my homelab. I've pointed this out briefly in parts 1 and 2. I enjoy the break-and-fix cycle of learning in my homelab. However, over the years I have found more joy with making things work consistently, from the very start, every time.
This is an update to my previous post regarding my process for creating a Linkding self-hosted service with FluxCD in my homelab Kubernetes cluster.
You can read the original post here: Creating Linkding Deployment with FluxCD
After getting my Linkding deployment working through my FluxCD GitOps lifecycle, I quickly realized that I was missing some key functionality and configuration steps.
The first one being that my Linkding app wasn't being exposed for me to access locally on my network. It was only accessible from a node in my cluster that could access the cluster IP addresses. This a is problem if I'm planning to use Linkding for all my bookmarks!
The next one being that the Deployment does not declare any superuser account. In the original version of my Deployment I was required to perform an exec command inside the Container to create my superuser name and password before I could ever login. This was using a python script and very tedious! Not what I want if my aim is to have a declarative, stateful Deployment where we could potentially deploy Linkding to a brand new Kubernetes cluster with a superuser already setup and configured. I have the PersistentVolumeClaim setup for the data directory to persist within the cluster, but an initial or bootstrap deploy to a brand new cluster would not result in any superuser account getting setup. This relates to the idea of idempotentency, where I want the Deployment to be applied the first time and any number of times after that without changing the outcome beyond the initial deployment.
These updates support declarative, repeatable deployments of linkding and improves security by not hardcoding credentials.
For a full breakdown of this updated structure to my Linkding Deployment you can check out my homelab GitHub repository at https://github.com/cyberwatchdoug/homelab/tree/main
This is part 2 of my series detailing a transition of my Homelab architecture to using Kubernetes with Proxmox. You can check out part one here: From Proxmox to Kubernetes - Evolving My Homelab (part 1)
In this post, I continue my journey evolving my homelab from a simple Proxmox setup to a more robust Kubernetes-based architecture. Building on part one, I’ll share what worked, what didn’t, and how my approach to self-hosting and automation has changed over time.
In this second part for my Secrets Management with External Secrets Operator (ESO) and 1Password, I will be detailing how I configured my ESO deployment through GitOps using Flux, Kustomization, and Secrets resources. You can read the first part here: Secrets Management With External Secrets Operator and 1Password (part 1).
A recap on why ESO: the goal of the ESO operator is to synchronize secrets from these external sources into Kubernetes secrets, so they can be more easily accessed and used throughout the cluster.
All of these configuration files can be found in my homelab GitHub repository located here: https://github.com/cyberwatchdoug/homelab/tree/main
This is an update to my previous post regarding my process for creating a Linkding self-hosted service with FluxCD in my homelab Kubernetes cluster.
You can read the original post here: Creating Linkding Deployment with FluxCD
After getting my Linkding deployment working through my FluxCD GitOps lifecycle, I quickly realized that I was missing some key functionality and configuration steps.
The first one being that my Linkding app wasn't being exposed for me to access locally on my network. It was only accessible from a node in my cluster that could access the cluster IP addresses. This a is problem if I'm planning to use Linkding for all my bookmarks!
The next one being that the Deployment does not declare any superuser account. In the original version of my Deployment I was required to perform an exec command inside the Container to create my superuser name and password before I could ever login. This was using a python script and very tedious! Not what I want if my aim is to have a declarative, stateful Deployment where we could potentially deploy Linkding to a brand new Kubernetes cluster with a superuser already setup and configured. I have the PersistentVolumeClaim setup for the data directory to persist within the cluster, but an initial or bootstrap deploy to a brand new cluster would not result in any superuser account getting setup. This relates to the idea of idempotentency, where I want the Deployment to be applied the first time and any number of times after that without changing the outcome beyond the initial deployment.
These updates support declarative, repeatable deployments of linkding and improves security by not hardcoding credentials.
For a full breakdown of this updated structure to my Linkding Deployment you can check out my homelab GitHub repository at https://github.com/cyberwatchdoug/homelab/tree/main
In this first part for my Secrets Management with External Secrets Operator (ESO) and 1Password series, I'm going to detail how to get ESO deployed through GitOps using Flux, Kustomization resources, and Helm resources. All of these configuration files can be found in my homelab GitHub repository located here: https://github.com/cyberwatchdoug/homelab/tree/main
What exactly is External Secrets Operator, and why should we use it? Great question. ESO is a Kubernetes operator that solves the dilemma of secrets management in Kubernetes from external sources. The list of providers is lengthy, but it includes important players like AWS, Google, Azure, HashiCorp, CyberArk, and 1Password. The goal of this operator is to synchronize secrets from these external sources into Kubernetes secrets, so they can be more easily accessed and used throughout the cluster.
Ever since I started tinkering with FluxCD in my homelab Kubernetes cluster, I've been on a kick with maximizing both best practices with it, and also automating the orchestration of my self-hosted services.
It's quite a ride! But as this post is my process for getting the Linkding bookmark service deployed, I will not be going into detail on how to get FluxCD setup and configured. That's a prerequisite you have hopefully already gone through.
For a full breakdown of this structure and the files you can check out my homelab GitHub repository at https://github.com/cyberwatchdoug/homelab/tree/main