En labbserver, tre förtroenderoller, en feldoman

Allt fungerar tills byggköraren behöver samma värduttag som VPN-gästen använder, och då kan ingen förklara varför ett jobb kan läsa gatewayens nycklar. Allt installerades på en maskin eftersom det fick plats, och varje gäst fick bred åtkomst eftersom det var det snabbaste sättet att få det att fungera. Resultatet är en värd vars förtroendegräns är strömkabeln. Att dela upp rollerna kräver mindre arbete än det låter, och det börjar med att namnge dem.

Tre roller som just nu delar allt

En VPN-ingång, en uppsättning privata tjänster och en byggköare vill olika saker. Den första behöver en publik port och ett smalt nät på den privata sidan. Den andra behöver beständig lagring och applikationens hemligheter. Den tredje kör kod som någon annan har skrivit.

Att alla tre får samma åtkomst är det som gör symptomet förvirrande, för då kan vilken som helst av dem påverka de andra. Ett byggjobb som når hypervisorns uttag är ett jobb som kan stoppa VPN:en. En tjänstegäst med rutt till hanteringsnätet kan ändra switchkonfigurationen. Problemet är privilegierna, och processlistan är bara där det syns. Att namnge rollerna först ger varje privilegium en plats att bo på.

Skissen nedan är en startpunkt för den delningen, inte ett löfte om hög tillgänglighet. Behandla den som en hypotes att verifiera, inte som den färdiga designen.

Dela tre roller, inte tre processer

Tre gäster på en värd ger tre privilegieuppsättningar och tre nätpositioner. De ger inte tre feldomaner, och designen bör säga det högt.

Separationen hjälper bara om en komprometterad gäst inte automatiskt ger de andra åtkomst, och det är en hypervisorinställning, inte en namngivningskonvention. Att kalla en VM för gateway hindrar inte en annan gäst från att nå värden. Läs konfigurationen för den virtuella switchen i stället för värdnamnet och bekräfta sedan att varje gäst sitter där 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 topologin och verifiera den sedan med verktygen som äger den. En gäst som dyker upp på fel brygga är ett fynd, inte en detalj. Rätta nätet innan du ändrar någon tjänstekonfiguration.

Låt VPN-gästen bara öppna de dörrar den äger

Publicera tunnelporten i routern och ingenting annat. Administrationsportar för gäster hör på en hanteringsväg, inte på internet, och hypervisorns eget gränssnitt hör också dit.

Nätet på den privata sidan bör nå de tjänster som fjärranvändarna behöver och stanna där. Applikationens autentisering är kvar påslagen, eftersom en tunnel är transport och inte inloggning. Håll VPN-gästens routingtabell så liten att du kan beskriva den i en mening. Om du inte kan beskriva den så enkelt har gränsen redan suddats ut.

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

Allt som lyssnar på värden och inte behövs för hantering borde inte lyssna alls. Det gäller hypervisorns API, som är lätt att lämna exponerat på ett publikt gränssnitt.

Byggjobb behöver en annan sorts gräns

Ett CI-jobb kör kommandon som repot styr, så dess förtroende beror på vem som kan pusha kod. En skalexekutor kör dessa kommandon som körarens användare på värden, vilket är den bredaste gräns som finns.

Containerexekutorer är smalare, och en privilegierad container är inte en av de smala. Håll köraren i sin egen gäst med sitt eget nätomfång och ge den bara den artefakt- och distributionsåtkomst som jobben behöver. Engångsarbetare minskar det sparade tillståndet; de minskar inte nåbarhet eller exponering av hemligheter. Båda behöver fortfarande tydliga gränser.

Tjänstegästen äger data, så det är dess säkerhetskopieplan som måste fungera. Håll repon, uppladdningar och databasen i samma schema. Testa en återställning i stället för att läsa jobbstatusen.

Planera för felet som alla tre delar

En värd är en feldoman. En omstart tar bort tunneln och varje privat tjänst i samma ögonblick, och det är precis då en väg in betyder mest.

Behåll konsolåtkomst som inte beror på VPN-gästen, vare sig det är en fysisk konsol, ett hanteringsgränssnitt utanför bandet eller en leverantörskonsol. En ögonblicksbild på samma disk är inte en oberoende kopia, och inte heller en säkerhetskopia som körs inne i gästen den skyddar. Testa sedan kallstart som en sekvens, inte som en checklista: värd, virtuella nät, tunnelväg och en namngiven applikation under ett vanligt 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'

Ordningen för processstarter bevisar ingenting om rutter och DNS, så testa vägen i stället för enheternas tillstånd. Vägen är vad en fjärranvändare faktiskt behöver.