Docker Security
PreviousD-Bus Enumeration & Command Injection Privilege EscalationNextAbusing Docker Socket for Privilege Escalation
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Basic Docker Engine Security
Docker इंजन लिनक्स कर्नेल के Namespaces और Cgroups का उपयोग करके कंटेनरों को अलग करता है, जो सुरक्षा की एक बुनियादी परत प्रदान करता है। Capabilities dropping, Seccomp, और SELinux/AppArmor के माध्यम से अतिरिक्त सुरक्षा प्रदान की जाती है, जो कंटेनर अलगाव को बढ़ाती है। एक auth plugin उपयोगकर्ता क्रियाओं को और अधिक सीमित कर सकता है।
Secure Access to Docker Engine
Docker इंजन को या तो स्थानीय रूप से एक Unix सॉकेट के माध्यम से या HTTP का उपयोग करके दूरस्थ रूप से एक्सेस किया जा सकता है। दूरस्थ पहुंच के लिए, गोपनीयता, अखंडता और प्रमाणीकरण सुनिश्चित करने के लिए HTTPS और TLS का उपयोग करना आवश्यक है।
Docker इंजन, डिफ़ॉल्ट रूप से, unix:///var/run/docker.sock पर Unix सॉकेट पर सुनता है। उबंटू सिस्टम पर, Docker के स्टार्टअप विकल्प /etc/default/docker में परिभाषित होते हैं। Docker API और क्लाइंट के लिए दूरस्थ पहुंच सक्षम करने के लिए, HTTP सॉकेट के माध्यम से Docker डेमन को उजागर करने के लिए निम्नलिखित सेटिंग्स जोड़ें:
हालांकि, HTTP के माध्यम से Docker डेमन को उजागर करना सुरक्षा चिंताओं के कारण अनुशंसित नहीं है। कनेक्शनों को HTTPS का उपयोग करके सुरक्षित करना उचित है। कनेक्शन को सुरक्षित करने के लिए दो मुख्य दृष्टिकोण हैं:
क्लाइंट सर्वर की पहचान की पुष्टि करता है।
क्लाइंट और सर्वर एक-दूसरे की पहचान की आपसी पुष्टि करते हैं।
सर्वर की पहचान की पुष्टि करने के लिए प्रमाणपत्रों का उपयोग किया जाता है। दोनों विधियों के विस्तृत उदाहरणों के लिए, इस गाइड को देखें।
कंटेनर छवियों की सुरक्षा
कंटेनर छवियों को निजी या सार्वजनिक भंडार में संग्रहीत किया जा सकता है। Docker कंटेनर छवियों के लिए कई भंडारण विकल्प प्रदान करता है:
Docker Hub: Docker से एक सार्वजनिक रजिस्ट्री सेवा।
Docker Registry: एक ओपन-सोर्स प्रोजेक्ट जो उपयोगकर्ताओं को अपनी खुद की रजिस्ट्री होस्ट करने की अनुमति देता है।
Docker Trusted Registry: Docker का व्यावसायिक रजिस्ट्री प्रस्ताव, जिसमें भूमिका-आधारित उपयोगकर्ता प्रमाणीकरण और LDAP निर्देशिका सेवाओं के साथ एकीकरण शामिल है।
छवि स्कैनिंग
कंटेनरों में सुरक्षा कमजोरियाँ हो सकती हैं या तो आधार छवि के कारण या आधार छवि के शीर्ष पर स्थापित सॉफ़्टवेयर के कारण। Docker एक प्रोजेक्ट पर काम कर रहा है जिसे Nautilus कहा जाता है जो कंटेनरों का सुरक्षा स्कैन करता है और कमजोरियों की सूची बनाता है। Nautilus प्रत्येक कंटेनर छवि परत की तुलना कमजोरियों के भंडार से करता है ताकि सुरक्षा छिद्रों की पहचान की जा सके।
अधिक जानकारी के लिए इसे पढ़ें।
docker scan
docker scan कमांड आपको छवि नाम या ID का उपयोग करके मौजूदा Docker छवियों को स्कैन करने की अनुमति देता है। उदाहरण के लिए, hello-world छवि को स्कैन करने के लिए निम्नलिखित कमांड चलाएँ:
Docker Image Signing
Docker इमेज साइनिंग कंटेनरों में उपयोग की जाने वाली इमेजों की सुरक्षा और अखंडता सुनिश्चित करता है। यहाँ एक संक्षिप्त व्याख्या है:
Docker कंटेंट ट्रस्ट को सक्रिय करने के लिए, सेट करें
export DOCKER_CONTENT_TRUST=1। यह सुविधा Docker संस्करण 1.10 और बाद में डिफ़ॉल्ट रूप से बंद है।इस सुविधा को सक्षम करने के साथ, केवल साइन की गई इमेजों को डाउनलोड किया जा सकता है। प्रारंभिक इमेज पुश के लिए रूट और टैगिंग कुंजियों के लिए पासफ़्रेज़ सेट करना आवश्यक है, Docker Yubikey को भी बेहतर सुरक्षा के लिए समर्थन करता है। अधिक विवरण यहाँ मिल सकते हैं।
कंटेंट ट्रस्ट सक्षम होने पर एक असाइन की गई इमेज को खींचने का प्रयास करने पर "No trust data for latest" त्रुटि होती है।
पहले के बाद इमेज पुश के लिए, Docker इमेज को साइन करने के लिए रिपॉजिटरी कुंजी के पासफ़्रेज़ के लिए पूछता है।
अपने निजी कुंजियों का बैकअप लेने के लिए, कमांड का उपयोग करें:
जब डॉकर होस्ट को स्विच करते हैं, तो संचालन बनाए रखने के लिए रूट और रिपॉजिटरी कुंजियों को स्थानांतरित करना आवश्यक है।
Trickest का उपयोग करें ताकि दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित वर्कफ़्लो को आसानी से बनाया और स्वचालित किया जा सके। आज ही एक्सेस प्राप्त करें:
कंटेनर सुरक्षा विशेषताएँ
Namespaces
Namespaces लिनक्स कर्नेल की एक विशेषता है जो कर्नेल संसाधनों को विभाजित करती है ताकि एक सेट के प्रक्रियाएँ एक सेट के संसाधनों को देखें जबकि दूसरा सेट प्रक्रियाएँ एक अलग सेट के संसाधनों को देखती हैं। यह विशेषता संसाधनों और प्रक्रियाओं के एक सेट के लिए समान namespace होने के द्वारा काम करती है, लेकिन उन namespaces का संदर्भ अलग-अलग संसाधनों की ओर होता है। संसाधन कई स्थानों में मौजूद हो सकते हैं।
डॉकर कंटेनर अलगाव प्राप्त करने के लिए निम्नलिखित लिनक्स कर्नेल namespaces का उपयोग करता है:
pid namespace
mount namespace
network namespace
ipc namespace
UTS namespace
Namespaces के बारे में अधिक जानकारी के लिए निम्नलिखित पृष्ठ देखें:
Namespacescgroups
लिनक्स कर्नेल की विशेषता cgroups एक सेट के प्रक्रियाओं के बीच cpu, memory, io, network bandwidth जैसे संसाधनों को प्रतिबंधित करने की क्षमता प्रदान करती है। डॉकर cgroup विशेषता का उपयोग करके कंटेनर बनाने की अनुमति देता है जो विशिष्ट कंटेनर के लिए संसाधन नियंत्रण की अनुमति देता है। निम्नलिखित एक कंटेनर है जिसे उपयोगकर्ता स्थान मेमोरी को 500m, कर्नेल मेमोरी को 50m, cpu शेयर को 512, blkioweight को 400 पर सीमित किया गया है। CPU शेयर एक अनुपात है जो कंटेनर के CPU उपयोग को नियंत्रित करता है। इसका डिफ़ॉल्ट मान 1024 है और यह 0 से 1024 के बीच होता है। यदि तीन कंटेनरों का CPU शेयर 1024 है, तो प्रत्येक कंटेनर CPU संसाधन विवाद की स्थिति में CPU का 33% तक ले सकता है। blkio-weight एक अनुपात है जो कंटेनर के IO को नियंत्रित करता है। इसका डिफ़ॉल्ट मान 500 है और यह 10 से 1000 के बीच होता है।
किसी कंटेनर का cgroup प्राप्त करने के लिए आप कर सकते हैं:
For more information check:
CGroupsCapabilities
Capabilities allow root उपयोगकर्ता के लिए अनुमत क्षमताओं पर अधिक नियंत्रण। Docker Linux kernel capability feature का उपयोग करता है जिससे Container के अंदर किए जा सकने वाले कार्यों को सीमित किया जा सके, चाहे उपयोगकर्ता का प्रकार कोई भी हो।
जब एक docker container चलाया जाता है, तो प्रक्रिया संवेदनशील क्षमताओं को छोड़ देती है जिनका उपयोग प्रक्रिया अलगाव से भागने के लिए कर सकती है। यह सुनिश्चित करने की कोशिश करता है कि प्रक्रिया संवेदनशील क्रियाएँ करने और भागने में सक्षम न हो:
Linux CapabilitiesSeccomp in Docker
यह एक सुरक्षा विशेषता है जो Docker को syscalls को सीमित करने की अनुमति देती है जो कंटेनर के अंदर उपयोग की जा सकती हैं:
SeccompAppArmor in Docker
AppArmor एक kernel enhancement है जो containers को सीमित संसाधनों के एक सीमित सेट में प्रति-कार्यक्रम प्रोफाइल के साथ सीमित करता है।:
AppArmorSELinux in Docker
लेबलिंग सिस्टम: SELinux हर प्रक्रिया और फ़ाइल सिस्टम ऑब्जेक्ट को एक अद्वितीय लेबल असाइन करता है।
नीति प्रवर्तन: यह सुरक्षा नीतियों को लागू करता है जो परिभाषित करती हैं कि एक प्रक्रिया लेबल अन्य लेबल पर क्या क्रियाएँ कर सकती है।
कंटेनर प्रक्रिया लेबल: जब कंटेनर इंजन कंटेनर प्रक्रियाएँ आरंभ करते हैं, तो उन्हें आमतौर पर एक सीमित SELinux लेबल, सामान्यतः
container_tअसाइन किया जाता है।कंटेनरों के भीतर फ़ाइल लेबलिंग: कंटेनर के भीतर फ़ाइलें आमतौर पर
container_file_tके रूप में लेबल की जाती हैं।नीति नियम: SELinux नीति मुख्य रूप से यह सुनिश्चित करती है कि
container_tलेबल वाली प्रक्रियाएँ केवलcontainer_file_tके रूप में लेबल की गई फ़ाइलों के साथ इंटरैक्ट कर सकती हैं (पढ़ना, लिखना, निष्पादित करना)।
यह तंत्र सुनिश्चित करता है कि यदि कंटेनर के भीतर एक प्रक्रिया से समझौता किया जाता है, तो यह केवल उन वस्तुओं के साथ इंटरैक्ट करने तक सीमित है जिनके पास संबंधित लेबल हैं, जिससे ऐसे समझौतों से संभावित नुकसान को काफी हद तक सीमित किया जा सके।
SELinuxAuthZ & AuthN
Docker में, एक प्राधिकरण प्लगइन सुरक्षा में एक महत्वपूर्ण भूमिका निभाता है यह तय करते हुए कि Docker daemon को अनुरोधों को अनुमति दी जाए या ब्लॉक किया जाए। यह निर्णय दो प्रमुख संदर्भों की जांच करके किया जाता है:
प्रमाणीकरण संदर्भ: इसमें उपयोगकर्ता के बारे में व्यापक जानकारी शामिल होती है, जैसे कि वे कौन हैं और उन्होंने खुद को कैसे प्रमाणित किया है।
कमांड संदर्भ: इसमें किए जा रहे अनुरोध से संबंधित सभी प्रासंगिक डेटा शामिल होता है।
ये संदर्भ सुनिश्चित करने में मदद करते हैं कि केवल प्रमाणित उपयोगकर्ताओं से वैध अनुरोधों को संसाधित किया जाए, जिससे Docker संचालन की सुरक्षा बढ़ती है।
AuthZ& AuthN - Docker Access Authorization PluginDoS from a container
यदि आप एक कंटेनर द्वारा उपयोग किए जाने वाले संसाधनों को ठीक से सीमित नहीं कर रहे हैं, तो एक समझौता किया गया कंटेनर उस होस्ट को DoS कर सकता है जहाँ यह चल रहा है।
CPU DoS
बैंडविड्थ DoS
दिलचस्प Docker फ्लैग
--privileged फ्लैग
अगली पृष्ठ पर आप --privileged फ्लैग का क्या अर्थ है जान सकते हैं:
--security-opt
no-new-privileges
यदि आप एक कंटेनर चला रहे हैं जहाँ एक हमलावर एक निम्न विशेषाधिकार उपयोगकर्ता के रूप में पहुँच प्राप्त करने में सफल हो जाता है। यदि आपके पास एक गलत कॉन्फ़िगर किया गया suid बाइनरी है, तो हमलावर इसका दुरुपयोग कर सकता है और कंटेनर के अंदर विशेषाधिकार बढ़ा सकता है। जिससे, वह इससे भागने में सक्षम हो सकता है।
no-new-privileges विकल्प के साथ कंटेनर चलाने से इस प्रकार के विशेषाधिकार वृद्धि को रोका जा सकेगा।
अन्य
For more --security-opt options check: https://docs.docker.com/engine/reference/run/#security-configuration
अन्य सुरक्षा विचार
रहस्यों का प्रबंधन: सर्वोत्तम प्रथाएँ
यह महत्वपूर्ण है कि रहस्यों को सीधे Docker छवियों में या पर्यावरण चर का उपयोग करके एम्बेड करने से बचें, क्योंकि ये तरीके आपकी संवेदनशील जानकारी को किसी भी व्यक्ति के लिए उजागर करते हैं जो docker inspect या exec जैसे कमांड के माध्यम से कंटेनर तक पहुँच रखता है।
Docker वॉल्यूम एक सुरक्षित विकल्प हैं, जिन्हें संवेदनशील जानकारी तक पहुँचने के लिए अनुशंसित किया गया है। इन्हें अस्थायी फ़ाइल प्रणाली के रूप में मेमोरी में उपयोग किया जा सकता है, जो docker inspect और लॉगिंग से संबंधित जोखिमों को कम करता है। हालाँकि, रूट उपयोगकर्ता और जिनके पास कंटेनर तक exec पहुँच है, वे अभी भी रहस्यों तक पहुँच सकते हैं।
Docker रहस्य संवेदनशील जानकारी को संभालने के लिए एक और अधिक सुरक्षित विधि प्रदान करते हैं। उन उदाहरणों के लिए जिन्हें छवि निर्माण चरण के दौरान रहस्यों की आवश्यकता होती है, BuildKit एक कुशल समाधान प्रस्तुत करता है जो निर्माण-समय रहस्यों का समर्थन करता है, निर्माण गति को बढ़ाता है और अतिरिक्त सुविधाएँ प्रदान करता है।
BuildKit का लाभ उठाने के लिए, इसे तीन तरीकों से सक्रिय किया जा सकता है:
एक पर्यावरण चर के माध्यम से:
export DOCKER_BUILDKIT=1कमांड को पूर्ववर्ती करके:
DOCKER_BUILDKIT=1 docker build .Docker कॉन्फ़िगरेशन में इसे डिफ़ॉल्ट रूप से सक्षम करके:
{ "features": { "buildkit": true } }, इसके बाद Docker पुनः प्रारंभ करें।
BuildKit --secret विकल्प के साथ निर्माण-समय रहस्यों के उपयोग की अनुमति देता है, यह सुनिश्चित करते हुए कि ये रहस्य छवि निर्माण कैश या अंतिम छवि में शामिल नहीं हैं, जैसे कि:
रनिंग कंटेनर में आवश्यक रहस्यों के लिए, Docker Compose और Kubernetes मजबूत समाधान प्रदान करते हैं। Docker Compose सेवा परिभाषा में रहस्यों की फ़ाइलों को निर्दिष्ट करने के लिए secrets कुंजी का उपयोग करता है, जैसा कि docker-compose.yml उदाहरण में दिखाया गया है:
यह कॉन्फ़िगरेशन Docker Compose के साथ सेवाएँ शुरू करते समय रहस्यों के उपयोग की अनुमति देता है।
Kubernetes वातावरण में, रहस्य स्वाभाविक रूप से समर्थित होते हैं और Helm-Secrets जैसे उपकरणों के साथ और प्रबंधित किए जा सकते हैं। Kubernetes की भूमिका आधारित पहुँच नियंत्रण (RBAC) रहस्य प्रबंधन सुरक्षा को बढ़ाता है, जो Docker Enterprise के समान है।
gVisor
gVisor एक एप्लिकेशन कर्नेल है, जो Go में लिखा गया है, जो Linux सिस्टम सतह के एक महत्वपूर्ण हिस्से को लागू करता है। इसमें एक Open Container Initiative (OCI) रनटाइम शामिल है जिसे runsc कहा जाता है, जो एप्लिकेशन और होस्ट कर्नेल के बीच एक अलगाव सीमा प्रदान करता है। runsc रनटाइम Docker और Kubernetes के साथ एकीकृत होता है, जिससे सैंडबॉक्स किए गए कंटेनरों को चलाना सरल हो जाता है।
Kata Containers
Kata Containers एक ओपन-सोर्स समुदाय है जो हल्के वर्चुअल मशीनों के साथ एक सुरक्षित कंटेनर रनटाइम बनाने के लिए काम कर रहा है जो कंटेनरों की तरह महसूस और प्रदर्शन करते हैं, लेकिन हार्डवेयर वर्चुअलाइजेशन तकनीक का उपयोग करके मजबूत कार्यभार अलगाव प्रदान करते हैं।
सारांश टिप्स
--privilegedध्वज का उपयोग न करें या कंटेनर के अंदर Docker सॉकेट माउंट न करें। Docker सॉकेट कंटेनरों को स्पॉन करने की अनुमति देता है, इसलिए यह होस्ट पर पूर्ण नियंत्रण प्राप्त करने का एक आसान तरीका है, उदाहरण के लिए,--privilegedध्वज के साथ एक और कंटेनर चलाकर।कंटेनर के अंदर रूट के रूप में न चलाएँ। एक अलग उपयोगकर्ता का उपयोग करें और उपयोगकर्ता नामस्थान। कंटेनर में रूट वही होता है जो होस्ट पर होता है जब तक कि इसे उपयोगकर्ता नामस्थान के साथ पुनः मैप नहीं किया जाता। यह मुख्य रूप से Linux नामस्थान, क्षमताओं और cgroups द्वारा हल्के से प्रतिबंधित होता है।
सभी क्षमताएँ हटा दें (
--cap-drop=all) और केवल आवश्यक क्षमताएँ सक्षम करें (--cap-add=...)। कई कार्यभार को किसी भी क्षमताओं की आवश्यकता नहीं होती है और उन्हें जोड़ने से संभावित हमले का दायरा बढ़ जाता है।“no-new-privileges” सुरक्षा विकल्प का उपयोग करें ताकि प्रक्रियाएँ अधिक विशेषाधिकार प्राप्त न कर सकें, उदाहरण के लिए, suid बाइनरी के माध्यम से।
कंटेनर के लिए उपलब्ध संसाधनों को सीमित करें। संसाधन सीमाएँ मशीन को सेवा से इनकार के हमलों से बचा सकती हैं।
seccomp को समायोजित करें, AppArmor (या SELinux) प्रोफाइल को कंटेनर के लिए आवश्यक न्यूनतम क्रियाओं और syscalls को प्रतिबंधित करने के लिए।
आधिकारिक Docker छवियों का उपयोग करें और हस्ताक्षर की आवश्यकता करें या उनके आधार पर अपनी खुद की बनाएं। बैकडोर छवियों को विरासत में न लें या उपयोग न करें। रूट कुंजी, पासफ़्रेज़ को सुरक्षित स्थान पर भी संग्रहीत करें। Docker की UCP के साथ कुंजी प्रबंधित करने की योजनाएँ हैं।
नियमित रूप से अपनी छवियों को फिर से बनाएं ताकि होस्ट और छवियों पर सुरक्षा पैच लागू हो सकें।
अपने रहस्यों का बुद्धिमानी से प्रबंधन करें ताकि हमलावर के लिए उन्हें एक्सेस करना कठिन हो।
यदि आप Docker डेमन को उजागर करते हैं तो HTTPS का उपयोग करें क्लाइंट और सर्वर प्रमाणीकरण के साथ।
अपने Dockerfile में, ADD के बजाय COPY को प्राथमिकता दें। ADD स्वचालित रूप से ज़िप फ़ाइलों को निकालता है और URLs से फ़ाइलें कॉपी कर सकता है। COPY में ये क्षमताएँ नहीं होती हैं। जब भी संभव हो, ADD का उपयोग करने से बचें ताकि आप दूरस्थ URLs और ज़िप फ़ाइलों के माध्यम से हमलों के प्रति संवेदनशील न हों।
प्रत्येक माइक्रो-सर्विस के लिए अलग कंटेनर रखें
कंटेनर के अंदर ssh न रखें, "docker exec" का उपयोग कंटेनर में ssh करने के लिए किया जा सकता है।
छोटे कंटेनर छवियाँ रखें
Docker ब्रेकआउट / विशेषाधिकार वृद्धि
यदि आप Docker कंटेनर के अंदर हैं या आपके पास Docker समूह में एक उपयोगकर्ता तक पहुँच है, तो आप भागने और विशेषाधिकार बढ़ाने की कोशिश कर सकते हैं:
Docker Breakout / Privilege EscalationDocker प्रमाणीकरण प्लगइन बायपास
यदि आपके पास Docker सॉकेट तक पहुँच है या आपके पास Docker समूह में एक उपयोगकर्ता तक पहुँच है लेकिन आपकी क्रियाएँ एक Docker प्रमाणीकरण प्लगइन द्वारा सीमित हैं, तो जांचें कि क्या आप इसे बायपास कर सकते हैं:
AuthZ& AuthN - Docker Access Authorization PluginDocker को मजबूत करना
उपकरण docker-bench-security एक स्क्रिप्ट है जो उत्पादन में Docker कंटेनरों को तैनात करने के चारों ओर सामान्य सर्वोत्तम प्रथाओं की दर्जनों जांच करता है। परीक्षण सभी स्वचालित होते हैं, और CIS Docker Benchmark v1.3.1 पर आधारित होते हैं। आपको इसे Docker चला रहे होस्ट से या पर्याप्त विशेषाधिकार वाले कंटेनर से चलाना होगा। जानें README में इसे कैसे चलाना है: https://github.com/docker/docker-bench-security.
संदर्भ
Trickest का उपयोग करें ताकि आप दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित कार्यप्रवाहों को आसानी से बना और स्वचालित कर सकें। आज ही एक्सेस प्राप्त करें:
