How Albgott decides who gets in.
What a connection has to get through before it reaches anything. /system covers what's deployed; this page covers who's allowed to touch it, and what isn't finished yet.
The default posture
Everything on this page is a variation of one rule: traffic between my networks is denied by default, and every exception is a named rule on the MikroTik with a source, a destination and a port. Two machines being on "internal" networks doesn't let them talk. A rule for that exact flow does.
The router protects itself the same way: it only answers the few things it has to, and drops everything else before it gets a chance to matter.
Outbound traffic is the one deliberate exception. My networks can reach the internet freely, because CI needs to pull dependencies and hosts need updates, and keeping an allow-list of every legitimate destination would cost more than it protects. Inbound is a strict allow-list. Outbound isn't, and I know it.
Two machines sharing a network doesn't let them talk. A rule written for that exact flow does.
The MikroTik only sees traffic that crosses between networks, so every host also has its own firewall: the Proxmox firewall for guests, ufw on everything else. And before a host runs anything, it gets the same baseline: key-only SSH, no root login and no password fallback. The full setup is on /operations.
Getting in remotely
Remote access goes through two separate WireGuard tunnels, both terminated on the MikroTik: one for everyday work and one for administering the infrastructure. A connected device never joins a VLAN. It gets an address on a routed overlay, and the firewall filters it like any other network, which means it can treat a laptop on VPN differently from the same laptop plugged in at home.
The split is about who's on the other end. I work with other people, and the work tunnel is how they connect: it reaches internal tools and stops there. The admin tunnel is the only path to the control plane, and no collaborator has it. A compromised device on the work tunnel can't reach a hypervisor console, and that's the whole point of having two.
A peer is a device, not a person. My phone and my laptop are separate peers, each named after the device and its tunnel, so if I lose the phone I revoke one peer and nothing else changes. A peer config is never shared between devices, and a suspected leaked key means a new peer, never the old one reused. Clients use split tunnelling, so only Albgott's networks go through the VPN.
One thing I had to learn by getting it wrong: a successful WireGuard handshake only means the device reached the router. It says nothing about what the device can do next. Each question is answered by a different layer:
| Layer | Decides |
|---|---|
| WireGuard | Whether the device can build the encrypted tunnel at all |
| Client routes (AllowedIPs) | Which destination networks go into the tunnel |
| Router firewall | Which source, destination and port combinations are allowed |
| DNS | Which names resolve to internal addresses |
| Application auth | Whether the person may use the app they reached |
The last row leads into the next section. The VPN puts a device on the right path; the application decides whether the person behind it is who they say they are.
Who you are once you're in
There are two identity providers, and both work today for different reasons. Authentik is the long-term target: eventually everything here should log in through it. Zitadel is there for public apps that need their own users, because it has real multi-tenancy (separate users, projects and settings per organisation) built in from the start.
What's still in progress is which services actually sit behind Authentik SSO. Today it's the observability stack, with MFA through an authenticator app. The rest isn't only a matter of time: some services only offer SSO in their paid tier, which slows the rollout down for reasons I don't control. Identity here works and is unfinished at the same time.
| Service | What it is | Reached via | Status |
|---|---|---|---|
| Authentik | Main identity provider, the long-term target for everything | Internal proxy only | Live; observability stack today, MFA via authenticator app |
| Zitadel | Second identity provider, multi-tenant, for future public apps | Public proxy | Live; not used in production yet |
Where secrets live
Infisical runs as an internal-only secrets manager. The goal is simple: stop keeping credentials in plaintext inside config and compose files spread across hosts, and give them one managed home.
The migration is ongoing. First I decide which secrets move; only once Infisical really is the source of truth for them do I change what consumes them. That order matters most in CI, where a mistake hurts the most. The build agents live on their own VLAN and can only reach the few services a deployment actually needs. Nothing lets a compromised build reach the management plane.
Watching for trouble
Security and observability share a stack here: the monitoring described on /operations is also what would notice most access problems first. Uptime Kuma checks endpoints from the outside while Prometheus watches from the inside, so a misconfiguration shows up even if the metrics look fine. Alerts go to one phone. Critical ones fire faster, and warnings for a host are muted while a critical alert for that host is firing, so a real problem is heard once and clearly.
The gap: none of this was designed as security monitoring. It catches a lot as a side effect, and dedicated security alerting is on the roadmap.
What's still open
The gaps from the sections above, in one place:
There are no off-node backups yet, so rebuilding a compromised host would mean reconstructing it from the docs, not restoring a known-good copy. Tracked on /operations.
Authentik and Zitadel both work, but not every service logs in through them yet. I'm moving them over one at a time.
Infisical is running, but some credentials still live in config files on hosts, which is exactly what Infisical is there to replace.
General observability is in place and useful, but alerting designed specifically for security is still on the roadmap.
Next: /system covers what's deployed, and /operations covers how it's kept running.