एक लैब सर्वर, तीन विश्वास भूमिकाएँ, एक विफलता डोमेन

सब कुछ तब तक काम करता है जब तक बिल्ड रनर को वही होस्ट सॉकेट नहीं चाहिए जो 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 कार्य रिपॉजिटरी-नियंत्रित आदेश चलाता है, इसलिए उसका विश्वास इस पर निर्भर है कि कौन कोड पुश कर सकता है। एक शेल निष्पादक उन आदेशों को होस्ट पर रनर के उपयोगकर्ता के रूप में चलाता है, और यह उपलब्ध सबसे चौड़ी सीमा है।

कंटेनर निष्पादक अधिक संकीर्ण हैं, और विशेषाधिकार प्राप्त कंटेनर उन संकीर्ण लोगों में नहीं है। रनर को उसके अपने नेटवर्क दायरे वाले अपने अतिथि में रखें, और उसे केवल वही आर्टिफैक्ट और तैनाती पहुँच दें जो कार्यों को चाहिए। फेंके जाने योग्य कार्यकर्ता संग्रहीत अवस्था घटाते हैं; वे पहुँच या रहस्यों के उजागर होने को कम नहीं करते। दोनों को अब भी स्पष्ट सीमाएँ चाहिए।

सेवा अतिथि डेटा का स्वामी है, इसलिए उसकी बैकअप योजना ही वह है जिसे काम करना है। रिपॉजिटरी, अपलोड और डेटाबेस को एक ही समय-सारणी में रखें। कार्य की स्थिति पढ़ने के बजाय पुनर्स्थापन जाँचें।

उस विफलता की योजना बनाएँ जो तीनों साझा करते हैं

एक होस्ट एक विफलता डोमेन है। रीबूट एक ही पल में टनल और हर निजी सेवा हटा देता है, और ठीक तभी अंदर जाने का रास्ता सबसे ज्यादा मायने रखता है।

ऐसी कंसोल पहुँच रखें जो 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 के बारे में कुछ साबित नहीं करता, इसलिए यूनिट की स्थितियों के बजाय पथ जाँचें। पथ ही वह चीज है जो दूरस्थ उपयोगकर्ता को वास्तव में चाहिए।