{
  "id": 4401390,
  "title": "🔒 HomeLab Chronicles: Episode 7 - Locked Out of My Own House",
  "url": "https://urgent.news/2026/08/30/homelab-chronicles-episode-7-locked-out-of-my-own-house",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-30T09:50:03.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/snskarora/homelab-chronicles-episode-7-locked-out-of-my-own-house-200j"
  },
  "original_language": "en",
  "account": "In this seventh episode of the HomeLab Chronicles, the author experiences a frustrating issue where they were unable to access their own home lab. After setting up a fresh rebuild and enabling Role-Based Access Control (RBAC) while the cluster was empty, the author encountered numerous problems.\n\nSymptom One: Flux Bootstrap Times Out\nThe Flux Bootstrap process timed out while waiting for custom resource definitions (CRDs), specifically 11 CRDs, all stuck in an \"InProgress\" status. These CRDs were committed and pushed without any issues, yet the cluster remained unresponsive. When inspecting a stuck CRD, it appeared as if it had never been processed at all. In contrast, under a healthy cluster, the apiserver would immediately assign a status of \"Established\" to a CRD. The logs revealed that the leader election lease for the controller-manager component could not be acquired, preventing the creation of ReplicaSets and ultimately causing all downstream processes to fail.\n\nSymptom Two: A Deployment Frozen in Time\nA deployment in the kube-system namespace was found to be stuck at 0/1, indicating that no ReplicaSet had been created. This meant that the deployment controller never even attempted to process the deployment. With no DNS pod present, errors downstream began to accumulate and were queued up alphabetically. The logs showed that both the controller-manager component and the scheduler were forbidden from accessing the objects they were supposed to manage. Even impersonation tests, which are typically permitted, failed due to a universal binding issue. The author discovered that the RBAC authorizer was not loading the policy at all, despite the presence of the correct permissions and roles.\n\nRoot Cause and Resolution\nThe author realized that the issue stemmed from the RBAC authorizer failing to load the policy. Even though the cluster's API server was healthy and the admin certificate bypassed authorization entirely, the authorizer itself was the culprit. After disabling RBAC temporarily and stopping/restarting the MicroK8s cluster, the author successfully re-ran the bootstrap process, which now skipped the RBAC enablement step. They added the crucial check to ensure that coredns reached a ready state of 1/1 before proceeding with any other deployments. This helped confirm that the datastore could persist writes and that the controllers could act on them. In the end, the author learned that while disabling RBAC for a short time can be convenient, enabling it while it's painless is the best practice.",
  "summary": "Hey all 👋 Short episode. Painful episode. The kind where the call is coming from inside the house, the house is the control plane, and nobody inside the house is allowed to answer the phone. Fresh rebuild, Flux repo ready, and I did the responsible thing: enabled RBAC while the cluster was empty. Every best-practices doc agrees — turn on authorization early, before workloads exist, while it's…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}