ერთი ლაბორატორიული სერვერი, ნდობის სამი როლი, ერთი მარცხის დომენი

ყველაფერი მუშაობს მანამ, სანამ აშენების გამმართველს არ დასჭირდება იგივე ჰოსტის სოკეტი, რომელსაც 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-ზე, ამიტომ გამოსცადეთ ბილიკი და არა ერთეულების მდგომარეობა. ბილიკია ის, რაც დისტანციურ მომხმარებელს ნამდვილად სჭირდება.