Yksi laboratoriopalvelin, kolme luottamusroolia, yksi vikavyöhyke

Kaikki toimii, kunnes build-runner tarvitsee saman isäntäsoketin, jota VPN-vieras käyttää, ja silloin kukaan ei osaa selittää, miksi työ voi lukea yhdyskäytävän avaimet. Kaikki asennettiin yhdelle koneelle, koska se mahtui, ja jokaiselle vieraalle annettiin laaja pääsy, koska se oli nopein tapa saada se toimimaan. Tuloksena on isäntä, jonka luottamusraja on virtajohto. Roolien erottaminen on vähemmän työtä kuin miltä kuulostaa, ja se alkaa niiden nimeämisestä.

Kolme roolia, jotka jakavat nyt kaiken

VPN-sisäänkäynti, joukko yksityisiä palveluita ja build-runner haluavat eri asioita. Ensimmäinen tarvitsee julkisen portin ja kapean verkon yksityisellä puolella. Toinen tarvitsee pysyvän tallennuksen ja sovelluksen salaisuudet. Kolmas suorittaa koodia, jonka joku muu on kirjoittanut.

Juuri se, että kaikki kolme saavat saman pääsyn, tekee oireesta hämmentävän, koska silloin mikä tahansa niistä voi vaikuttaa toisiin. Build-työ, joka pääsee hypervisorin sokettiin, on työ, joka voi pysäyttää VPN:n. Palveluvieras, jolla on reitti hallintaverkkoon, voi muuttaa kytkimen kokoonpanoa. Oikeudet ovat ongelma, ja prosessilista on vain paikka, jossa se näkyy. Roolien nimeäminen ensin antaa jokaiselle oikeudelle paikan, jossa elää.

Alla oleva luonnos on lähtökohta tälle jaolle, ei lupaus korkeasta käytettävyydestä. Käsittele sitä todennettavana hypoteesina, älä valmiina suunnitteluna.

Erota kolme roolia, älä kolmea prosessia

Kolme vierasta yhdellä isännällä antavat kolme oikeusjoukkoa ja kolme verkkosijaintia. Ne eivät anna kolmea vikavyöhykettä, ja suunnittelun pitäisi sanoa se ääneen.

Erottelu auttaa vain, jos yhden vieraan murto ei automaattisesti anna oikeuksia muille, ja se on hypervisorin asetus, ei nimeämiskäytäntö. VM:n kutsuminen yhdyskäytäväksi ei estä toista vierasta pääsemästä isäntään. Lue virtuaalikytkimen kokoonpano isäntänimen sijaan ja varmista sitten, että jokainen vieras istuu siellä, missä luulet.

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

Kirjoita topologia ylös ja varmista se sitten työkaluilla, jotka omistavat sen. Väärälle sillalle ilmestyvä vieras on löydös, ei yksityiskohta. Korjaa verkko ennen kuin muutat mitään palvelukokoonpanoa.

Anna VPN-vieraan avata vain ne ovet, jotka se omistaa

Julkaise tunneliportti reitittimellä ja ei mitään muuta. Vieraiden hallintaportit kuuluvat hallintapolulle, eivät internetiin, ja hypervisorin oma liitäntä kuuluu sinne myös.

Yksityisen puolen verkon pitäisi tavoittaa palvelut, joita etäkäyttäjät tarvitsevat, ja pysähtyä siihen. Sovelluksen todennus pysyy päällä, koska tunneli on siirtoa eikä kirjautuminen. Pidä VPN-vieraan reititystaulu niin pienenä, että sen voi kuvata yhdellä lauseella. Jos et pysty kuvaamaan sitä niin yksinkertaisesti, raja on jo hämärtynyt.

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

Minkään isännällä kuuntelevan, jota hallintaan ei tarvita, ei pitäisi kuunnella lainkaan. Siihen kuuluu hypervisorin API, joka on helppo jättää avoimeksi julkiselle liitännälle.

Build-työt tarvitsevat erilaisen rajan

CI-työ suorittaa komentoja, joita tietovarasto ohjaa, joten sen luottamus riippuu siitä, kuka voi työntää koodia. Shell-suorittaja ajaa ne komennot runnerin käyttäjänä isännällä, ja se on laajin saatavilla oleva raja.

Konttisuorittajat ovat kapeampia, eikä etuoikeutettu kontti ole niitä kapeita. Pidä runner omassa vieraassaan omalla verkkolaajuudellaan ja anna sille vain se artefakti- ja käyttöönotto-oikeus, jota työt tarvitsevat. Kertakäyttöiset työntekijät vähentävät säilytettyä tilaa; ne eivät vähennä tavoitettavuutta tai salaisuuksien paljastumista. Molemmat tarvitsevat edelleen nimenomaiset rajat.

Palveluvieras omistaa tiedot, joten sen varmuuskopiosuunnitelman on toimittava. Pidä tietovarastot, lataukset ja tietokanta samassa aikataulussa. Testaa palautus sen sijaan, että lukisit työn tilan.

Suunnittele vika, jonka kaikki kolme jakavat

Yksi isäntä on yksi vikavyöhyke. Uudelleenkäynnistys poistaa tunnelin ja jokaisen yksityisen palvelun samalla hetkellä, ja juuri silloin sisäänpääsy merkitsee eniten.

Pidä konsolipääsy, joka ei riipu VPN-vieraasta, olipa se fyysinen konsoli, kaistanulkoinen hallintaliitäntä tai tarjoajan konsoli. Samalla levyllä säilytetty tilannekuva ei ole riippumaton kopio, eikä sellainen ole varmuuskopio, joka ajetaan sen vieraan sisällä, jota se suojaa. Testaa sitten kylmäkäynnistys jaksona, ei tarkistuslistana: isäntä, virtuaaliset verkot, tunnelipolku ja yksi nimetty sovellus tavallisen tilin alla.

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'

Prosessien käynnistysjärjestys ei todista mitään reiteistä ja DNS:stä, joten testaa polku, älä yksiköiden tiloja. Polku on se, mitä etäkäyttäjä todella tarvitsee.