Én labserver, tre tillidsroller, ét fejldomæne

Alt virker, indtil build-runneren har brug for den samme værts-socket, som VPN-gæsten bruger, og så kan ingen forklare, hvorfor et job kan læse gatewayens nøgler. Alt blev installeret på én maskine, fordi det passede, og hver gæst fik bred adgang, fordi det var den hurtigste måde at få det til at virke. Resultatet er en vært, hvis tillidsgrænse er strømkablet. At dele rollerne er mindre arbejde, end det lyder, og det starter med at navngive dem.

Tre roller, der lige nu deler alt

En VPN-indgang, et sæt private tjenester og en build-runner vil have forskellige ting. Den første har brug for en offentlig port og et smalt netværk på den private side. Den anden har brug for vedvarende lager og applikationshemmeligheder. Den tredje kører kode, som en anden har skrevet.

Det er netop det, at alle tre får samme adgang, der gør symptomet forvirrende, fordi enhver af dem derefter kan påvirke de andre. Et build-job, der kan nå hypervisor-socketen, er et job, der kan stoppe VPN'en. En tjenestegæst med en rute til administrationsnetværket kan ændre switch-konfigurationen. Rettighederne er problemet, og proceslisten er kun det sted, hvor det viser sig. At navngive rollerne først giver hver rettighed et sted at bo.

Skitsen nedenfor er et udgangspunkt for den opdeling, ikke et løfte om høj tilgængelighed. Behandl den som en hypotese, der skal verificeres, ikke som det færdige design.

Del tre roller, ikke tre processer

Tre gæster på én vært giver tre rettighedssæt og tre netværkspositioner. De giver ikke tre fejldomæner, og designet bør sige det højt.

Opdelingen hjælper kun, hvis et kompromis i én gæst ikke automatisk giver de andre rettigheder, og det er en hypervisor-indstilling, ikke en navngivningskonvention. At kalde en VM for en gateway forhindrer ikke en anden gæst i at nå værten. Læs konfigurationen af den virtuelle switch i stedet for værtsnavnet, og bekræft derefter, at hver gæst sidder, hvor 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 topologien ned, og verificér den derefter med de værktøjer, der ejer den. En gæst, der dukker op på den forkerte bridge, er en opdagelse, ikke en detalje. Ret netværket, før du ændrer nogen tjenestekonfiguration.

Lad VPN-gæsten åbne kun de døre, den ejer

Udgiv tunnelporten på routeren og intet andet. Gæsteadministrationsporte hører til på en administrationsvej, ikke på internettet, og hypervisorens egen grænseflade hører også til der.

Netværket på den private side bør nå de tjenester, som fjernbrugere har brug for, og stoppe der. Applikationsgodkendelse forbliver slået til, fordi en tunnel er transport og ikke et login. Hold VPN-gæstens routingtabel lille nok til at beskrive i én sætning. Hvis du ikke kan beskrive den så enkelt, er grænsen allerede blevet sløret.

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

Alt, der lytter på værten og ikke er nødvendigt for administration, bør slet ikke lytte. Det omfatter hypervisor-API'et, som det er let at efterlade åbent på en offentlig grænseflade.

Build-job kræver en anden slags grænse

Et CI-job kører kommandoer, som repositoryet styrer, så dets tillid afhænger af, hvem der kan pushe kode. En shell-eksekutor kører disse kommandoer som runnerens bruger på værten, og det er den bredeste grænse, der findes.

Containereksekutorer er smallere, og en privilegeret container er ikke en af de smalle. Hold runneren i sin egen gæst med sit eget netværksomfang, og giv den kun den artefakt- og deployment-adgang, som jobbene har brug for. Engangs-arbejdere reducerer den bevarede tilstand; de reducerer ikke rækkevidde eller eksponering af hemmeligheder. Begge dele kræver stadig eksplicitte grænser.

Tjenestegæsten ejer dataene, så dens backup-plan er den, der skal virke. Hold repositories, uploads og databasen i samme tidsplan. Test en gendannelse i stedet for at læse jobstatus.

Planlæg den fejl, som alle tre deler

Én vært er ét fejldomæne. En genstart fjerner tunnelen og hver privat tjeneste i samme øjeblik, og det er netop, når en vej ind betyder mest.

Behold konsoladgang, der ikke afhænger af VPN-gæsten, hvad enten det er en fysisk konsol, en out-of-band-administrationsgrænseflade eller en udbyderkonsol. Et snapshot gemt på samme disk er ikke en uafhængig kopi, og en backup, der kører inde i den gæst, den beskytter, er det heller ikke. Test derefter koldstart som en sekvens i stedet for en tjekliste: vært, virtuelle netværk, tunnelsti og én navngivet applikation under en almindelig 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'

Rækkefølgen af processtart beviser intet om ruter og DNS, så test stien i stedet for enhedstilstandene. Stien er det, en fjernbruger faktisk har brug for.