Skip to content

Latest commit

 

History

History
70 lines (52 loc) · 4.12 KB

README.md

File metadata and controls

70 lines (52 loc) · 4.12 KB
Raw

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

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.