Jeden laboratorní server, tři role důvěry, jedna doména selhání

Všechno funguje, dokud běžec sestavení nepotřebuje stejný soket hostitele, který používá host VPN, a pak nikdo nedokáže vysvětlit, proč úloha může číst klíče brány. Všechno bylo nainstalované na jednom stroji, protože se to vešlo, a každý host dostal široký přístup, protože to byl nejrychlejší způsob, jak to rozchodit. Výsledkem je hostitel, jehož hranicí důvěry je napájecí kabel. Rozdělit role dá méně práce, než to zní, a začíná to jejich pojmenováním.

Tři role, které zatím sdílejí všechno

Vstup VPN, sada soukromých služeb a běžec sestavení chtějí různé věci. První potřebuje veřejný port a úzkou síť na soukromé straně. Druhý potřebuje trvalé úložiště a tajemství aplikace. Třetí spouští kód, který napsal někdo jiný.

Právě to, že všechny tři mají stejný přístup, dělá symptom matoucím, protože pak kterýkoli z nich může ovlivnit ostatní. Úloha sestavení, která dosáhne na soket hypervizoru, je úloha, která může zastavit VPN. Host služeb s cestou do řídicí sítě může změnit konfiguraci přepínače. Oprávnění jsou problém a seznam procesů je jen místo, kde se to projeví. Pojmenovat role jako první dá každému oprávnění místo, kde může žít.

Náčrt níže je výchozí bod pro toto rozdělení, ne slib vysoké dostupnosti. Berte ho jako hypotézu k ověření, ne jako hotový návrh.

Rozdělte tři role, ne tři procesy

Tři hosté na jednom hostiteli dávají tři sady oprávnění a tři síťové pozice. Nedávají tři domény selhání a návrh by to měl říct nahlas.

Rozdělení pomůže jen tehdy, když kompromitace jednoho hosta automaticky nedá oprávnění ostatním, a to je nastavení hypervizoru, ne konvence pojmenování. Pojmenovat VM jako bránu nezabrání jinému hostu dosáhnout hostitele. Čtěte konfiguraci virtuálního přepínače místo názvu hostitele a pak potvrďte, že každý host sedí tam, kde si myslíte.

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

Zapište topologii a pak ji ověřte nástroji, které ji vlastní. Host, který se objeví na špatném mostu, je zjištění, ne detail. Opravte síť dřív, než změníte jakoukoli konfiguraci služby.

Nechte hosta VPN otevřít jen dveře, které vlastní

Zveřejněte port tunelu na routeru a nic jiného. Správní porty hostů patří na řídicí cestu, ne na internet, a vlastní rozhraní hypervizoru tam patří taky.

Síť na soukromé straně by měla dosáhnout na služby, které vzdálení uživatelé potřebují, a tam skončit. Ověřování aplikace zůstává zapnuté, protože tunel je transport, ne přihlášení. Držte směrovací tabulku hosta VPN dost malou, aby se dala popsat jednou větou. Pokud ji tak jednoduše popsat nedokážete, hranice se už rozmazala.

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

Cokoli na hostiteli naslouchá a není potřeba pro správu, by nemělo naslouchat vůbec. Patří sem API hypervizoru, které je snadné nechat vystavené na veřejném rozhraní.

Úlohy sestavení potřebují jiný druh hranice

Úloha CI spouští příkazy řízené repozitářem, takže její důvěra závisí na tom, kdo může tlačit kód. Shellový vykonavatel spouští tyto příkazy jako uživatel běžce na hostiteli, a to je nejširší dostupná hranice.

Vykonavatelé kontejnerů jsou užší a privilegovaný kontejner mezi ty úzké nepatří. Držte běžce ve vlastním hostu s vlastním síťovým rozsahem a dejte mu jen přístup k artefaktům a nasazení, který úlohy potřebují. Jednorázoví pracovníci snižují uchovávaný stav; nesnižují dosažitelnost ani vystavení tajemství. Obě věci stále potřebují výslovné limity.

Host služeb vlastní data, takže jeho plán zálohování je ten, který musí fungovat. Držte repozitáře, nahrávání a databázi ve stejném rozvrhu. Testujte obnovu místo čtení stavu úlohy.

Plánujte selhání, které sdílejí všichni tři

Jeden hostitel je jedna doména selhání. Restart odstraní tunel a každou soukromou službu ve stejný okamžik, a to je přesně chvíle, kdy cesta dovnitř záleží nejvíc.

Zachovejte přístup ke konzoli, který nezávisí na hostu VPN, ať už je to fyzická konzole, mimosíťové rozhraní pro správu nebo konzole poskytovatele. Snímek uložený na stejném disku není nezávislá kopie, a záloha, která běží uvnitř hosta, kterého chrání, také ne. Pak testujte studený start jako sled, ne jako kontrolní seznam: hostitel, virtuální sítě, cesta tunelu a jedna pojmenovaná aplikace pod běžným účtem.

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

Pořadí startů procesů nic nedokazuje o trasách a DNS, takže testujte cestu, ne stavy jednotek. Cesta je to, co vzdálený uživatel skutečně potřebuje.