Hardware & Prerequisites

What you need to buy, plug in, and prepare before a single command is run.

This guide builds a real cluster on real hardware. You don’t need a data center — a single small computer and a USB drive is enough to follow every chapter. But the class of hardware you pick decides which security layers are physically possible, so read this page before you spend any money.

The one rule that decides everything: can it nest a VM?

Layer 1 of this architecture runs k3s inside an immutable virtual machine, so that even a full compromise of Kubernetes is still trapped inside a throwaway VM. That extra wall only exists if your hardware can run a virtual machine that is itself trustworthy. This splits all hardware into two camps.

A Raspberry Pi cannot run a virtual machine inside a virtual machine. The Pi 5’s processor (Cortex-A76) lacks the ARM nested virtualization extension, which only exists on ARMv8.3 and newer. This isn’t a setting you can switch on — the silicon doesn’t have it. On a Pi we therefore drop the VM layer and run the immutable OS directly on the metal. You still get six of the seven layers.

Think of the VM as a sealed glovebox you do risky work inside. A powerful Intel/AMD machine can put a glovebox inside another glovebox. A Raspberry Pi can only give you one glovebox — still good, just one wall fewer.

Two supported hardware classes

gVisor needs a 48-bit address-space kernel. Raspberry Pi OS ships a 39-bit kernel and gVisor will refuse to start. On a Pi, install Ubuntu Server for ARM instead of Raspberry Pi OS if you want the gVisor sandbox in Layer 3. Plain 64-bit Raspberry Pi OS is fine for everything except gVisor.

Recommended shopping list

Class A — the recommended build (full seven layers)

Class B — the Raspberry Pi build (six layers, bare metal)

Do not use a cheap USB flash stick for storage. etcd, container layers, and object storage all write constantly. Consumer flash sticks have no wear levelling for this load and will corrupt within weeks. Use a USB-attached SSD.

Software prerequisites

You will prepare a fresh OS install in Layer 0. Before that, on your admin machine (your laptop), install the client tools you’ll use to drive the cluster:

# kubectl — talk to the cluster
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# helm — install the security add-ons
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# wireguard — the encrypted tunnel you'll use to reach the cluster
sudo apt install -y wireguard            # Debian/Ubuntu

You will never expose the Kubernetes API to the internet. Every kubectl command in this guide travels through a WireGuard tunnel (Layer 4). The cluster’s control port (6443) stays firewalled to the VPN only. Set this expectation now — it shapes every later decision.

Network prerequisites

• A home router you control, ideally able to forward one UDP port for WireGuard.
• A static internal IP (or DHCP reservation) for the host machine.
• Optional: a domain name if you want TLS certificates for any service you expose.

What you’ll have when hardware is ready

A freshly wiped machine of either class, a USB SSD plugged in (still empty — we encrypt it in Layer 5), and an admin laptop with kubectl, helm, and wireguard installed. That’s the starting line. The next chapter covers Layer 0 / Host OS hardening — locking down the base operating system before any Kubernetes component touches it.