Մեկ լաբորատոր սերվեր, վստահության երեք դեր, մեկ խափանման տիրույթ

Ամեն ինչ աշխատում է, քանի դեռ շինարարության կատարողը չի պահանջում նույն հոսթի բնիկը, որն օգտագործում է VPN հյուրը, և այդ ժամանակ ոչ ոք չի կարող բացատրել, թե ինչու աշխատանքը կարող է կարդալ դարպասի բանալիները։ Ամեն ինչ տեղադրվել է մեկ մեքենայի վրա, որովհետև տեղավորվում էր, և յուրաքանչյուր հյուրի տրվել է լայն հասանելիություն, որովհետև դա աշխատեցնելու ամենաարագ ճանապարհն էր։ Արդյունքը հոսթ է, որի վստահության սահմանը սնուցման մալուխն է։ Դերերը առանձնացնելը ավելի քիչ աշխատանք է, քան թվում է, և այն սկսվում է դրանց անվանումով։

Երեք դերեր, որոնք հիմա կիսում են ամեն ինչ

VPN մուտքը, մասնավոր ծառայությունների հավաքածուն և շինարարության կատարողը տարբեր բաներ են ուզում։ Առաջինին պետք է հանրային պորտ և նեղ ցանց մասնավոր կողմում։ Երկրորդին պետք է մշտական պահոց և հավելվածի գաղտնիքներ։ Երրորդը կատարում է կոդ, որը գրել է մեկ ուրիշը։

Հենց բոլոր երեքին նույն հասանելիությունը տալն է ախտանիշը շփոթեցնող դարձնում, որովհետև այդ ժամանակ նրանցից ցանկացածը կարող է ազդել մյուսների վրա։ Շինարարության աշխատանքը, որը հասնում է հիպերվիզորի բնիկին, աշխատանք է, որը կարող է կանգնեցնել VPN-ը։ Ծառայությունների հյուրը, որը երթուղի ունի դեպի կառավարման ցանց, կարող է փոխել անջատիչի կարգավորումը։ Լիազորություններն են խնդիրը, և պրոցեսների ցանկը միայն այն տեղն է, որտեղ դա երևում է։ Դերերը նախ անվանելը յուրաքանչյուր լիազորության տալիս է ապրելու տեղ։

Ներքևի ուրվագիծը այդ բաժանման մեկնարկային կետն է, ոչ թե բարձր հասանելիության խոստում։ Վերաբերվեք դրան որպես ստուգման ենթակա վարկածի, ոչ թե ավարտված նախագծի։

Առանձնացրեք երեք դեր, ոչ թե երեք պրոցես

Մեկ հոսթի վրա երեք հյուր տալիս են երեք լիազորությունների հավաքածու և երեք ցանցային դիրք։ Նրանք չեն տալիս երեք խափանման տիրույթ, և նախագիծը պետք է դա բարձրաձայն ասի։

Բաժանումն օգնում է միայն այն դեպքում, երբ մեկ հյուրի վնասումը ավտոմատ կերպով լիազորություններ չի տալիս մյուսներին, և դա հիպերվիզորի կարգավորում է, ոչ թե անվանակարգման պայմանականություն։ VM-ը դարպաս անվանելը չի խանգարում մեկ այլ հյուրի հասնել հոսթին։ Կարդացեք վիրտուալ անջատիչի կարգավորումը հոսթի անվան փոխարեն, ապա հաստատեք, որ յուրաքանչյուր հյուր նստած է այնտեղ, որտեղ դուք կարծում եք։

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

Գրեք տոպոլոգիան և ապա ստուգեք այն գործիքներով, որոնք տիրապետում են դրան։ Սխալ կամրջի վրա հայտնված հյուրը բացահայտում է, ոչ թե մանրուք։ Ուղղեք ցանցը նախքան որևէ ծառայության կարգավորում փոխելը։

Թույլ տվեք VPN հյուրին բացել միայն իր դռները

Հրապարակեք թունելի պորտը երթուղիչում և ուրիշ ոչինչ։ Հյուրերի կառավարման պորտերը պատկանում են կառավարման ուղուն, ոչ թե ինտերնետին, և հիպերվիզորի սեփական ինտերֆեյսը նույնպես այնտեղ է։

Մասնավոր կողմի ցանցը պետք է հասնի հեռավոր օգտատերերին անհրաժեշտ ծառայություններին և կանգ առնի այնտեղ։ Հավելվածի նույնականացումը մնում է միացված, որովհետև թունելը տրանսպորտ է, ոչ թե մուտք։ Պահեք VPN հյուրի երթուղային աղյուսակը բավական փոքր, որպեսզի այն նկարագրեք մեկ նախադասությամբ։ Եթե չեք կարող այն այդքան պարզ նկարագրել, սահմանն արդեն լղոզվել է։

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

Այն ամենը, ինչ լսում է հոսթի վրա և պետք չէ կառավարմանը, ընդհանրապես չպետք է լսի։ Դա ներառում է հիպերվիզորի API-ն, որը հեշտ է բաց թողնել հանրային ինտերֆեյսի վրա։

Շինարարության աշխատանքներին այլ տեսակի սահման է պետք

CI աշխատանքը կատարում է պահոցի կողմից վերահսկվող հրահանգներ, ուստի նրա վստահությունը կախված է նրանից, թե ով կարող է կոդ ուղարկել։ Shell կատարողը այդ հրահանգները գործարկում է որպես կատարողի օգտատեր հոսթի վրա, և դա ամենալայն հասանելի սահմանն է։

Կոնտեյներ կատարողներն ավելի նեղ են, և արտոնյալ կոնտեյները նեղերից չէ։ Պահեք կատարողին իր սեփական հյուրում՝ իր ցանցային ծավալով, և տվեք նրան միայն արտեֆակտների և տեղակայման այն հասանելիությունը, որն անհրաժեշտ է աշխատանքներին։ Միանգամյա աշխատողները նվազեցնում են պահվող վիճակը, բայց չեն նվազեցնում հասանելիությունը կամ գաղտնիքների բացահայտումը։ Երկուսին էլ դեռ պետք են հստակ սահմանափակումներ։

Ծառայությունների հյուրը տիրապետում է տվյալներին, ուստի նրա պահուստային պլանն է, որ պետք է աշխատի։ Պահեք պահոցները, բեռնումները և տվյալների բազան նույն ժամանակացույցում։ Փորձարկեք վերականգնումը՝ աշխատանքի կարգավիճակը կարդալու փոխարեն։

Պլանավորեք այն խափանումը, որը կիսում են բոլոր երեքը

Մեկ հոսթը մեկ խափանման տիրույթ է։ Վերագործարկումը հեռացնում է թունելը և յուրաքանչյուր մասնավոր ծառայություն նույն պահին, և հենց այդ ժամանակ ներսի ճանապարհն ամենաշատն է կարևոր։

Պահեք կոնսոլի հասանելիություն, որը կախված չէ VPN հյուրից, լինի դա ֆիզիկական կոնսոլ, արտաբանդ կառավարման ինտերֆեյս թե մատակարարի կոնսոլ։ Նույն սկավառակի վրա պահված պատկերը անկախ պատճեն չէ, և պահուստը, որն աշխատում է իր պաշտպանած հյուրի ներսում, նույնպես չէ։ Ապա փորձարկեք սառը գործարկումը որպես հաջորդականություն, ոչ թե ստուգաթերթ՝ հոսթ, վիրտուալ ցանցեր, թունելի ուղի և մեկ անվանված հավելված սովորական հաշվով։

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'

Պրոցեսների մեկնարկի հերթականությունը ոչինչ չի ապացուցում երթուղիների և DNS-ի մասին, ուստի փորձարկեք ուղին, ոչ թե միավորների վիճակները։ Ուղին այն է, ինչ հեռավոր օգտատիրոջն իսկապես պետք է։