Think Like a CISO: Access Control — Who Has the Keys?

You set up your homelab, created an SSH key, copied it everywhere, and never thought about it again. You have a root password that works on every node. Your API tokens live in shell scripts, and sudo doesn't ask questions. Sound familiar?

In an enterprise, this would be a career-ending audit finding. In your homelab, it's Tuesday. But the risks are real — and the fixes are straightforward. This is where a CISO mindset makes the biggest difference: access control isn't glamorous, but it's the foundation everything else rests on.

The "I'm the Only Admin" Fallacy

"Why bother with access control? I'm the only one using this."

This is the most dangerous assumption in homelab security. Access control isn't just about keeping other people out. It's about:

Limiting blast radius — if one service is compromised, can it reach everything?
Preventing accidents — a mistyped command in a root shell can destroy data
Maintaining accountability — when something breaks, can you trace what changed?
Protecting against credential theft — if malware runs on your workstation, what can it reach?

You're not just one admin. You're one admin with dozens of service accounts, API tokens, SSH keys, and automated processes — each one a potential attack vector.

Audit What You Have

Before you fix anything, you need to know what exists. Run through this checklist:

SSH keys:

How many keys do you have? Where are they?
Which servers accept which keys?
Do any keys have no passphrase?
When were they last rotated?

User accounts:

What accounts exist on each server? (cat /etc/passwd | grep -v nologin)
Are there accounts you don't recognize or no longer need?
Does anyone (or anything) use shared accounts?

sudo access:

Who has passwordless sudo? (grep NOPASSWD /etc/sudoers /etc/sudoers.d/*)
Is sudo logged?
Are there sudoers entries that are overly broad?

API tokens and service accounts:

Where are API tokens stored? In scripts? Environment variables? Config files?
Do tokens have expiration dates?
Do tokens follow least privilege — or do they have full admin access because it was easier?

Web interfaces:

Which management UIs are accessible, and from where?
Do they use unique, strong passwords?
Is there any multi-factor authentication?

Write it all down. You'll almost certainly find things you forgot about.

SSH: The Front Door

SSH is the primary access method for most homelabs, and it's where the worst habits live.

Use Ed25519 keys, not RSA. Ed25519 is faster, more secure, and produces shorter keys. If you're still using RSA, generate a new key:

ssh-keygen -t ed25519 -C "homelab-$(date +%Y)"

Always use a passphrase. A key without a passphrase is a plaintext credential sitting on your disk. Use ssh-agent so you only type it once per session.

One key per purpose. Don't use the same key for your homelab, your GitHub account, and your work servers. If one is compromised, you don't want it opening every door. Shouldn't even have to be said, but you'd be surprised.

Disable password authentication. Once your keys are in place, turn off password auth entirely:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin prohibit-password

Restrict which keys can do what. In authorized_keys, you can limit a key to specific commands or source IPs:

from="192.168.10.0/24",command="/usr/local/bin/backup-script" ssh-ed25519 AAAA... backup-key

This is especially valuable for automated processes — a backup key shouldn't grant an interactive shell.

Sudo: Earned, Not Given

NOPASSWD: ALL in sudoers is the homelab equivalent of giving every employee the master key to the building. It's convenient, and it's a terrible idea.

Require a password for sudo. Yes, it's slightly annoying. It's also a speed bump that prevents automated processes and compromised sessions from immediately escalating to root.

Scope sudo to specific commands. If a service only needs to restart nginx, don't give it full sudo:

service-account ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

Use separate service accounts. Don't run everything as your personal user. Create purpose-specific accounts with limited privileges:

useradd -r -s /usr/sbin/nologin -d /opt/myservice myservice

Log everything. Make sure sudo logging is enabled (it usually is by default). When something goes wrong, you'll want to see exactly which commands were run and by whom.

API Tokens: The Forgotten Credentials

API tokens are the silent sprawl of most homelabs. You create them for a quick test, paste them into a script, and forget they exist. Six months later, that token still has full admin access to your hypervisor.

Least privilege, always. When creating a token, give it only the permissions it needs. A monitoring token doesn't need write access. A CI/CD token doesn't need to manage users.

Set expiration dates. Most platforms support token expiry. Use it. A token that expires in 90 days forces you to rotate it — which means you'll also notice if the service using it is still needed.

Store tokens in a secrets manager. Not in scripts, not in environment files committed to git, not in .bashrc. Use OpenBAO, Vault, or at minimum a file with restricted permissions that's excluded from version control.

Inventory your tokens. For each service you use, check what tokens exist:

Proxmox: Datacenter → Permissions → API Tokens
Gitea: Settings → Applications
Grafana: Administration → Service accounts

Delete anything you don't recognize or no longer need.

Network-Level Access Control

Authentication isn't the only layer. Network segmentation is access control too.

Management interfaces on a separate VLAN. Your Proxmox UI, switch management, IPMI/iDRAC — these should not be on the same network as your IoT devices or guest WiFi.

Firewall rules for management access. Only allow SSH, HTTPS management, and API access from your trusted network segments. Deny by default.

No management from the internet. If you need remote access, use a VPN. Port-forwarding your Proxmox UI is not remote access — it's an open invitation.

Automation: The Discipline Multiplier

Manual access control doesn't scale, even in a homelab. You'll forget to rotate a key, miss a stale account, or leave a token active longer than intended.

Infrastructure as Code for access. Define your SSH keys, firewall rules, and user accounts in Terraform or Ansible. When access is defined in code, it's reviewable, auditable, and reproducible.

Automate credential rotation. Even a simple cron job that reminds you to rotate keys every 6 months is better than never rotating them.

Centralize authentication where possible. If you're running enough services, consider a central identity provider. Even something lightweight like Authelia or LLDAP reduces credential sprawl.

A Practical Starting Point

You don't need to fix everything at once. Here's a priority order:

1. Audit — list every account, key, and token you have
2. Disable what's unused — delete stale accounts, revoke old tokens
3. Add passphrases to SSH keys — regenerate any that don't have one
4. Move secrets out of scripts — into a secrets manager or at minimum restricted files
5. Scope sudo — replace NOPASSWD: ALL with specific commands where possible
6. Segment management access — firewall rules limiting who can reach admin interfaces

Each of these is a one-time effort that permanently reduces your attack surface.

It's About Intentionality

Access control isn't about making your homelab harder to use. It's about making deliberate decisions about who and what can do things — instead of letting access accumulate by accident.

A CISO doesn't aim for zero access. They aim for the right access — granted explicitly, scoped narrowly, reviewed regularly, and revoked promptly. That's the standard your homelab deserves.

Who has the keys to your infrastructure? If you can't answer that question in under a minute, it's time to find out.