🚯 👔 🛌🏽 सुरक्षा क्रिब: डॉकटर ◻️ 🎲 🚺

डॉकर कंटेनर सबसे लोकप्रिय कंटेनरीकरण तकनीक हैं। प्रारंभ में, इसका उपयोग मुख्य रूप से देव और परीक्षण वातावरण के लिए किया गया था, और समय के साथ यह उत्पादन में बदल गया। बारिश के बाद मशरूम की तरह डॉकटर कंटेनर उत्पादन वातावरण में गुणा करना शुरू कर दिया, हालांकि इस तकनीक का उपयोग करने वालों में से कुछ ने इस बारे में सोचा कि डॉक कंटेनर को सुरक्षित रूप से कैसे प्रकाशित किया जाए।

ओडब्ल्यूएएसपी के आधार पर, हमने नियमों की एक सूची तैयार की है, जिसके कार्यान्वयन से डॉकटर कंटेनरों पर निर्मित आपके पर्यावरण की सुरक्षा होगी।

नियम ०

होस्ट मशीन और डॉकर में सभी वर्तमान अपडेट होने चाहिए।

कंटेनर पर्यावरण से बचने के लिए जाने जाने वाली कमजोरियों से बचने के लिए मेजबान प्रणाली, जो आमतौर पर मेजबान सिस्टम पर विशेषाधिकार वृद्धि का कारण बनती है, मेजबान ओएस, डॉकर इंजन और डॉकर मशीन के लिए सभी पैच स्थापित करना बेहद महत्वपूर्ण है।

इसके अलावा, कंटेनर (वर्चुअल मशीनों के विपरीत) होस्ट के साथ कर्नेल साझा करते हैं, इसलिए कंटेनर के अंदर चलने वाला कर्नेल सीधे होस्ट कर्नेल में चलता है। उदाहरण के लिए, एक कर्नेल विशेषाधिकार वृद्धि (जैसे कि गंदे गाय) के रूप में एक अच्छी तरह से पृथक कंटेनर के अंदर चलने से मेजबान पर रूट एक्सेस हो जाएगा।

नियम १

डोकर डेमॉन के सॉकेट तक पहुंच न दें

Docker सेवा (डेमॉन) आने वाले API कनेक्शन के लिए UNIX सॉकेट /var/run/docker.sock का उपयोग करती है। इस संसाधन का स्वामी मूल उपयोगकर्ता होना चाहिए। और कोई उपाय नहीं। इस सॉकेट में एक्सेस अधिकार बदलना अनिवार्य रूप से होस्ट सिस्टम को रूट एक्सेस देने के बराबर है।

इसके अलावा, आपको कंटेनरों के साथ /var/run/docker.sock सॉकेट को बंद नहीं करना चाहिए, जहां आप इसके बिना कर सकते हैं, क्योंकि इस मामले में, कंटेनर में सेवा से समझौता करने से मेजबान सिस्टम पर पूरा नियंत्रण हो जाएगा। यदि आपके पास कंटेनर हैं जो कुछ इस तरह का उपयोग करते हैं:

-v /var/run/docker.sock://var/run/docker.sock

या डॉकटर-कम्पोज़ के लिए:

 volumes: - "/var/run/docker.sock:/var/run/docker.sock"

इसे बदलने की तत्काल आवश्यकता है।

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

नियम २

कंटेनर के अंदर एक अप्रकाशित उपयोगकर्ता कॉन्फ़िगर करें

एक विशेषाधिकार प्राप्त उपयोगकर्ता का उपयोग करने के लिए एक कंटेनर को कॉन्फ़िगर करना एक विशेषाधिकार वृद्धि हमले से बचने का सबसे अच्छा तरीका है। यह विभिन्न तरीकों से किया जा सकता है:

1. "डॉक रन" कमांड के "-u" विकल्प का उपयोग करना:

 docker run -u 4000 alpine

2. छवि निर्माण के दौरान:

 FROM alpine RUN groupadd -r myuser && useradd -r -g myuser myuser <      root-, ,  > USER myuser

3. डॉकर डेमॉन में "यूजर नेमस्पेस" (उपयोगकर्ता पर्यावरण) के लिए समर्थन सक्षम करें:

 --userns-remap=default

आधिकारिक प्रलेखन में इसके बारे में अधिक पढ़ें।

Kubernetes में, बाद में runAsNonRoot विकल्प के माध्यम से सुरक्षा संदर्भ में कॉन्फ़िगर किया गया है:

 kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... runAsNonRoot: true ...

नियम ३

कंटेनर क्षमताओं को सीमित करें

लिनक्स पर, कर्नेल 2.2 से शुरू होकर, लिनक्स कर्नेल क्षमताओं (विवरण के लिए, लिंक देखें) नामक विशेषाधिकार प्राप्त प्रक्रियाओं की क्षमताओं को नियंत्रित करने का एक तरीका है।

डोकर डिफ़ॉल्ट रूप से इन कर्नेल सुविधाओं के पूर्वनिर्धारित सेट का उपयोग करता है। और यह आपको कमांड का उपयोग करके इस सेट को बदलने की अनुमति देता है:

 --cap-drop —     --cap-add —

सबसे अच्छी सुरक्षा सेटिंग पहले सभी सुविधाओं को निष्क्रिय करना है (- सभी ड्रॉप), और उसके बाद केवल आवश्यक लोगों को कनेक्ट करें। उदाहरण के लिए, इस तरह:

 docker run --cap-drop all --cap-add CHOWN alpine

और सबसे महत्वपूर्ण (!): -प्राप्त ध्वज के साथ कंटेनर चलाने से बचें !!!

Kubernetes में, Linux कर्नेल क्षमताओं की बाधा को सुरक्षा के संदर्भ में क्षमताओं के विकल्प के माध्यम से कॉन्फ़िगर किया गया है:

 kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... capabilities: drop: - all add: - CHOWN ...

नियम ४

नो-न्यू-विशेषाधिकार ध्वज का उपयोग करें

कंटेनर शुरू करते समय, यह उपयोग करने के लिए उपयोगी है - सुरक्षा-ऑप्ट = नो-न्यू-विशेषाधिकार ध्वज जो कंटेनर के अंदर विशेषाधिकार वृद्धि को रोकता है।

Kubernetes में, लिनक्स कर्नेल क्षमताओं की बाधा सुरक्षा के संदर्भ में AllowPrivilegeEscalation विकल्प के माध्यम से कॉन्फ़िगर की गई है:

 kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... allowPrivilegeEscalation: false ...

नियम ५

इंटर-कंटेनर संचार बंद करें

डिफ़ॉल्ट रूप से, डॉकर में अंतर-कंटेनर संचार सक्षम होता है, जिसका अर्थ है कि सभी कंटेनर एक दूसरे के साथ संवाद कर सकते हैं (docker0 नेटवर्क का उपयोग करके)। इस सुविधा को -cc = झूठे झंडे के साथ डॉकर सेवा चलाकर अक्षम किया जा सकता है।

नियम ६

लिनक्स सुरक्षा मॉड्यूल का उपयोग करें (Linux सुरक्षा मॉड्यूल - seccomp, AppArmor, SELinux)

डिफ़ॉल्ट रूप से, डॉकर पहले से ही लिनक्स सुरक्षा मॉड्यूल के लिए प्रोफाइल का उपयोग करता है। इसलिए, सुरक्षा प्रोफ़ाइल को कभी भी अक्षम न करें! अधिकतम जो उनके साथ किया जा सकता है वह नियमों को कसने के लिए है।

Seccomp के लिए डिफ़ॉल्ट प्रोफ़ाइल यहाँ उपलब्ध है ।

Docker सुरक्षा के लिए AppArmor का भी उपयोग करता है, और Docker Engine स्वयं कंटेनर शुरू होने पर AppArmor के लिए एक डिफ़ॉल्ट प्रोफ़ाइल बनाता है। दूसरे शब्दों में, इसके बजाय:

 $ docker run --rm -it hello-world

शुरू होता है:

 $ docker run --rm -it --security-opt apparmor=docker-default hello-world

प्रलेखन भी nginx के लिए एक AppArmor प्रोफ़ाइल का एक उदाहरण प्रदान करता है, जो उपयोग करने के लिए काफी संभव है (आवश्यक!)

 #include <tunables/global> profile docker-nginx flags=(attach_disconnected,mediate_deleted) { #include <abstractions/base> network inet tcp, network inet udp, network inet icmp, deny network raw, deny network packet, file, umount, deny /bin/** wl, deny /boot/** wl, deny /dev/** wl, deny /etc/** wl, deny /home/** wl, deny /lib/** wl, deny /lib64/** wl, deny /media/** wl, deny /mnt/** wl, deny /opt/** wl, deny /proc/** wl, deny /root/** wl, deny /sbin/** wl, deny /srv/** wl, deny /tmp/** wl, deny /sys/** wl, deny /usr/** wl, audit /** w, /var/run/nginx.pid w, /usr/sbin/nginx ix, deny /bin/dash mrwklx, deny /bin/sh mrwklx, deny /usr/bin/top mrwklx, capability chown, capability dac_override, capability setuid, capability setgid, capability net_bind_service, deny @{PROC}/* w, # deny write for all files directly in /proc (not in a subdir) # deny write to files not in /proc/<number>/** or /proc/sys/** deny @{PROC}/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9]*}/** w, deny @{PROC}/sys/[^k]** w, # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel) deny @{PROC}/sys/kernel/{?,??,[^s][^h][^m]**} w, # deny everything except shm* in /proc/sys/kernel/ deny @{PROC}/sysrq-trigger rwklx, deny @{PROC}/mem rwklx, deny @{PROC}/kmem rwklx, deny @{PROC}/kcore rwklx, deny mount, deny /sys/[^f]*/** wklx, deny /sys/f[^s]*/** wklx, deny /sys/fs/[^c]*/** wklx, deny /sys/fs/c[^g]*/** wklx, deny /sys/fs/cg[^r]*/** wklx, deny /sys/firmware/** rwklx, deny /sys/kernel/security/** rwklx, }

नियम 7

कंटेनर संसाधनों को सीमित करें

यह नियम काफी सरल है: कंटेनरों को अगले DoS / DDoS हमले के दौरान सभी सर्वर संसाधनों को नष्ट करने से रोकने के लिए, हम व्यक्तिगत रूप से प्रत्येक कंटेनर के लिए मेमोरी उपयोग सीमा निर्धारित कर सकते हैं। आप सीमित कर सकते हैं: मेमोरी की मात्रा, सीपीयू, कंटेनर पुनरारंभ की संख्या।

तो चलिए क्रम में।

स्मृति

-M या --memory विकल्प

एक कंटेनर में अधिकतम मात्रा में मेमोरी का उपयोग किया जा सकता है। न्यूनतम मूल्य 4 मीटर (4 मेगाबाइट) है।

विकल्प - स्तन-स्वैप

स्वैप (स्वैप फ़ाइल) को कॉन्फ़िगर करने का विकल्प। चालाकी से कॉन्फ़िगर किया गया:

यदि --ememory-swap> 0 है, तो –ememory ध्वज को भी सेट करना होगा। इस मामले में, मेमोरी-स्वैप दिखाता है कि स्वैप के साथ कंटेनर को कुल मेमोरी कितनी उपलब्ध है।
एक सरल उदाहरण। यदि --memory = "300m", और --emory-swap = "1g" है, तो कंटेनर 300MB मेमोरी और 700MB स्वैप (1g - 300m) का उपयोग कर सकता है।
यदि - मिमोरी-स्वैप = 0, सेटिंग को अनदेखा किया जाता है।
यदि - मीमोरी-स्वैप को समान मान के रूप में सेट किया जाता है, तो कंटेनर में स्वैप नहीं होगा।
यदि --memory-swap निर्दिष्ट नहीं है, लेकिन - memory निर्दिष्ट है, तो स्वैप की संख्या निर्दिष्ट मेमोरी की मात्रा के दोगुने के बराबर होगी। उदाहरण के लिए, यदि --memory = "300m", और --ememory-swap सेट नहीं है, तो कंटेनर 300MB मेमोरी और 600MB स्वैप का उपयोग करेगा।
यदि - मिमोरी-स्वैप = -1, तो कंटेनर सभी स्वैप का उपयोग करेगा जो मेजबान सिस्टम पर संभव है।

परिचारिका पर ध्यान दें: कंटेनर के अंदर शुरू की गई मुफ्त उपयोगिता कंटेनर के लिए उपलब्ध स्वैप का वास्तविक मूल्य नहीं दिखाती है, लेकिन मेजबान स्वैप की संख्या।

विकल्प --oom-मार-अक्षम करें

आपको OOM (आउट ऑफ़ मेमोरी) हत्यारे को सक्षम या अक्षम करने की अनुमति देता है।

चेतावनी! आप OOM किलर को केवल --memory विकल्प सेट के साथ बंद कर सकते हैं, अन्यथा ऐसा हो सकता है कि कंटेनर के अंदर-बाहर मेमोरी के साथ, कर्नेल होस्ट सिस्टम प्रक्रियाओं को मारना शुरू कर देगा।

अन्य स्मृति प्रबंधन कॉन्फ़िगरेशन विकल्प, जैसे --memory-swappiness, --memory- आरक्षण, और - कर्नेल-मेमोरी, कंटेनर के प्रदर्शन को ट्यून करने के लिए अधिक हैं।

प्रोसेसर

विकल्प - कार्पस

विकल्प सेट करता है कि कंटेनर कितने उपलब्ध प्रोसेसर संसाधनों का उपयोग कर सकता है। उदाहरण के लिए, यदि हमारे पास दो सीपीयू के साथ एक मेजबान है और हम --cpus = "1.5" सेट करते हैं, तो कंटेनर को डेढ़ प्रोसेसर का उपयोग करने की गारंटी है।

विकल्प - सीपीयू-सीपस

विशिष्ट कोर या सीपीयू के उपयोग को कॉन्फ़िगर करता है। मान एक हाइफ़न या अल्पविराम के साथ निर्दिष्ट किया जा सकता है। पहले मामले में, अनुमत कोर की सीमा को इंगित किया जाएगा, दूसरे में - विशिष्ट कोर।

कंटेनर पुनरारंभ की संख्या

 --restart=on-failure:<number_of_restarts>

यदि यह अप्रत्याशित रूप से क्रैश हो जाता है, तो यह सेटिंग सेट करती है कि कितनी बार डोकर कंटेनर को पुनः आरंभ करने का प्रयास करेगा। यदि कंटेनर की स्थिति चल रही है, तो काउंटर रीसेट कर दिया गया है।

एक छोटी सकारात्मक संख्या निर्धारित करने की सिफारिश की जाती है, उदाहरण के लिए, 5, जो एक गैर-कार्यशील सेवा के अंतहीन पुनरारंभ से बचना होगा।

नियम 8

रीड-ओनली फाइल सिस्टम और वॉल्यूम का उपयोग करें

यदि कंटेनर को कहीं भी कुछ भी नहीं लिखना चाहिए, तो आपको यथासंभव रीड-ओनली फ़ाइल सिस्टम का उपयोग करने की आवश्यकता है। यह एक संभावित घुसपैठिये के जीवन को बहुत जटिल करेगा।

केवल-पढ़ने के लिए फ़ाइल सिस्टम के साथ एक कंटेनर शुरू करने का एक उदाहरण:

 docker run --read-only alpine

रीड-ओनली मोड में वॉल्यूम कनेक्ट करने का एक उदाहरण:

 docker run -v volume-name:/path/in/container:ro alpine

नियम ९

कंटेनर सुरक्षा विश्लेषण उपकरण का उपयोग करें

ज्ञात कमजोरियों वाले कंटेनरों का पता लगाने के लिए उपकरणों का उपयोग किया जाना चाहिए। उनमें से बहुत सारे अभी तक नहीं हैं, लेकिन वे हैं:

• नि: शुल्क

क्लैर।

• वाणिज्यिक:

Snyk (एक मुक्त संस्करण है);
लंगर (एक मुक्त संस्करण है);
जेफ्रोग एक्सरे ;
गुण ।

और कुबेरनेट्स के लिए, कॉन्फ़िगरेशन त्रुटियों का पता लगाने के लिए उपकरण हैं:

सुरक्षा क्रिब: डॉकटर