ब्लॉग
कंटेनर एस्केप से बचाव: मल्टी-टेनेंट होस्टिंग के लिए डॉकर आइसोलेशन पर एक व्यावहारिक गाइड
मल्टी-टेनेंट वातावरण में एस्केप कमजोरियों और आइसोलेशन विफलताओं के खिलाफ डॉकर कंटेनरों को सुरक्षित करने का तरीका जानें, जिसमें ठोस कदम और उदाहरण शामिल हैं।

सारांश
डॉकर कंटेनर होस्ट कर्नेल साझा करते हैं, जिससे आइसोलेशन महत्वपूर्ण हो जाता है—विशेष रूप से मल्टी-टेनेंट होस्टिंग में जहां एक एकल कंटेनर एस्केप सभी टेनेंट्स से समझौता कर सकता है। कई डेवलपर्स मानते हैं कि कंटेनर पूरी तरह से अलग वर्चुअल मशीनें हैं, लेकिन वास्तविकता अलग है। यह लेख डॉकर आइसोलेशन (नेमस्पेस, cgroups) के पीछे लिनक्स कर्नेल सुविधाओं और उन पर हमला करने वाले वैक्टरों की व्याख्या करता है। आप अपने डॉकर सेटअप को मजबूत करने के लिए व्यावहारिक कदम सीखेंगे: विशेषाधिकारों को सीमित करना, सुरक्षित रनटाइम का उपयोग करना, छवियों को स्कैन करना और नेटवर्क विभाजन लागू करना। एक मल्टी-टेनेंट वर्डप्रेस होस्टिंग प्रदाता के वास्तविक दुनिया के उदाहरण का पालन करके, आप देखेंगे कि इन सुरक्षाओं को कैसे लागू किया जाए। हम प्रदर्शन व्यापार-बंद और seccomp/AppArmor के उपयोग जैसे चेतावनियों को भी कवर करते हैं। लक्ष्य आपको एक मजबूत आइसोलेशन रणनीति देना है जो कंटेनर एस्केप को रोकती है और आपके टेनेंट्स को सुरक्षित रखती है।
परिचय
यदि आप एक मल्टी-टेनेंट होस्टिंग प्लेटफ़ॉर्म चलाते हैं—चाहे वह साझा वर्डप्रेस होस्टिंग हो, एक SaaS एप्लिकेशन हो, या एक देव वातावरण सेवा हो—कंटेनर एस्केप एक बुरा सपना है। कर्नेल में एक भेद्यता या एक गलत कॉन्फ़िगरेशन एक टेनेंट को उनके कंटेनर से बाहर निकलने और अन्य टेनेंट्स के डेटा या स्वयं होस्ट तक पहुंचने की अनुमति दे सकता है। डॉकर का आइसोलेशन लिनक्स कर्नेल सुविधाओं जैसे नेमस्पेस और cgroups पर निर्भर करता है, लेकिन आउट-ऑफ-द-बॉक्स कॉन्फ़िगरेशन अक्सर मजबूत सुरक्षा के लिए अपर्याप्त होते हैं। यह लेख आपको हमला वैक्टर के माध्यम से ले जाएगा और आपके डॉकर कंटेनरों को लॉक डाउन करने के लिए कार्रवाई योग्य कदम प्रदान करेगा, जिसे एक वास्तविक दुनिया मल्टी-टेनेंट वर्डप्रेस उदाहरण के साथ चित्रित किया गया है। उत्पादन ऑर्केस्ट्रेशन पर एक व्यापक नज़र के लिए, ऑर्केस्ट्रेटिंग प्रोडक्शन-रेडी कंटेनरीकृत एप्लिकेशन पर हमारे गाइड को देखें।
डॉकर आइसोलेशन को समझना
डॉकर कंटेनर प्रक्रिया-स्तरीय अलगाव प्रदान करने के लिए लिनक्स नेमस्पेस का उपयोग करते हैं: PID नेमस्पेस प्रक्रिया ट्री को अलग करते हैं, नेटवर्क नेमस्पेस नेटवर्क इंटरफेस को अलग करते हैं, माउंट नेमस्पेस फ़ाइलसिस्टम माउंट को अलग करते हैं, और उपयोगकर्ता नेमस्पेस कंटेनर रूट को एक गैर-विशेषाधिकार प्राप्त होस्ट उपयोगकर्ता पर मैप करने की अनुमति देते हैं। कंट्रोल ग्रुप (cgroups) CPU, मेमोरी और डिस्क I/O जैसे संसाधन उपयोग को सीमित करते हैं। ये सुविधाएँ मिलकर प्रत्येक कंटेनर के चारों ओर एक "सैंडबॉक्स" बनाती हैं। हालांकि, एक वर्चुअल मशीन के विपरीत जो एक अलग कर्नेल चलाती है, कंटेनर होस्ट कर्नेल साझा करते हैं। इसका मतलब है कि कर्नेल में एक भेद्यता (जैसे, CVE-2022-0492) का फायदा उठाकर कंटेनर के नेमस्पेस अलगाव से बाहर निकला जा सकता है। इसके अतिरिक्त, कंटेनर के अंदर रूट के रूप में कंटेनर चलाने, कंटेनर को सभी क्षमताएं देने, या अनावश्यक लिनक्स क्षमताओं को न छोड़ने जैसी गलत कॉन्फ़िगरेशन हमले की सतह को चौड़ा कर सकती हैं।
हमला वैक्टर
सामान्य हमला वैक्टर में शामिल हैं:
- कर्नेल एक्सप्लॉइट्स: होस्ट एक्सेस प्राप्त करने के लिए होस्ट कर्नेल में बग का फायदा उठाना।
- विशेषाधिकार प्राप्त कंटेनर:
--privilegedके साथ चलाना सभी क्षमताओं को प्रदान करता है और अधिकांश अलगाव को बायपास करता है। - क्षमता का दुरुपयोग: पूर्ण विशेषाधिकार मोड के बिना भी,
CAP_SYS_ADMINयाCAP_NET_ADMINजैसी खतरनाक क्षमताओं वाला एक कंटेनर फ़ाइलसिस्टम माउंट कर सकता है या नेटवर्क सेटिंग्स में हेरफेर कर सकता है। - असुरक्षित छवि प्रथाएं: ज्ञात कमजोरियों वाली बेस छवियों का उपयोग करना या कंपाइलर या शेल इंटरप्रेटर जैसे अनावश्यक टूल शामिल करना।
- साझा माउंट नेमस्पेस: कंटेनर में होस्ट निर्देशिकाओं को माउंट करने से बचने की अनुमति मिल सकती है यदि केवल-पढ़ने के लिए नहीं।
व्यावहारिक सुरक्षा कदम
1. गैर-रूट उपयोगकर्ता के रूप में कंटेनर चलाएं
डिफ़ॉल्ट रूप से, डॉकर कंटेनर को कंटेनर के अंदर रूट के रूप में चलाता है। यदि कोई हमलावर कंटेनर के अंदर रूट प्राप्त करता है, तो उनके पास अधिक लाभ होता है। अपने डॉकरफ़ाइल में एक उपयोगकर्ता बनाएं और USER निर्देश का उपयोग करें। साथ ही, यदि संभव हो तो किसी मनमाने होस्ट उपयोगकर्ता पर मैप करने के लिए डॉकर कंपोज़ में --user फ़्लैग का उपयोग करने से बचें।
2. सभी क्षमताओं को छोड़ें और केवल आवश्यक जोड़ें
लिनक्स क्षमताएं सुपरयूज़र विशेषाधिकारों को छोटी इकाइयों में तोड़ती हैं। डॉकर कंपोज़ में, cap_drop: ALL का उपयोग करें फिर केवल आवश्यक (जैसे, NET_BIND_SERVICE) को cap_add करें। SYS_ADMIN, NET_ADMIN, SYS_PTRACE जैसी खतरनाक क्षमताओं से बचें।
3. केवल-पढ़ने के लिए रूट फ़ाइलसिस्टम का उपयोग करें
अपने कंटेनर परिभाषा में read_only: true सेट करें। यह हमलावरों को कंटेनर के फ़ाइलसिस्टम पर लिखने से रोकता है। यदि आपके ऐप को अस्थायी फ़ाइलों को लिखने की आवश्यकता है, तो उस स्थान पर एक tmpfs वॉल्यूम माउंट करें।
4. उपयोगकर्ता नेमस्पेस रीमैपिंग सक्षम करें
उपयोगकर्ता नेमस्पेस रीमैपिंग कंटेनर के रूट उपयोगकर्ता को एक गैर-रूट होस्ट उपयोगकर्ता पर मैप करता है। यह अलगाव की एक परत जोड़ता है, क्योंकि भले ही कंटेनर रूट से बाहर निकल जाए, उनके पास रीमैप किए गए उपयोगकर्ता के विशेषाधिकार होंगे। इसे /etc/docker/daemon.json में "userns-remap": "default" के साथ सक्षम करें। ध्यान रखें कि यह वॉल्यूम अनुमतियों को जटिल बना सकता है। अधिक विवरण के लिए, सुरक्षित और कुशल वेब होस्टिंग के लिए डॉकर आइसोलेशन में महारत हासिल करना देखें।
5. Seccomp और AppArmor/AppArmor प्रोफाइल लागू करें
Seccomp एक कंटेनर द्वारा की जा सकने वाली सिस्टम कॉल को प्रतिबंधित करता है। डॉकर खतरनाक सिस्टम कॉल को ब्लॉक करने वाली एक डिफ़ॉल्ट seccomp प्रोफ़ाइल प्रदान करता है। आप कस्टम प्रोफाइल भी बना सकते हैं। इसी तरह, AppArmor (या SELinux) अनिवार्य पहुंच नियंत्रण प्रदान करता है। AppArmor का उपयोग आपके कंटेनर को अनुमत संचालन के न्यूनतम सेट तक सीमित करने के लिए करें। सुरक्षा प्रोफ़ाइल को डॉकर कंपोज़ में security_opt के माध्यम से सेट किया जा सकता है।
6. न्यूनतम बेस छवियों का उपयोग करें और कमजोरियों के लिए स्कैन करें
Alpine या Distroless जैसी छोटी छवियों को चुनें जिनमें एक छोटी हमला सतह हो। नियमित रूप से Docker Scout, Trivy, या Clair जैसे टूल से छवियों को स्कैन करें। तैनात होने वाली कमजोर छवियों को रोकने के लिए स्कैनिंग को अपने CI/CD पाइपलाइन में एकीकृत करें।
7. कस्टम ब्रिज नेटवर्क के साथ नेटवर्क विभाजन
प्रत्येक टेनेंट या एप्लिकेशन टियर के लिए अलग-अलग ब्रिज नेटवर्क बनाएं। यह पूर्व-पश्चिम यातायात को सीमित करता है। डॉकर कंपोज़ में, नेटवर्क को परिभाषित करें और सेवाओं को अलग करें। यदि किसी सेवा को आउटगोइंग इंटरनेट एक्सेस की आवश्यकता नहीं है तो internal: true का उपयोग करें। होस्ट पर फ़ायरवॉल नियम इंटर-कंटेनर यातायात को और प्रतिबंधित करते हैं।
8. Cgroups के साथ संसाधनों को सीमित करें
डॉकर कंपोज़ में deploy.resources.limits का उपयोग करके CPU और मेमोरी सीमाएं सेट करें। यह एक समझौता किए गए कंटेनर को संसाधन थकावट हमले को लॉन्च करने से रोकता है। इसके अतिरिक्त, महीन नियंत्रण के लिए kernel_memory और memory_reservation सेट करें।
वास्तविक दुनिया उदाहरण: डॉकर कंपोज़ के साथ मल्टी-टेनेंट वर्डप्रेस होस्टिंग
एक परिदृश्य पर विचार करें जहां आप विभिन्न ग्राहकों के लिए कई वर्डप्रेस साइटों को होस्ट करते हैं, प्रत्येक अपने डॉकर कंटेनर में। एक असुरक्षित सेटअप इस तरह दिख सकता है:
version: '3'
services:
wordpress:
image: wordpress:latest
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: exampleuser
WORDPRESS_DB_PASSWORD: examplepass
WORDPRESS_DB_NAME: exampledb
volumes:
- ./wp-content:/var/www/html/wp-content
db:
image: mysql:5.7
environment:
MYSQL_DATABASE: exampledb
MYSQL_USER: exampleuser
MYSQL_PASSWORD: examplepass
MYSQL_ROOT_PASSWORD: somewordpress
volumes:
- db_data:/var/lib/mysql
volumes:
db_data:
यह सेटअप असुरक्षित है: वर्डप्रेस कंटेनर अंदर रूट के रूप में चलता है, इसमें सभी क्षमताएं हैं (क्योंकि कोई भी छोड़ी नहीं गई है), लिखने की अनुमति के साथ एक होस्ट निर्देशिका माउंट करता है, और इसमें अप्रतिबंधित नेटवर्क एक्सेस है।
अब इसे मजबूत करते हैं:
version: '3'
services:
wordpress:
image: wordpress:latest
user: www-data
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
read_only: true
tmpfs:
- /var/www/html/wp-content/plugins
security_opt:
- seccomp=seccomp-profile.json
- apparmor=wordpress-profile
networks:
- frontend
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: exampleuser
WORDPRESS_DB_PASSWORD: examplepass
WORDPRESS_DB_NAME: exampledb
volumes:
- wp-uploads:/var/www/html/wp-content/uploads
deploy:
resources:
limits:
cpus: '0.5'
memory: 256M
db:
image: mysql:5.7
user: mysql
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
networks:
- backend
environment:
MYSQL_DATABASE: exampledb
MYSQL_USER: exampleuser
MYSQL_PASSWORD: examplepass
MYSQL_ROOT_PASSWORD: somewordpress
volumes:
- db_data:/var/lib/mysql
deploy:
resources:
limits:
cpus: '0.25'
memory: 128M
networks:
frontend:
driver: bridge
internal: false
backend:
driver: bridge
internal: true
volumes:
wp-uploads:
db_data:
मुख्य सुधार:
- दोनों कंटेनर गैर-रूट उपयोगकर्ताओं (
www-dataऔरmysql) के रूप में चलते हैं। - सभी क्षमताएं छोड़ी गईं, केवल
NET_BIND_SERVICEजोड़ा गया। - वर्डप्रेस फ़ाइलसिस्टम केवल-पढ़ने के लिए है सिवाय एक tmpfs माउंट और एक अपलोड वॉल्यूम के।
- Seccomp और AppArmor प्रोफाइल लागू किए गए हैं (आपको कस्टम प्रोफाइल प्रदान करने की आवश्यकता होगी)।
- अलग-अलग नेटवर्क वेब को डेटाबेस से अलग करते हैं, डेटाबेस नेटवर्क आंतरिक है।
- संसाधन सीमाएं संसाधन थकावट को रोकती हैं।
वर्डप्रेस-विशिष्ट डॉकर हार्डनिंग पर अधिक जानकारी के लिए, डॉकर फॉर वर्डप्रेस: आइसोलेटेड कंटेनर सब कुछ कैसे बदलते हैं देखें।
चेतावनियां
- उपयोगकर्ता नेमस्पेस रीमैपिंग: शक्तिशाली होने के बावजूद, यह वॉल्यूम माउंटिंग को तोड़ता है क्योंकि रीमैप किया गया होस्ट UID कंटेनर UID के समान नहीं होता है। आपको सही अनुमतियों के साथ निर्देशिकाओं को पहले से बनाने की आवश्यकता हो सकती है या रीमैपिंग समर्थन के साथ डॉकर वॉल्यूम का उपयोग करना पड़ सकता है।
- Seccomp/AppArmor प्रोफाइल: कस्टम प्रोफाइल के लिए आपके एप्लिकेशन की सिस्टम कॉल और फ़ाइल एक्सेस पैटर्न को समझने की आवश्यकता होती है। अत्यधिक प्रतिबंधात्मक प्रोफाइल कार्यक्षमता को तोड़ सकते हैं। अच्छी तरह से परीक्षण करें।
- प्रदर्शन: Seccomp और AppArmor जैसी अतिरिक्त सुरक्षा परतें न्यूनतम ओवरहेड होती हैं, लेकिन संसाधन सीमाएं और केवल-पढ़ने के लिए फ़ाइलसिस्टम लिखने-भारी अनुप्रयोगों को प्रभावित कर सकते हैं।
- ऑर्केस्ट्रेशन जटिलता: एक मल्टी-टेनेंट वातावरण में, प्रति-टेनेंट डॉकर कंपोज़ फ़ाइलों का प्रबंधन बोझिल हो सकता है। Kubernetes जैसे उच्च-स्तरीय ऑर्केस्ट्रेशन टूल का उपयोग करने पर विचार करें, लेकिन यह अपनी सुरक्षा संबंधी विचार लाता है।
निष्कर्ष
कंटेनर एस्केप मल्टी-टेनेंट डॉकर होस्टिंग में एक वास्तविक खतरा है, लेकिन इसे रोका जा सकता है। अलगाव तंत्र को समझकर और गहराई से बचाव लागू करके—क्षमताओं को छोड़कर, गैर-रूट के रूप में चल रहा है, उपयोगकर्ता नेमस्पेस को सक्षम करना, seccomp, AppArmor, नेटवर्क विभाजन, और नियमित छवि स्कैनिंग—आप जोखिम को काफी कम कर सकते हैं। याद रखें कि डॉकर की डिफ़ॉल्ट सेटिंग्स मल्टी-टेनेंट वर्कलोड के लिए उत्पादन-तैयार नहीं हैं। अपने टेनेंट्स और अपने इंफ्रास्ट्रक्चर की सुरक्षा के लिए आज ही इन चरणों को लागू करें। डॉकर सुरक्षा सर्वोत्तम प्रथाओं के एक व्यापक अवलोकन के लिए, डॉकर के साथ अपने वेब अनुप्रयोगों को सुरक्षित करना: अलगाव और सर्वोत्तम प्रथाओं पर एक व्यावहारिक मार्गदर्शिका देखें।
Sources (5)
- Docker and Container Isolation - Medium
- What is container isolation? Mechanisms, limitations, and secure runtimes | Blog - Northflank
- Container Isolation Explained for Kubernetes and Beyond - Edera
- Docker Security: 5 Risks and 12 Best Practices for Securing Your Containers - Tigera.io
- 9 Security Best Practices for Docker Containers - Kinsta®

