Éin labbserver, tre tillitsroller, éitt feildomene

Alt fungerer heilt til byggjekøyraren treng den same vertssokkelen som VPN-gjesten brukar, og då kan ingen forklare kvifor ein jobb kan lese nøklane til gatewayen. Alt vart installert på éin maskin fordi det passa, og kvar gjest fekk brei tilgang fordi det var den snøggaste vegen til å få det til å virke. Resultatet er ein vert der tillitsgrensa er straumkabelen. Å dele opp rollene krev mindre arbeid enn det høyrest ut som, og det byrjar med å gje dei namn.

Tre roller som i dag deler alt

Ein VPN-inngang, ei gruppe private tenester og ein byggjekøyrar vil ha ulike ting. Den fyrste treng ein offentleg port og eit smalt nett på den private sida. Den andre treng varig lagring og løyndomar for applikasjonen. Den tredje køyrer kode som nokon andre har skrive.

Det at alle tre får same tilgang er det som gjer symptomet forvirrande, for då kan kven som helst av dei påverke dei andre. Ein byggjobb som kan nå hypervisor-sokkelen, er ein jobb som kan stoppe VPN-en. Ein tenestegjest med rute til styringsnettet kan endre konfigurasjonen av brytaren. Det er privilegia som er problemet, og prosesslista er berre der det kjem til syne. Å namngje rollene fyrst gjev kvart privilegium ein stad å bu.

Skissa nedanfor er eit startpunkt for den delinga, ikkje eit løfte om høg tilgjenge. Behandle ho som ein hypotese du skal prøve, ikkje som det ferdige designet.

Del tre roller, ikkje tre prosessar

Tre gjester på éin vert gjev tre privilegiumssett og tre nettposisjonar. Dei gjev ikkje tre feildomenet, og designet bør seie det høgt.

Skiljet hjelper berre om ein kompromittert gjest ikkje automatisk gjev dei andre tilgang, og det er ei hypervisor-innstilling, ikkje ein navnekonvensjon. Å kalle ein VM for gateway hindrar ikkje ein annan gjest i å nå verten. Les konfigurasjonen av den virtuelle brytaren i staden for vertsnamnet, og stadfest deretter at kvar gjest står der du trur ho står.

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

Skriv ned topologien og stadfest han med verktøya som eig han. Ein gjest som dukkar opp på feil brue er eit funn, ikkje ein detalj. Retta nettet før du endrar nokon tenestekonfigurasjon.

Lat VPN-gjesten opne berre dei dørene ho eig

Publiser tunnelporten i rutaren og ingenting anna. Administrasjonsportar for gjester høyrer på ein styringsveg, ikkje på internett, og grensesnittet til hypervisoren høyrer òg dit.

Nettet på den private sida bør nå tenestene som fjernbrukarane treng, og stoppe der. Autentisering i applikasjonen skal stå på, for ein tunnel er transport og ikkje innlogging. Hald rutetabellen til VPN-gjesten så liten at du kan skildre han i éi setning. Klara du ikkje å skildre han så enkelt, er grensa alt blitt uklar.

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

Alt som lyttar på verten og ikkje trengst for styring, bør ikkje lytte i det heile. Det gjeld hypervisor-API-et, som det er lett å la stå ope på eit offentleg grensesnitt.

Byggjobbar treng ein annan type grense

Ein CI-jobb køyrer kommandoar som repositoriet styrer, så tilliten hans avheng av kven som kan pushe kode. Ein shell-utøvar køyrer desse kommandoane som brukaren til køyraren på verten, og det er den vidaste grensa som finst.

Container-utøvarar er smalare, og ein privilegert container er ikkje ein av dei smale. Hald køyraren i sin eigen gjest med sitt eige nettverksomfang, og gje han berre den tilgangen til artefakt og utrulling som jobbane treng. Einbruksarbeidarar reduserer lagra tilstand; dei reduserer ikkje rekkevidde eller eksponering av løyndomar. Båe desse treng framleis klare grenser.

Tenestegjesten eig dataa, så det er hans sikkerheitskopiplan som må verke. Hald repositorium, opplastingar og databasen i same tidsplan. Test ein gjenoppretting i staden for å lese statusen på jobben.

Planlegg for feilen alle tre deler

Éin vert er éitt feildomene. Ein omstart fjernar tunnelen og kvar privat teneste i same augneblink, og det er nettopp då ein veg inn tel mest.

Hald på konsolltilgang som ikkje avheng av VPN-gjesten, anten det er ein fysisk konsoll, eit administrasjonsgrensesnitt utanfor bandet eller ein konsoll hjå leverandøren. Eit snapshot lagra på same disk er ikkje ein sjølvstendig kopi, og det er ikkje ein sikkerheitskopi som køyrer inne i gjesten han verner. Test så kaldstart som ein rekkjefølgje og ikkje som ei sjekkliste: vert, virtuelle nett, tunnelveg og éin namngjeven applikasjon under ein vanleg konto.

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'

Rekkjefølgja på prosessoppstart provar ingenting om ruter og DNS, så test vegen og ikkje tilstanden til einingane. Det er vegen ein fjernbrukar faktisk treng.