Një server laboratori, tre role besimi, një domen dështimi

Gjithçka funksionon derisa ekzekutuesi i ndërtimit të ketë nevojë për të njëjtin socket pritësi që përdor mysafiri VPN, dhe atëherë askush nuk mund të shpjegojë pse një punë mund të lexojë çelësat e portës. Gjithçka u instalua në një makinë sepse përshtatej, dhe çdo mysafir mori akses të gjerë sepse ishte mënyra më e shpejtë për ta bërë të funksionojë. Rezultati është një pritës kufiri i besimit i të cilit është kablloja e energjisë. Ndarja e roleve kërkon më pak punë sesa duket, dhe fillon me emërtimin e tyre.

Tre role që aktualisht ndajnë gjithçka

Një hyrje VPN, një grup shërbimesh private dhe një ekzekutues ndërtimi duan gjëra të ndryshme. I pari ka nevojë për një port publik dhe një rrjet të ngushtë në anën private. I dyti ka nevojë për ruajtje të përhershme dhe sekretet e aplikacionit. I treti ekzekuton kod që ka shkruar dikush tjetër.

Dhënia e të njëjtit akses të treve është ajo që e bën simptomën konfuze, sepse atëherë secili prej tyre mund të ndikojë te të tjerët. Një punë ndërtimi që arrin socket-in e hipervizorit është një punë që mund të ndalojë VPN-në. Një mysafir shërbimesh me rrugë drejt rrjetit të menaxhimit mund të ndryshojë konfigurimin e switch-it. Problemi janë privilegjet, dhe lista e proceseve është vetëm vendi ku kjo shfaqet. Emërtimi i roleve së pari i jep çdo privilegji një vend ku të banojë.

Skica më poshtë është një pikënisje për atë ndarje, jo një premtim i disponueshmërisë së lartë. Trajtojeni si hipotezë për t'u verifikuar, jo si dizajni i përfunduar.

Ndani tre role, jo tre procese

Tre mysafirë në një pritës japin tre grupe privilegjesh dhe tre pozicione rrjeti. Ata nuk japin tre domene dështimi, dhe dizajni duhet ta thotë këtë me zë të lartë.

Ndarja ndihmon vetëm nëse komprometimi i një mysafiri nuk u jep automatikisht të tjerëve akses, dhe ky është një konfigurim i hipervizorit, jo një konventë emërtimi. Të quash një VM portë nuk e ndalon një mysafir tjetër të arrijë pritësin. Lexoni konfigurimin e switch-it virtual në vend të emrit të pritësit, pastaj konfirmoni që çdo mysafir qëndron aty ku mendoni.

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

Shkruani topologjinë dhe pastaj verifikojeni me mjetet që e zotërojnë. Një mysafir që shfaqet në urën e gabuar është një gjetje, jo një detaj. Rregulloni rrjetin përpara se të ndryshoni çdo konfigurim shërbimi.

Lëreni mysafirin VPN të hapë vetëm dyert që zotëron

Publikoni portin e tunelit në ruter dhe asgjë tjetër. Portat e administrimit të mysafirëve i përkasin një rruge menaxhimi, jo internetit, dhe aty i përket edhe ndërfaqja e vetë hipervizorit.

Rrjeti në anën private duhet të arrijë shërbimet që u nevojiten përdoruesve në distancë dhe të ndalet atje. Vërtetimi i aplikacionit mbetet i ndezur, sepse një tunel është transport dhe jo hyrje. Mbajeni tabelën e rrugëzimit të mysafirit VPN aq të vogël sa ta përshkruani me një fjali. Nëse nuk mund ta përshkruani kaq thjesht, kufiri tashmë është turbulluar.

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

Çdo gjë që dëgjon në pritës dhe nuk nevojitet për menaxhim nuk duhet të dëgjojë fare. Kjo përfshin API-n e hipervizorit, të cilin është e lehtë ta lësh të ekspozuar në një ndërfaqe publike.

Punët e ndërtimit kanë nevojë për një lloj tjetër kufiri

Një punë CI ekzekuton komanda të kontrolluara nga repozitori, kështu që besimi i saj varet nga kush mund të dërgojë kod. Një ekzekutues shell i ekzekuton ato komanda si përdoruesi i ekzekutuesit në pritës, që është kufiri më i gjerë i disponueshëm.

Ekzekutuesit e kontejnerëve janë më të ngushtë, dhe një kontejner i privilegjuar nuk është një prej atyre të ngushtë. Mbajeni ekzekutuesin në mysafirin e vet me shtrirjen e vet të rrjetit dhe jepini vetëm aksesin ndaj artefakteve dhe vendosjes që u nevojitet punëve. Punëtorët e përdorimit një herë zvogëlojnë gjendjen e ruajtur; nuk zvogëlojnë arritshmërinë ose ekspozimin e sekreteve. Të dyja ende kanë nevojë për kufij të qartë.

Mysafiri i shërbimeve zotëron të dhënat, kështu që plani i tij i rezervës është ai që duhet të funksionojë. Mbajini repozitorët, ngarkimet dhe bazën e të dhënave në të njëjtin orar. Testoni një rikthim në vend që të lexoni statusin e punës.

Planifikoni dështimin që ndajnë të tre

Një pritës është një domen dështimi. Një rindezje heq tunelin dhe çdo shërbim privat në të njëjtin moment, dhe pikërisht atëherë një rrugë hyrjeje ka më shumë rëndësi.

Mbajini aksesin në konsolë që nuk varet nga mysafiri VPN, qoftë konsolë fizike, ndërfaqe menaxhimi jashtë brezit apo konsolë e ofruesit. Një snapshot i ruajtur në të njëjtin disk nuk është kopje e pavarur, dhe as një rezervë që ekzekutohet brenda mysafirit që mbron. Pastaj testoni nisjen e ftohtë si sekuencë, jo si listë kontrolli: pritësi, rrjetet virtuale, rruga e tunelit dhe një aplikacion i emërtuar nën një llogari të zakonshme.

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'

Rendi i nisjes së proceseve nuk provon asgjë për rrugët dhe DNS-në, prandaj testoni rrugën, jo gjendjet e njësive. Rruga është ajo që një përdorues në distancë i nevojitet vërtet.