Klonování image VPN serveru bez klonování jeho identity

Image se spustí, služba naběhne a klienti se připojí. To je okamžik zastavit se a zeptat se, která ze dvou velmi odlišných operací právě proběhla. Buď kopie obnovuje jednu logickou bránu, která dříve existovala, nebo přidává do flotily druhou bránu. Obě jsou legitimní a mají různé důsledky pro identitu a přístup. Stroj, který čistě naběhne, nedokazuje ani jednu z nich.

Odpověď určují tři podmínky a jsou to tři kbelíky materiálu, které image může nést. Roztřiďte je dřív, než se image vytvoří, ne poté, co byl dvakrát nasazen.

Nejprve rozhodněte, kterou ze dvou operací provádíte

Obnovení zachovává jednu identitu služby. Stará instance je pryč, jméno a certifikát zůstávají a klienti dál důvěřují stejnému koncovému bodu. Přidání vytváří druhou identitu, kterou musí klienti, logy i odvolání rozlišovat.

Rozdíl není kosmetický. Pokud dva živé hostitele představují stejný certifikát brány, klient je nedokáže rozlišit, auditní stopa také ne, a odvolání tohoto certifikátu odstraní oba najednou. To může být přesně to, co chce záměrný návrh vysoké dostupnosti, a jen zřídka to, co zamýšlí ukvapená kopie image.

První rozhodnutí je tedy věta napsaná dřív, než image opustí build hostitele: tato kopie obnovuje bránu A, nebo se tato kopie stává bránou B. Všechno další je účtování proti té větě. Pokud ji nikdo nedokáže napsat, kopie není připravena k sestavení.

Znovupoužitelné vstupy, identita a oprávnění, stav nasazení

Kbelík pro opakované použití je ten snadný: balíčky, revidovaná konfigurace bez tajemství, šablony služeb, nastavení zpevnění. V tom je image skutečně dobrý a lze jej reprodukovat bez omezení.

Kbelík identity a oprávnění je místo, kde se kopie pokazí. Soukromý klíč a certifikát brány identifikují tuto bránu u každého klienta. Podpisový klíč certifikační autority je jiný objekt s jinou mocí: vydává identity. Důvěřovat vydavateli neznamená, že každá nová brána potřebuje schopnost vydávat, a přibalení podpisového klíče do image dává tuto schopnost všemu, co image dokáže přečíst.

Kbelík stavu nasazení je ten, na který lidé zapomínají, protože vypadá jako konfigurace. Adresy pro naslouchání, fondy adres, protlačované trasy, nastavení resolveru a lokální integrace všechny kódují předpoklady o prvním hostiteli. Druhý uzel, který je zkopíruje, může přidělovat z fondu, který už vlastní jiná brána, nebo nasměrovat klienty na prostředek, který existuje jen vedle originálu.

Co musí nový uzel dostat a od koho

Samostatně spravovaný uzel by měl dostat vlastní přihlašovací údaje schváleným procesem registrace, přičemž podpisová operace probíhá tam, kde žije podpisový klíč, ne na novém hostiteli. Zaznamenejte, kterou identitu lze odebrat, aniž by se narušily ostatní uzly; pokud je odpověď „všechny“, má návrh jednu identitu, která předstírá, že jsou dvě.

Síťové hodnoty si zaslouží stejný přístup. Zvolte fond, adresu pro naslouchání a sadu protlačovaných tras, které nekolidují se stávající bránou, a zapište je do vstupů zřizování, ne do image. Vstup je revidovatelný; image ne.

Existuje legitimní mezistav. Podporovaný návrh obnovy nebo replikace může záměrně udržovat jednu logickou identitu služby napříč hostiteli, s řízeným přístupem ke staré kopii a plánem rotace. To je rozhodnutí s vlastníkem, ne výchozí stav, který nastane, protože image byl pohodlný.

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

První příkaz řekne, jakou identitu uzel skutečně představuje a kdo ji podepsal. Druhý je počáteční inventura, ne důkaz: soukromý materiál může žít mimo tento adresář, uvnitř databáze aplikace nebo ve vrstvě snímku, kterou běžící souborový systém už neukazuje.

Co kopie image tiše nese

Smazání souboru z nejnovější revize image jej neodstraní ze starších revizí, mezipamětí vrstev ani snímků pořízených, dokud existoval. Proto se s image nesoucími přihlašovací údaje musí zacházet jako s citlivými objekty po celou dobu jejich života, ne jen v okamžiku sestavení.

Zkontrolujte obsah image a vstupy zřizování jako oddělené otázky. Image odpovídá na „co je uvnitř tohoto artefaktu“, vstupy odpovídají na „čím se tato instance stane při prvním startu“. Čistý image s bootstrap skriptem, který stáhne sdílený klíč, odpovídá na první otázku dobře a na druhou špatně.

Image pro obnovu, které legitimně obsahují tajemství, držte omezené na lidi, kteří je potřebují, a zaznamenejte, kde jsou uloženy. Alternativa, image, který je pohodlný, protože funguje bez jakéhokoli zřizování, je tentýž image, který každému, kdo jej najde, dá identitu brány. Jen jeden z těch dvou úkolů se objeví v build logu.

Vstupní kontroly před produkcí

Než uzel přijme provoz, potvrďte čtyři věci: identitu, kterou představuje, klienty, které přijme, prostředky, ke kterým smí dosáhnout, a zpětnou cestu pro adresy, které rozdává.

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

Pak zkontrolujte negativní případ, který chytá nehody: má nový uzel administrativní nebo klientský přístup, který byl určen pro originál? Kopírovaná konfigurace může nést záznam navíc pro klienta, zděděnou trasu správy nebo direktivu push, která dávala smysl na prvním hostiteli.

Pokud image s živými tajemstvími už opustil schválenou hranici, vyměňte přihlašovací údaje a omezte kopie. Odebrání souboru z posledního buildu není totéž jako vyřazení údajů, které starší kopie stále drží, a mezera mezi těmito dvěma skutečnostmi je přesně to okno, které útočník potřebuje.