Én labserver, tre tillitsroller, ett feildomen

Alt virker til bygg-runneren trenger samme vertssocket 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. Resultatet er en vert der tillitsgrensen er strømkabelen. Å skille rollene er mindre arbeid enn det høres ut som, og det begynner med å gi dem navn.

Tre roller som for tiden deler alt

En VPN-inngang, et sett private tjenester og en bygg-runner vil ha forskjellige ting. Den første trenger en offentlig port og et smalt nettverk på den private siden. Den andre trenger vedvarende lagring og applikasjonshemmeligheter. Den tredje kjører kode som noen andre har skrevet.

Det er nettopp det at alle tre får samme tilgang som gjør symptomet forvirrende, fordi hvilken som helst av dem da kan påvirke de andre. En byggejobb som kan nå hypervisor-socketen, er en jobb som kan stoppe VPN-en. En tjenestegjest med rute til administrasjonsnettet kan endre svitsjkonfigurasjonen. Rettighetene er problemet, og prosesslisten er bare stedet der det vises. Å navngi rollene først gir hver rettighet et sted å bo.

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

Skill tre roller, ikke tre prosesser

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

Delingen hjelper bare hvis et kompromiss i én gjest ikke automatisk gir de andre rettigheter, og det er en hypervisor-innstilling, ikke en navnekonvensjon. Å kalle en VM for gateway hindrer ikke en annen gjest i å nå verten. Les konfigurasjonen til den virtuelle svitsjen i stedet for vertsnavnet, og bekreft deretter at hver gjest sitter der du tror.

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 verifiser den deretter 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 på ruteren og ingenting annet. Administrasjonsporter for gjester hører til på en administrasjonsvei, ikke på internett, og hypervisorens eget grensesnitt hører også til der.

Nettet på den private siden bør nå tjenestene fjernbrukere trenger, og stoppe der. Applikasjonsautentisering blir stående på, fordi en tunnel er transport og ikke en innlogging. Hold rutetabellen til VPN-gjesten liten nok til å beskrives i én setning. Hvis du ikke kan 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 administrasjon, bør ikke lytte i det hele tatt. Det inkluderer 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 kontrollerer, så tilliten avhenger av hvem som kan pushe kode. En skallkjøring kjører disse kommandoene som runnerens bruker på verten, og det er den bredeste grensen som finnes.

Containerkjøringer er smalere, og en privilegert container er ikke en av de smale. Hold runneren i sin egen gjest med sitt eget nettverksomfang, og gi den bare den artefakt- og distribusjonstilgangen jobbene trenger. Engangsarbeidere reduserer lagret tilstand; de reduserer ikke rekkevidde eller eksponering av hemmeligheter. Begge deler trenger fortsatt tydelige grenser.

Tjenestegjesten eier dataene, så sikkerhetskopiplanen dens er den som må virke. Hold repositorier, opplastinger og databasen i samme tidsplan. Test en gjenoppretting i stedet for å lese jobbstatusen.

Planlegg for feilen alle tre deler

Én vert er ett feildomen. 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 out-of-band-administrasjonsgrensesnitt eller en leverandørkonsoll. Et øyeblikksbilde lagret på samme disk er ikke en uavhengig kopi, og en sikkerhetskopi som kjører inne i gjesten den beskytter, er det heller ikke. Test deretter kaldstart som en sekvens og ikke som en sjekkliste: vert, virtuelle nettverk, tunnelsti 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å prosessstarter beviser ingenting om ruter og DNS, så test stien i stedet for enhetstilstandene. Stien er det en fjernbruker faktisk trenger.