Én labbserver, tre tillitsroller, ett feildomene

Alt fungerer helt til byggkjøringsmaskinen trenger den samme vertssokkelen som VPN-gjesten bruker, og da kan ingen forklare hvorfor en jobb kan lese nøklene til gatewayen. Alt ble installert på én maskin fordi det passet, og hver gjest fikk bred tilgang fordi det var den raskeste måten å få det til å virke på. Resultatet er en vert der tillitsgrensen er strømkabelen. Å dele opp rollene krever mindre arbeid enn det høres ut som, og det begynner med å gi dem navn.

Tre roller som i dag deler alt

En VPN-inngang, et sett private tjenester og en byggkjøringsmaskin vil ha ulike ting. Den første trenger en offentlig port og et smalt nett på den private siden. Den andre trenger varig lagring og hemmeligheter for applikasjonen. Den tredje kjører kode som noen andre har skrevet.

At alle tre får samme tilgang er det som gjør symptomet forvirrende, for da kan enhver av dem påvirke de andre. En byggejobb som kan nå hypervisor-sokkelen, er en jobb som kan stoppe VPN-en. En tjenestegjest med rute til styringsnettet kan endre konfigurasjonen av svitsjen. Det er privilegiene som er problemet, og prosesslisten er bare der det viser seg. Å navngi rollene først gir hvert privilegium et sted å bo.

Skissen nedenfor er et startpunkt for den delingen, ikke et løfte om høy tilgjengelighet. Behandle den som en hypotese du skal prøve, ikke som det ferdige designet.

Del tre roller, ikke tre prosesser

Tre gjester på én vert gir tre privilegiesett og tre nettposisjoner. De gir ikke tre feildomener, og designet bør si det høyt.

Skillet hjelper bare hvis en kompromittert gjest ikke automatisk gir de andre tilgang, og det er en hypervisor-innstilling, ikke en navnekonvensjon. Å kalle en VM for gateway hindrer ikke en annen gjest i å nå verten. Les konfigurasjonen av den virtuelle svitsjen i stedet for vertsnavnet, og bekreft deretter at hver gjest står der du tror den 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 bekreft den med verktøyene som eier den. En gjest som dukker opp på feil bro er et funn, ikke en detalj. Rett nettet før du endrer noen tjenestekonfigurasjon.

La VPN-gjesten åpne bare dørene den eier

Publiser tunnelporten i ruteren og ingenting annet. Administrasjonsporter for gjester hører hjemme på en styringsvei, ikke på internett, og grensesnittet til hypervisoren hører også dit.

Nettet på den private siden bør nå tjenestene fjernbrukerne trenger, og stoppe der. Autentisering i applikasjonen skal stå på, for en tunnel er transport og ikke innlogging. Hold rutetabellen til VPN-gjesten så liten at du kan beskrive den i én setning. Klarer du ikke å beskrive den så enkelt, er grensen allerede blitt uklar.

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

Alt som lytter på verten og ikke trengs for styring, bør ikke lytte i det hele tatt. Det gjelder hypervisor-API-et, som det er lett å la stå åpent på et offentlig grensesnitt.

Byggejobber trenger en annen type grense

En CI-jobb kjører kommandoer som repositoriet styrer, så tilliten avhenger av hvem som kan pushe kode. En shell-utfører kjører disse kommandoene som brukeren til kjøringsmaskinen på verten, og det er den videste grensen som finnes.

Container-utførere er smalere, og en privilegert container er ikke en av de smale. Hold kjøringsmaskinen i sin egen gjest med sitt eget nettverksomfang, og gi den bare den tilgangen til artefakter og utrulling som jobbene trenger. Engangsarbeidere reduserer lagret tilstand; de reduserer ikke rekkevidde eller eksponering av hemmeligheter. Begge disse trenger fortsatt klare grenser.

Tjenestegjesten eier dataene, så det er dens sikkerhetskopiplan som må virke. Hold repositorier, opplastinger og databasen i samme tidsplan. Test en gjenoppretting i stedet for å lese statusen på jobben.

Planlegg for feilen alle tre deler

Én vert er ett feildomene. En omstart fjerner tunnelen og hver privat tjeneste i samme øyeblikk, og det er nettopp da en vei inn betyr mest.

Behold konsolltilgang som ikke avhenger av VPN-gjesten, enten det er en fysisk konsoll, et administrasjonsgrensesnitt utenfor båndet eller en konsoll hos leverandøren. Et øyeblikksbilde lagret på samme disk er ikke en uavhengig kopi, og det er heller ikke en sikkerhetskopi som kjører inne i gjesten den beskytter. Test så kaldstart som en rekkefølge og ikke som en sjekkliste: vert, virtuelle nett, tunnelvei og én navngitt applikasjon under en vanlig 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'

Rekkefølgen på prosessoppstart beviser ingenting om ruter og DNS, så test veien og ikke tilstanden til enhetene. Det er veien en fjernbruker faktisk trenger.