Homelab

This directory contains the files that compose my homelab.

Map of Contents

Project	Summary	Path
barbarian	Documentation and scripts for the `barbarian` TrueNAS host	`barbarian`
docs	Standalone documentation for architecture and procedure	`docs`
druid	Docker compose files and documentation for the `druid` cloud compute host	`druid`
fighter	Docker compose configuration, documentation, and scripts related to the `fighter` local compute host	`fighter`
monk	Documentation for the `monk` TrueNAS host	`monk`
paladin	Documentation for the `paladin` TrueNAS host	`paladin`
sellswords	Documentation and Terraform configuration files for cloud vendors such as AWS and Cloudflare	`sellswords`
silver-hand	Documentation and Terraform configuration for the `silver-hand` local Kubernetes cluster	`silver-hand`
stacks	Maximally independent Docker compose files for various services	`stacks`
wizard	Documentation, configuration, and scripts for the `wizard` VyOS host	`wizard`

Configure a New Host

NixOS

Download the NixOS ISO installer.
Refer to the NixOS Manual for further instructions.

Security

Below are described the general security principles followed throughout this project:

Never lean on security through obscurity.
Minimize friction induced by security. Friction induces laziness, which inevitably circumvents the original security system.
Understand that security practices cannot eliminate vulnerability of the system, only make it too expensive to attack.
Tie less important secrets to more important secrets, but not vice-versa.

Further, we have some tool-specific guidelines.

Securing SSH

When configuring the SSH server for a local host or VPS, or when provisioning a new SSH keypair.

Generate one private key for each user-machine pair.
Do not automate dissemination of pubkeys. Always install pubkeys manually.
Disable password-based authentication.
Disable root login.

Docker Compose

To write secrets into docker-compose.yml files securely, we use the following env_file snippet:

env_file:
  - path: ./<service>.secrets
    required: true

And we then write the required secrets in dotenv format in a file located at ./<service>.secrets. For example:

API_KEY=zj1vtmUNGIfHJBfYsDINr8AVN5on1Hy0
# ROOT_PASSWORD=changeme
ROOT_PASSWORD=0gavJVrsv89bmdDeJXAcI1eCvQ4Um8Hy

When these files are staged in git, our .gitattributes runs the sops filter against any file matching one of its described patterns.

Web Services

If a service supports OAuth2, we configure Keycloak SSO for that service. When feasible, we shift responsibility for authentication and authorization to Keycloak. This is dependent on each service implementing OAuth2/OpenIDConnect.

If a service does not support OAuth2, but it does support authentication via the X-Forwarded-User header, we use mesosphere/traefik-forward-auth as a Traefik middleware. This middleare restricts access to the service regardless of whether the service understands the X-Forwarded-User header, which makes it useful for compatible multi-user applications and single-user applications.

If a service should not be internet-accessible, we use Traefik's ipWhiteList middleware to restrict access to LAN IPs only.

Else, some services absolutely require separate authentication (e.g. Plex, N8n). In such cases, we create user credentials as we would for any internet service; using our password manager.

4.1 KiB Raw Blame History