# Who's Allowed to Talk to What: Identity and Access in the Homelab

> VLANs decide which networks can talk. They say nothing about which people can. Part 5 of the homelab series: a central identity service in its own VM, Tailscale as the front door, and why the break-glass path matters more than the lock.

URL: https://harshith.in/blog/homelab-identity-and-access/
Author: Harshith Sunku (Staff Engineer) — https://harshith.in/about/
Tags: networking, security, systems
Series: [The Homelab](https://harshith.in/series/homelab/) (part 5 of 5)

The problem announced itself the day the third self-hosted service asked
me to create its fourth local admin account. Every service wanted its own
users, its own passwords, its own idea of who I am — and every one of
those accounts was an orphan credential I would forget to rotate and
forget to delete. Meanwhile the network side looked *done*:
[part 1](https://harshith.in/blog/homelab-proxmox-zfs-lxc/) had carved everything into VLANs
by trust. But segmentation answers *which segments can exchange packets*
and quietly dodges the harder question: **which people and devices are
allowed to do what**. A VLAN doesn't know who you are. If your security
model ends at segmentation, anyone with a foothold in the right subnet
inherits everything that subnet can reach — perimeter thinking, and it
fails the same way at home as it does in companies. All shell, no bones.

What I tried first was what everyone tries first: keep minting local
accounts and keep a mental map of them. That scales to about three
services. The fix the lab taught me is the same one enterprises pay real
money for — identity as its own layer, with one place accounts are born
and one place they die.

## Identity gets its own machine — and its own segment

User accounts, groups, and authentication now live in a dedicated
identity appliance. It's one of the few [VMs rather than
containers](https://harshith.in/blog/homelab-proxmox-zfs-lxc/) in the lab, and it sits in its
own VLAN, because the identity service is the *root of trust*: compromise
it and every downstream permission is fiction. The isolation calculus that
felt like overkill for a media server is the bare minimum here — a full
kernel boundary, a segment nothing else shares, and the management plane
unreachable from anything untrusted.

Centralizing identity sounds like enterprise ceremony for a house, right
up until you've lived the local-admin-account treadmill. One directory,
one place accounts are born, one place they die.

## Tailscale is the front door

Remote access is where identity and networking actually meet. Nothing in
the lab is port-forwarded; the way in is Tailscale — WireGuard underneath,
but the part that matters here is *who* a connection is, not just where
it's from:

- **Nodes authenticate as identities, not addresses.** A device joins the
  mesh by logging in; access follows the login. Lose a laptop and you
  revoke the *device*, not re-key a VPN and re-distribute configs.
- **ACLs are policy as code.** "This user's devices may reach the
  hypervisor's management interface; that tagged node may reach only the
  reverse proxy." It's a reviewable text file, not a pile of firewall
  rules re-derived from memory.
- **Keys expire.** Access defaults to decaying unless renewed, which is
  the correct default for anything you'll otherwise forget about.

The mental shift: the VPN isn't a tunnel into a trusted network — it's a
per-device, per-identity grant. Being "on the network" stops being a
permission by itself.

*[Diagram: Identity-checked front door, with a break-glass path around it]*

Public exposure follows the same scoping logic. The [Cloudflare Tunnel
from part 1](https://harshith.in/blog/homelab-proxmox-zfs-lxc/) publishes *specific services*,
not a network: an outbound connection carries named hostnames to a
container behind the reverse proxy, and the blast radius of "public" ends
at those hostnames. Public ≠ LAN. (This blog dodges the question entirely —
it's [static files on a CDN](https://harshith.in/blog/how-this-blog-runs-for-0/) and touches
none of this.)

## Design for the day identity is down

Here's the failure I almost built for myself: the identity VM goes down,
and every login in the lab depends on it — including, if you're careless,
the login you'd use to *fix the identity VM*. A circular dependency,
waiting to be discovered at the worst time. This is the same lesson [the
wake-on-LAN gateway](https://harshith.in/blog/waking-the-lab-esp32-mqtt-wol/) taught me at
the power layer: **recovery paths must not depend on the thing being
recovered.**

So the lab keeps deliberate break-glass paths: a local root credential on
the hypervisor that lives in a password manager and nowhere on the
network, and console access that works when SSO doesn't. The test that
matters isn't "can I log in" — it's "can I log in *while the directory is
off*." I ran that drill on purpose before I needed it, and I recommend
the experience: a lock you can't open in a power cut isn't security, it's
a lockout.

## Takeaways

- Segmentation controls which networks talk; identity controls which
  people and devices do. You need both — a VLAN doesn't know who you are.
- Centralize accounts in one directory, isolate it like the root of trust
  it is (own VM, own segment), and stop minting local admins.
- Prefer identity-based mesh access (Tailscale ACLs, expiring keys,
  per-device revocation) over network-based trust. "On the VPN" should
  not mean "allowed."
- Expose services, never networks: scope public tunnels to named
  hostnames.
- Keep a tested break-glass path that works with identity down — the
  recovery rule from part 4, applied to logins. Drill it before you
  need it.