Access Control Policy

• No network is trusted by virtue of its location. Every request is authenticated regardless of origin.
• Identity is centralized. Access is granted to an authenticated identity, not to an IP address, a shared password, or a long-lived static token.
• Privilege is the minimum that makes the function work, and is scoped to a single system wherever the tooling allows it.
• Access is revocable at one point of control, so removal is immediate and complete rather than a checklist across many systems.

There is no trusted internal network. Hosts do not grant access based on being on the same subnet, and being inside the perimeter conveys no privilege on its own.

• All inter-host and administrative traffic travels over a private WireGuard network (Tailscale). Every device must be individually enrolled and authenticated before it can route, and device authorization is independent of any credential presented later.
• Only one host publishes ports to the public internet, limited to those needed to serve web and mail traffic. Every other service is reachable only across the private network.
• Public web services terminate at a single reverse proxy. Applications that support it sit behind a single sign-on forward-auth layer, so an unauthenticated request is rejected at the edge before it reaches the application.
• Administrative access to hosts requires a public key held only on an enrolled device. Password authentication and interactive root login over SSH are disabled.
• Automation authenticates with its own scoped credentials rather than reusing an operator session. Each host holds a read-only deploy key valid for its own repository alone, so a compromised host cannot write to source control or read another host configuration.
• Physical location is explicitly not a control. Two hosts sit on a residential network whose other devices are treated as untrusted, and one of them is reachable only over the private network by design.

Identity is consolidated into a self-hosted Authentik instance, which is the single point at which access is granted and removed for the services that support federated login.

Authorization is expressed as group membership in the identity provider rather than per-application user lists. Applications that carry their own login instead of federating are treated as exceptions under section 8 and are required to enforce multi-factor authentication locally.

• Multi-factor authentication is required on every account that can reach a production system or its data. This covers the hosting provider, the DNS and CDN provider, source control, the private network provider, the secrets manager, and the identity provider itself.
• Applications that hold financial data require a second factor before any authenticated page is reachable, including the screen from which a bank connection is initiated. Time-based one-time passcodes and WebAuthn are both supported.
• Host access uses public key cryptography. Passwords are not an accepted factor for SSH on any host.
• Shared accounts are not used. Each principal, human or automated, authenticates as itself.

Automation runs with credentials narrower than the operator holds. Three patterns are used consistently:

• Deploy keys are per-host and read-only. A host can fetch the configuration that defines it and nothing else. None can push.
• The secrets manager identity used by deployment automation has read permission only, scoped to the environment it renders.
• Services that need to observe the container runtime receive a filtered, read-only socket proxy rather than the Docker socket itself, with write operations refused at the proxy.

Privilege escalation on hosts is explicit. Automation declares where root is required rather than running everything elevated by default.

No credential is committed to source control. Secrets live in the self-hosted secrets manager and are rendered onto hosts at deploy time, so the deployed state is reproducible without the repository ever containing a secret. Credentials are rotated on suspected disclosure, on device loss, and whenever a system that could read them is rebuilt.

One deliberate exception is recorded here rather than hidden: keys whose rotation would render existing encrypted data unreadable are treated as permanent for the life of that data, and are protected by the controls above rather than by rotation.

Access is reviewed on a fixed schedule, not only when something changes. Each review is a deliberate pass, and the effective date on this page is advanced when one is completed.

Continuous monitoring supplements these scheduled passes. Authentication events and administrative access are logged centrally, and a host-based intrusion detection system evaluates those logs and blocks malicious sources automatically.

There are no employees, contractors, or additional users, so there is no joiner or leaver population and no transfer process between roles. The equivalent control, and the one that actually matters here, is immediate revocation of a device or credential that should no longer have access. That is treated as the de-provisioning process and is exercised the same way a departure would be.

• Revocation is centralized. Removing a device from the private network provider withdraws its network access immediately, and disabling an account at the identity provider withdraws application access across every federated service at once. Neither requires touching individual hosts.
• Loss or decommissioning of a device triggers, without waiting for a scheduled review: removal of the device from the private network, revocation of its SSH public key, invalidation of active sessions at the identity provider, and rotation of any secret the device could read.
• Automation credentials are revoked by deleting the machine identity or deploy key at its issuer, which is a single action per credential and takes effect on the next request.
• Should the deployment ever gain an additional user, the account is created at the identity provider with group-based authorization only, and no local application account is issued. Removal is then a single action at that provider.
• Registration on self-hosted applications is closed. New accounts cannot be self-created; they exist only if I create them deliberately.

Some self-hosted applications carry built-in authentication rather than federating to the identity provider, usually because the upstream project does not support it cleanly. Those are permitted only where the application enforces multi-factor authentication itself, keeps registration closed, and is covered by the same network controls as everything else. Exceptions are recorded in the infrastructure repository alongside the service they apply to, not tracked separately, so an exception cannot outlive the service that needed it.

This policy is reviewed annually and whenever access architecture changes materially, whichever comes first. It sits under the Information Security Policy.