कंटेनर्स को डिफ़ॉल्ट रूप से रूट के रूप में क्यों नहीं चलाना चाहिए?

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

"रूट के रूप में चलाना" वास्तव में क्या मतलब है

डिफ़ॉल्ट रूप से, कई कंटेनर इमेजेस (विशेष रूप से न्यूनतम या पुरानी वाली) अपनी मुख्य प्रक्रिया को कंटेनर के अंदर UID 0 के रूप में निष्पादित करती हैं। क्योंकि कंटेनर्स होस्ट कर्नेल को अन्य कंटेनर्स और होस्ट के साथ साझा करते हैं, एक कंटेनर के अंदर रूट पूरी तरह से अलग वर्चुअल मशीन पर रूट के समान नहीं है — लेकिन यह अभी भी इससे कहीं अधिक शक्तिशाली है। यदि कोई अटैकर रूट-स्वामित्व वाले कंटेनर के अंदर कोड निष्पादन प्राप्त करता है, तो वे अनुमति प्राप्त करते हैं:

• कंटेनर में माउंट की गई किसी भी फाइल के लिए पूर्ण रीड/राइट एक्सेस, इच्छित अनुमतियों की परवाह किए बिना
• पैकेजेस स्थापित करने, बाइनरीज को संशोधित करने, या एप्लिकेशन स्थिति में हेराफेरी करने की क्षमता
• कंटेनर ब्रेकआउट की ओर एक आसान रास्ता यदि कोई कर्नेल या रनटाइम कमजोरी दोहनीय हो
• माउंट की गई Docker सॉकेट या होस्ट फाइलसिस्टम पाथ जैसी गलतकॉन्फ़िगर की गई वॉल्यूमेस के साथ संयुक्त होने पर बढ़ी हुई शक्ति

कर्नेल एक्सप्लॉइट के बिना भी, कंटेनर के अंदर रूट एक्सेस किसी भी एप्लिकेशन-स्तरीय कमजोरी (SSRF, deserialization bugs, arbitrary file write, आदि) के ब्लास्ट रेडियस को नाटकीय रूप से बढ़ाता है।

यह ऑर्केस्ट्रेटेड वातावरण में अधिक महत्वपूर्ण क्यों है

Kubernetes क्लस्टर में, अत्यधिक Linux क्षमताओं या एक अनुमेय सुरक्षा संदर्भ के साथ एक रूट कंटेनर एक अटैकर को दे सकता है:

• /proc या /sys को इस तरह संशोधित करना जो होस्ट को प्रभावित करता है
• विशेषाधिकार बढ़ाएं यदि hostPID, hostNetwork, या hostIPC सक्षम हैं
• माउंट की गई सेवा खाता टोकन का दुरुपयोग करके क्लस्टर भर में पार्श्व रूप से pivot करें
• नोड पर escape करें यदि privileged: true सेट है या SYS_ADMIN जैसी खतरनाक क्षमताएं प्रदान की गई हैं

रूट यूजर ही हमेशा कमजोरी नहीं है — यह रूट प्लस अत्यधिक उदार कर्नेल क्षमताओं, होस्ट माउंटेस, या नेमस्पेस साझाकरण का संयोजन है जो एक contained compromise को cluster-wide में बदल देता है।

व्यावहारिक सख्ती के कदम

1. इमेज में एक गैर-रूट यूजर सेट करें

डिफ़ॉल्ट पर भरोसा करने के बजाय अपने Dockerfile में स्पष्ट रूप से एक गैर-रूट यूजर परिभाषित करें:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. इसे Orchestrator स्तर पर लागू करें

इमेज पर केवल भरोसा न करें — नीति को रनटाइम पर लागू करें। Kubernetes में, एक securityContext का उपयोग करें:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true पॉड को admission पर विफल करने का कारण बनता है यदि इमेज UID 0 के रूप में चलाने का प्रयास करती है, जो आपको एक best-effort convention के बजाय एक hard guarantee देता है।

3. अनावश्यक क्षमताओं को छोड़ें

अधिकांश एप्लिकेशनों को कंटेनर्स को दी जाने वाली डिफ़ॉल्ट Linux क्षमताओं में से कोई भी नहीं चाहिए। सब कुछ छोड़ दें और केवल वही जोड़ें जो सख्ती से आवश्यक है (कम पोर्ट्स को binding करने के दुर्लभ मामलों को NET_BIND_SERVICE की आवश्यकता हो सकती है)।

4. Privileged मोड और होस्ट नेमस्पेस साझाकरण से बचें

privileged: true, hostNetwork: true, और hostPID: true को बहुत ही विशिष्ट इंफ्रास्ट्रक्चर कार्यभारों के लिए आरक्षित किया जाना चाहिए (कुछ CNI या monitoring agents की तरह) — कभी भी सामान्य एप्लिकेशन कंटेनर्स के लिए नहीं।

5. नीति उपकरणों के साथ स्कैन करें और लागू करें

Admission controllers या नीति engines (जैसे Kyverno, OPA/Gatekeneeper) का उपयोग करें ताकि स्वचालित रूप से उन deployments को अस्वीकार किया जा सके जो इन नियमों का उल्लंघन करते हैं, मैनुअल कोड review पर निर्भर करने के बजाय। इसे CI में image scanning के साथ जोड़ी दें ताकि root-user इमेजेस को cluster तक पहुंचने से पहले पकड़ा जा सके।

एक स्तरीय, पूर्ण नहीं, रक्षा

गैर-रूट के रूप में चलाना जोखिम को पूरी तरह से नहीं हटाता है — कर्नेल-स्तर के कंटेनर escapes in-container यूजर से स्वतंत्र रूप से मौजूद हैं — लेकिन यह कम प्रयास वाले विशेषाधिकार escalation और पार्श्व गति तकनीकों की एक विशाल श्रेणी को हटाता है। read-only filesystems, dropped capabilities, और restrictive network policies के साथ मिलकर, यह एक defense-in-depth कंटेनर सुरक्षा रणनीति में सबसे सस्ते और सबसे प्रभावी परतों में से एक बनता है।

Cloud-native workloads को hardening करने पर गहराई तक जाना चाहते हैं? Cloud security और DevOps pipeline hardening पर संबंधित Korra Studio segments का अन्वेषण करें ताकि अपनी शेष defense-in-depth रणनीति को बनाया जा सके।