क्या हर टेनेंट को अपना VM मिलना चाहिए?

सारांश

मल्टी-टेनेंट होस्टिंग आपको यह चुनने के लिए मजबूर करती है कि टेनेंट एक-दूसरे तक कितनी दूर पहुंच सकते हैं। कंटेनर प्रक्रियाओं और संसाधनों को अलग करने के लिए Linux नेमस्पेस और cgroups का उपयोग करते हैं, लेकिन वे होस्ट कर्नेल साझा करते हैं। वर्चुअल मशीन हार्डवेयर-स्तर की सीमा जोड़ती हैं, जिसकी कीमत गति और परिचालन भार के रूप में चुकानी पड़ती है। एक हाइब्रिड दृष्टिकोण—VMs के अंदर कंटेनर—आपको दोनों दे सकता है, लेकिन यह आपके पैच करने की सतह को दोगुना कर देता है। यह लेख आपको जोखिम-आधारित निर्णय, एक-पर-एक तुलना और Docker हार्डनिंग चरणों से अवगत कराता है जो VM के अंदर भी मायने रखते हैं। अंत तक, आप जान जाएंगे कि कौन सा आइसोलेशन मॉडल आपके टेनेंट्स के लिए उपयुक्त है और लॉन्च से पहले क्या कॉन्फ़िगर करना है।

आपका मल्टी-टेनेंट ऐप लगभग तैयार है। आपके पास एक Docker Compose फ़ाइल है जो प्रति ग्राहक स्टैक तेज़ी से तैयार करती है। फिर एक दोस्त जो होस्टिंग कंपनी चलाता है, पूछता है, 'क्या आप प्रत्येक टेनेंट को अपना VM दे रहे हैं?' आप रुक जाते हैं। आपने उस सवाल की योजना नहीं बनाई थी। यह लेख आपको आज ही इसका उत्तर देने का एक तरीका देता है, बिना सुरक्षा टीम के। आप इसे अकेले करते हैं, इसलिए निर्णय इतना सरल होना चाहिए कि रात के 2 बजे भी उसका बचाव किया जा सके।

'सर्वश्रेष्ठ' मॉडल खोजने की कोशिश करना बंद करें। पहले लिखें कि क्या होगा यदि किसी टेनेंट का कोड आपके होस्ट पर कब्ज़ा कर ले। कोई भी टूल चुनने से पहले ब्लास्ट रेडियस परिभाषित करें। यह अभ्यास आपको किसी भी बेंचमार्क से अधिक बताएगा।

कर्नेल वह रूममेट है जिसे आप बेदखल नहीं कर सकते

कंटेनर कुशल हैं क्योंकि वे होस्ट कर्नेल साझा करते हैं। यह साझेदारी ही पूरी तरकीब है, और पूरा जोखिम है। Linux नेमस्पेस प्रत्येक कंटेनर को प्रक्रियाओं, नेटवर्किंग और फाइलसिस्टम का अपना दृश्य देते हैं। कंट्रोल ग्रुप (cgroups) आपको CPU, मेमोरी और डिस्क I/O सीमित करने की अनुमति देते हैं ताकि एक टेनेंट दूसरों को भूखा न रख सके। लेकिन इनमें से कोई भी हार्डवेयर दीवार नहीं बनाता।

कंटेनर को एक प्रक्रिया की तरह समझें जिसके पास वास्तव में अच्छा नकली आईडी है। उसे विश्वास है कि वह अपनी मशीन पर है। हालाँकि, कर्नेल आपके होस्ट पर चलने वाली Linux की एक प्रति है। यदि कोई टेनेंट कर्नेल भेद्यता का फायदा उठाता है, तो नेमस्पेस केवल मेटाडेटा बन जाते हैं। एक हमलावर जो कर्नेल फ़ंक्शन को कॉल कर सकता है, वह उसी कर्नेल पर अन्य नेमस्पेस तक पहुंच सकता है। यह वह कंटेनर एस्केप है जिसके बारे में आप सुनते रहते हैं।

मान लीजिए आप एक छोटे B2B टूल को प्रति क्लाइंट एक कंटेनर के साथ होस्ट करते हैं। एक क्लाइंट एक संदिग्ध प्लगइन इंस्टॉल करता है जिसमें रिमोट कोड एक्ज़ीक्यूशन बग है। डिफ़ॉल्ट Docker सेटिंग्स के साथ, वह प्रक्रिया कंटेनर के अंदर root के रूप में चल रही है। कंटेनर में root अभी भी UID 0 है, और कर्नेल उस UID को होस्ट root से तब तक अलग नहीं करता जब तक आप स्पष्ट रूप से उपयोगकर्ताओं को मैप नहीं करते। हमलावर बाहर निकलने का प्रयास कर सकता है, और साझा कर्नेल उनका लक्ष्य है।

विफलता को नाटकीय होने की आवश्यकता नहीं है। एक एकल टेनेंट मेमोरी लीक करके होस्ट को स्वैप में धकेल सकता है, जिससे बाकी टेनेंट धीमे हो जाते हैं। cgroup सीमाओं के बिना, एक गलत लूप एक उपलब्धता हमला है। उनके साथ, यह एक अवरुद्ध प्रक्रिया और एक अलर्ट है।

क्या इसका मतलब है कि कंटेनर असुरक्षित हैं? नहीं। इसका मतलब है कि आपको कर्नेल को एक साझा विश्वास क्षेत्र के रूप में मानना चाहिए। चुनने से पहले, एक-पैराग्राफ जोखिम विवरण लिखें: 'यदि किसी टेनेंट का कंटेनर समझौता किया गया है, तो हमलावर पहुंच सकता है: [सूची]। व्यवसाय लागत होगी: [राशि या प्रभाव]।' यदि वह पैराग्राफ आपको डराता है, तो आप पागल नहीं हैं। आप ईमानदार हैं।

आइसोलेशन स्पेक्ट्रम पर गहराई से नज़र डालने के लिए, साझा कंटेनरों से लेकर पूरी तरह से अलग स्टैक तक, मल्टी-टेनेंट Docker आर्किटेक्चर डिज़ाइन करने के हमारे गाइड को देखें।

इसे तीन तरीकों से विभाजित करें (तैनाती से पहले एक चुनें)

मल्टी-टेनेंट आइसोलेशन के लिए वास्तव में तीन आर्किटेक्चर हैं। हर 'सर्वोत्तम अभ्यास' इनका संयोजन है।

दृष्टिकोण	आइसोलेशन बाधा	सबसे उपयुक्त जब	सबसे कठिन चेतावनी
प्रति-टेनेंट कंटेनर	कर्नेल नेमस्पेस + cgroups	कई छोटे टेनेंट, प्रति टेनेंट कम जोखिम, घनत्व की आवश्यकता	एक कर्नेल शोषण उस होस्ट पर हर टेनेंट को तोड़ सकता है
प्रति टेनेंट एक VM	हाइपरवाइज़र/हार्डवेयर वर्चुअलाइज़ेशन	विनियमित डेटा, शत्रुतापूर्ण टेनेंट, प्रति टेनेंट उच्च मूल्य	भारी, प्रावधान में धीमा, आप प्रति टेनेंट OS पैच करते हैं
VMs के अंदर कंटेनर	कंटेनरीकृत वर्कलोड के चारों ओर VM सीमा	घनत्व के साथ समूहों के बीच एक कठोर खोल	लागत और परिचालन ओवरहेड लगभग दोगुना

प्रति-टेनेंट कंटेनर। यह अधिकांश SaaS संस्थापकों के लिए डिफ़ॉल्ट है। प्रत्येक टेनेंट को अपना कंटेनर या छोटा Compose स्टैक मिलता है। प्रावधान तुरंत होता है, इमेज छोटी होती हैं, CI/CD सीधा है। संसाधन सीमाएं शोर करने वाले पड़ोसियों को सर्वर खाने से रोकती हैं। व्यापार-बंद साझा कर्नेल है। यदि आप वर्कलोड को गैर-विशेषाधिकार प्राप्त रख सकते हैं और नियमित रूप से होस्ट को पैच कर सकते हैं, तो यह अक्सर पहला सही कदम होता है।

दो टेनेंट को एक ही कंटेनर में न रखें। वह साझा कर्नेल और साझा रनटाइम और साझा फाइलसिस्टम है। यदि एक टेनेंट एक फ़ाइल अपलोड करता है जो प्रक्रिया बनाती है, तो दूसरा टेनेंट पहले से ही उसी प्रोसेस टेबल में है। एक कंटेनर आपके आइसोलेशन की इकाई है; प्रति कंटेनर एक टेनेंट बनाएं।

डेटाबेस के बारे में क्या? यदि हर टेनेंट एक ही MongoDB या PostgreSQL इंस्टेंस से समान क्रेडेंशियल्स के साथ जुड़ता है, तो आप पहले ही एक बड़ा साझा घटक जोड़ चुके हैं। प्रत्येक टेनेंट को अलग क्रेडेंशियल दें, और आदर्श रूप से एक अलग डेटाबेस या स्कीमा दें। कंटेनर ऐप को अलग करते हैं; डेटाबेस अक्सर पहला रिसाव होता है जिसे हमलावर परीक्षण करेगा।

प्रति टेनेंट एक VM। प्रत्येक टेनेंट को एक पूर्ण वर्चुअल मशीन दें। हाइपरवाइज़र एक हार्डवेयर-स्तर सीमा जोड़ता है, जो बिल्कुल वही है जो एक कर्नेल शोषण को होस्ट तक पहुंचने के लिए पार करना होता है। यह विनियमित वातावरण या जब टेनेंट अविश्वसनीय होते हैं, के लिए मायने रखता है। लागत घनत्व और समय है। अब आप सिर्फ कंटेनर नहीं, बल्कि ऑपरेटिंग सिस्टम का बेड़ा प्रबंधित करते हैं। प्रत्येक VM को अपडेट, सुरक्षा एजेंट और निगरानी की आवश्यकता होती है। एक एकल संस्थापक के लिए, यह वास्तविक काम है।

इस स्तर पर काम करने वाले पैटर्न: एक ही बेस इमेज से VM बनाने के लिए इंफ्रास्ट्रक्चर-एज़-कोड का उपयोग करें, लाइव सिस्टम को पैच करने के बजाय नई इमेज में अपडेट बेक करें, और उन वर्कलोड को समाप्त करें जिन्हें आप पहचानते नहीं हैं। VM के प्रबंधन पोर्ट को इंटरनेट के लिए बंद रखें।

VMs के अंदर कंटेनर। यह हाइब्रिड शायद ही कभी शुरुआती ट्यूटोरियल में चर्चा में आता है। आप प्रत्येक टेनेंट (या छोटे समूह) के चारों ओर एक छोटा VM रखते हैं, फिर उस VM के अंदर कंटेनर चलाते हैं। VM एक ब्लास्ट-रेडियस कंटेनर है; कंटेनर केवल तैनाती योग्य इकाइयाँ हैं। यह आपको वर्चुअलाइज़ेशन का कठोर किनारा और इमेज की पुनरुत्पादन क्षमता देता है। इसकी लागत अधिक है, क्योंकि आप वर्चुअलाइज़ेशन ओवरहेड और कंटेनर लचीलेपन के लिए भुगतान करते हैं, लेकिन यह दीर्घकालिक मॉडल सबसे समझदार हो सकता है जब आप टेनेंट पर पूरी तरह भरोसा नहीं कर सकते।

एक सामान्य माइक्रो-उदाहरण: एक टेनेंट एक Node API और एक पृष्ठभूमि कार्यकर्ता चलाता है। दोनों प्रक्रियाओं वाले एक विशाल कंटेनर के बजाय, एक VM का उपयोग करें, फिर अलग-अलग संसाधन सीमाओं वाले दो कंटेनर, एक साझा नेटवर्क, और कार्यकर्ता के लिए कोई सीधा इंटरनेट एक्सपोज़र नहीं। VM कठोर किनारा प्रदान करता है; कंटेनर संरचना प्रदान करते हैं।

आपको कौन सा चुनना चाहिए? तालिका आपकी शॉर्टलिस्ट है। अगले अनुभाग निर्णय को ठोस बनाते हैं।

यदि आप कंटेनर चुनते हैं, तो ये छह काम करें या परेशान न हों

प्रति-टेनेंट कंटेनर तब ठीक हैं जब आप हर कंटेनर को संभावित हमलावर मानते हैं। यह कॉन्फ़िगरेशन से शुरू होता है, कल्पना से नहीं।

0. किसी पर भरोसा करने से पहले संसाधनों को सीमित करें। Cgroups एक निष्पक्षता तंत्र और उपलब्धता बचाव हैं। प्रति कंटेनर --memory और --cpus सेट करें। एक टेनेंट जो मेमोरी लीक करता है उसे अपनी सीमा का सामना करना चाहिए, आपके सर्वर की नहीं। यह एक सुरक्षा सीमा नहीं है, लेकिन शोर करने वाला पड़ोसी बिना कोड की एक पंक्ति के हमला है। एक व्यावहारिक शुरुआत: --memory 512m --cpus 0.5। कार्यकर्ता प्रक्रिया के लिए, कम शुरू करें और बढ़ाएं।

1. गैर-root उपयोगकर्ता के रूप में चलाएं। कंटेनर प्रक्रिया को कभी भी UID 0 उपयोग न करने दें जब तक कि आपको पूरी तरह से आवश्यकता न हो। Dockerfile में एक उपयोगकर्ता सेट करें और अतिरिक्त सुरक्षा के रूप में --user पास करें। एक अनपेक्षित उपयोगकर्ता के रूप में चलने वाले शोषण के पास कर्नेल तक बहुत कम रास्ते होते हैं। अपनी Dockerfile में, एक उपयोगकर्ता बनाएं: RUN useradd -u 10001 app और USER app। समय बचाने के लिए इसे न छोड़ें।

2. हर क्षमता को छोड़ें जिसकी आपको आवश्यकता नहीं है। Linux क्षमताएं root की शक्ति को छोटे टुकड़ों में विभाजित करती हैं। अधिकांश वेब ऐप्स को लगभग किसी की आवश्यकता नहीं होती। --cap-drop=ALL से शुरू करें और केवल वही वापस जोड़ें जो आप जानते हैं कि आपको चाहिए। CAP_SYS_ADMIN के बिना एक कंटेनर के लिए नेमस्पेस ट्रिक्स का उपयोग करना बहुत कठिन है। यदि आपका ऐप एक विशेषाधिकार प्राप्त पोर्ट बांधने का प्रयास करता है, तो इसे उच्च पोर्ट पर चलाएं और NET_BIND_SERVICE देने के बजाय सामने प्रॉक्सी रखें।

3. फाइलसिस्टम को केवल-पठनीय बनाएं। आपके ऐप को अपनी कंटेनर परत में नहीं लिखना चाहिए। स्टेट के लिए tmpfs माउंट करें। एक हमलावर जो डिस्क पर नहीं लिख सकता, उसके लिए पर्सिस्टेंस लगाना बहुत कठिन है। एक समझौता किया गया PHP ऐप जो वेबशेल लिखने की कोशिश करता है, विफल हो जाएगा जब रूट फाइलसिस्टम केवल-पठनीय है। आप एक नामित वॉल्यूम माउंट कर सकते हैं जिसकी आपके ऐप को वास्तव में आवश्यकता है।

4. seccomp और AppArmor या SELinux लागू करें। ये जोखिम भरे syscalls को डिस्कार्ड ढेर में भेजते हैं। Docker एक डिफ़ॉल्ट seccomp प्रोफ़ाइल भेजता है; इसका उपयोग करें। एक और परत के लिए AppArmor प्रोफ़ाइल जोड़ें। आपको हर syscall में महारत हासिल करने की आवश्यकता नहीं है। आपको उस चीज़ को अस्वीकार करने की आवश्यकता है जो एक सामान्य वेब कार्यकर्ता को कभी आवश्यकता नहीं होती। कभी भी --privileged के साथ न चलाएं। वह फ्लैग आपके द्वारा अभी स्थापित लगभग हर बचाव को अक्षम कर देता है।

5. नेटवर्क को विभाजित करें। हर कंटेनर को हर दूसरे कंटेनर का मार्ग न दें। डिफ़ॉल्ट अस्वीकार करें, फिर केवल उन पोर्ट को खोलें जिनकी आपको आवश्यकता है। एक समझौता किया गया डेटाबेस कंटेनर आपके एडमिन पैनल को स्कैन नहीं कर पाना चाहिए। यदि टेनेंट अलग-अलग नेटवर्क में हैं, तो एक नेटवर्क में उल्लंघन पार्श्व रूप से नहीं फैल सकता।

एक व्यावहारिक शुरुआत:

docker run --user 10001 --cap-drop=ALL --security-opt no-new-privileges --read-only --tmpfs /tmp:rw,size=64M --security-opt seccomp=default.json --memory 512m --cpus 0.5 myimage

उन्हीं फ्लैग्स को Compose फ़ाइल में डालें और उन्हें हर टेनेंट पर लागू करें। यह पूर्ण नहीं है, लेकिन यह docker run के बॉक्स से बाहर देने वाले से कहीं अधिक मजबूत डिफ़ॉल्ट है।

गहन वॉकथ्रू के लिए, मल्टी-टेनेंट होस्टिंग में Docker कंटेनरों के लिए हमारे चरण-दर-चरण हार्डनिंग गाइड का उपयोग करें।

Docker की एन्हांस्ड कंटेनर आइसोलेशन एक अपवाद है जिसे आपको जानना चाहिए

यदि आप एक प्रबंधित Docker वातावरण के अंदर चलते हैं, तो Docker की एन्हांस्ड कंटेनर आइसोलेशन (ECI) देखें। यह हुड के नीचे उपयोगकर्ता नेमस्पेस आइसोलेशन और एक सुरक्षित कंटेनर रनटाइम का उपयोग करता है। कंटेनर के अंदर root होस्ट पर एक अनपेक्षित उपयोगकर्ता से मैप होता है, इसलिए root के रूप में चलने वाला कंटेनर भी होस्ट root विशेषाधिकार प्राप्त नहीं करता। यह डिफ़ॉल्ट रूप से खतरनाक क्षमताओं और syscalls को भी अवरुद्ध करता है। यह कुछ ऐसा नहीं है जिसे आप वनीला Docker पर कुछ फ्लैग्स के साथ फिर से बना सकते हैं। यदि आपका प्लेटफ़ॉर्म इसका समर्थन करता है, तो इसे चालू करें। यह गैर-root उपयोगकर्ताओं और संसाधन सीमाओं की आवश्यकता को नहीं हटाता है, लेकिन यह जोखिम गणित को बदल देता है।

आप Docker daemon में उपयोगकर्ता नेमस्पेस रीमैपिंग (userns-remap) के साथ इसका एक हिस्सा अनुमानित कर सकते हैं। यह सुरक्षित रनटाइम के रूप में पूर्ण नहीं है, लेकिन कुछ नहीं से बेहतर है। यदि आप इसका उपयोग करते हैं, तो विश्वास करने से पहले UID मैपिंग काम करती है सत्यापित करें।

VM भ्रांति: वर्चुअल मशीनों पर जाना हार्डनिंग नहीं है

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

दूसरा जाल VM को स्वयं सुरक्षित मानना है। एक कमजोर SSH पासवर्ड, बिना पैच किए बेस पैकेज, या खुला प्रबंधन पोर्ट वाली एक डिफ़ॉल्ट इमेज एक उपहार है। हाइपरवाइज़र सीमा केवल तभी मायने रखती है जब अतिथि कठोर और अद्यतित हो। अन्यथा, आपका 'सुरक्षित VM' समझौता करने का एक तेज़ मार्ग है क्योंकि आप सुरक्षित महसूस करते हैं और जांचना बंद कर देते हैं।

VM आपको जो देता है वह कम करने योग्य ब्लास्ट त्रिज्या है। एक टेनेंट की आपदा एक VM में रहती है। इसकी कीमत आपको आपका समय है। आप अपने टेनेंट की संख्या के बराबर ऑपरेटिंग सिस्टम के लिए sysadmin बन जाते हैं। यदि आप एक उत्पाद भेजने वाले एकल संस्थापक हैं, तो पूछें कि क्या आपके पास बेड़े को पैच करने और निगरानी करने के लिए घंटे हैं। यदि हाँ, तो प्रति टेनेंट VM सही कॉल हो सकता है। यदि नहीं, तो मजबूत हार्डनिंग वाले कंटेनर अधिक ईमानदार हो सकते हैं।

यह भी याद रखें कि आपका हाइपरवाइज़र होस्ट एक महत्वपूर्ण लक्ष्य है। एक समझौता किया गया हाइपरवाइज़र सभी मेहमानों को देख सकता है। केवल मेहमानों को नहीं, होस्ट को पैच करें। VM आपको होस्ट पैचिंग से मुक्त नहीं करता; यह इसे चूकने के दांव को बढ़ाता है।

हाइब्रिड पर एक चेतावनी: यह न मानें कि VM के अंदर कंटेनर आपको 'मुफ्त में सुरक्षा की दो परतें' देते हैं। VM एक सीमा जोड़ता है; कंटेनर को अभी भी गैर-root, क्षमताओं और seccomp की आवश्यकता है। अन्यथा पहली परत केवल सबसे कमजोर कंटेनर जितनी मजबूत होती है।

चार प्रश्न जो दस मिनट में बहस को सुलझा देते हैं

अमूर्त में अनुकूलन न करें। इन चार प्रश्नों को क्रम से पूछें। उत्तर लिखें।

1. मेरे टेनेंट की पहुंच किस तक है? यदि एक टेनेंट केवल अपने वेब ऐप और डेटाबेस तक पहुंच सकता है, तो सख्त नेटवर्क नियमों वाले प्रति-टेनेंट कंटेनर बचाव योग्य हैं। यदि किसी टेनेंट का डेटा विनियमित या वित्तीय रूप से संवेदनशील है, तो VMs की ओर बढ़ें।

2. एक टेनेंट के समझौते से मुझे कितना नुकसान होगा? खोए हुए ग्राहकों, कानूनी जोखिम और विश्वास को जोड़ें। यदि संख्या VMs चलाने की लागत से बड़ी है, तो पैसा खर्च करें। यदि नहीं, तो कंटेनर एक तर्कसंगत विकल्प हैं।

3. मेरे कितने टेनेंट हैं और वे कितना भुगतान करते हैं? कई छोटे ग्राहक: कंटेनर घनत्व मायने रखता है। कुछ बड़े खाते: प्रत्येक को एक VM दें और तदनुसार बिल करें। जो टेनेंट आपको एक कॉफी से कम भुगतान करते हैं, उनमें से प्रत्येक को प्रबंधित करने के लिए OS की आवश्यकता नहीं होनी चाहिए।

4. क्या मैं एक अनुसूची पर चीजों को पैच कर सकता हूं? कंटेनर एक होस्ट कर्नेल साझा करते हैं, इसलिए होस्ट को पैच करना सभी की रक्षा करता है। VMs आपके पैच लक्ष्यों को कई गुना करते हैं। यदि आप जानते हैं कि आप अपडेट छोड़ देंगे, तो कम चलती भागों और कठिन डिफ़ॉल्ट वाले आर्किटेक्चर चुनें।

आपके उत्तर एक समूह बनाएंगे। दो या अधिक VM-केंद्रित उत्तरों का मतलब है कि आपको प्रति-टेनेंट कंटेनरों के लिए डिफ़ॉल्ट नहीं होना चाहिए। तीन या अधिक कंटेनर-केंद्रित उत्तरों का मतलब है कि VMs समय से पहले हैं। एक प्रतिकूल परिणाम: संवेदनशील डेटा तक पहुंच वाला कम-राजस्व टेनेंट अभी भी VM की आवश्यकता है, क्योंकि नियामक लागत का उनके भुगतान से कोई लेना-देना नहीं है।

न्यूनतम भरोसे के साथ जहाज करें, फिर अधिक आइसोलेशन अर्जित करें

आपका पहला आर्किटेक्चर आपका अंतिम नहीं होना चाहिए। अपने वास्तव में बनाए रखने योग्य सबसे कड़े सेटअप से शुरू करें, फिर जैसे आपका टेनेंट आधार उचित ठहराता है, आइसोलेशन जोड़ें। अधिकांश एकल ऑपरेटरों के लिए, इसका मतलब है गैर-root, सीमित क्षमताओं, केवल-पठनीय फाइलसिस्टम, seccomp और नेटवर्क विभाजन के साथ प्रति-टेनेंट कंटेनर। विनियमित या उच्च-मूल्य वाले टेनेंट के लिए, सीधे प्रति टेनेंट एक VM पर कूदें, कंटेनर केवल अंदर एक पैकेजिंग परत के रूप में।

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

लॉन्च से पहले, हमारे व्यावहारिक Docker आइसोलेशन सुरक्षा चेकलिस्ट के माध्यम से चलें—यह इन निर्णयों को एक सूची में बदल देता है जिसे आप किसी ग्राहक को पृष्ठ दिखाने से पहले सत्यापित कर सकते हैं।