Files

T

History

fix(base): drop dead AUTO_UPDATE knob from base.yml

base.yml set AUTO_UPDATE=1 but never forwarded it to harden-ssh.sh (which
defaults to 0), so base hosts never actually scheduled daily updates despite
the config implying they did. Auto-update is intentionally bastion-only for
now — jumphost.yml / harden-jumphost.sh enable it by default, and base
(container) hosts will get a dedicated docker-image updater later — so remove
the knob entirely rather than wire it through. No behavior change.
Also drop cloud-init/base.yml from the README "Daily updates" line that
claimed it takes AUTO_UPDATE=1.

2026-06-12 17:23:55 -05:00

base.yml

fix(base): drop dead AUTO_UPDATE knob from base.yml

2026-06-12 17:23:55 -05:00

jumphost.yml

feat(firewall): add deny-by-default host firewall (harden-firewall.sh)

2026-06-12 17:06:25 -05:00

README.md

feat(firewall): add deny-by-default host firewall (harden-firewall.sh)

2026-06-12 17:06:25 -05:00

README.md

cloud-init/

Generic, distro-agnostic cloud-init templates for standing up a base host or a bastion from scratch. They run on Alpine, Debian, or Alma — the runcmd prelude detects the package manager and installs bash/git/curl before invoking the scripts.

Template	What it does
`base.yml`	Hostname (per the schema) + shared MOTD + seed root keys from `globals/` + SSH hardening (`harden-ssh.sh`) + deny-by-default host firewall (`harden-firewall.sh`, `ENABLE_FIREWALL=1`).
`jumphost.yml`	Same base, but bastion hardening (`harden-jumphost.sh`) with an `ssh-admins`/`ssh-jumpers` split and a ProxyJump whitelist; same host firewall.

These are for the host itself. To stand up a Docker stack on a host, use the per-deployment cloud-init.yml under deployments/<name>/ instead (those clone the repo and run the stack's deploy.sh).

Usage

Copy the template, fill in REPO_URL, HOST (<svc>-<n>, e.g. sto-1), and the other values at the top of the runcmd block.
Paste it as the instance's user-data when creating the VM.
On first boot the host names itself, installs the MOTD, seeds admin keys from globals/, hardens SSH, and brings up the deny-by-default firewall.

Hostnames follow ../globals/Network Domain Name Schema.md; our VMs skip the region code and use srvno.de as the base.

The harden scripts print a generated root private key to stdout, which lands in the cloud provider's serial/console log. Capture it there, or rely on the keys seeded from globals/authorized_keys (or SSH_KEYS_URL) and ignore it.