Compose वैलिडेटर
कंटेनर जोखिम खोजें- !privileged: true लगभग होस्ट-स्तरीय पहुँच देता है।
- !पासवर्ड इनलाइन दिख रहा है। Secrets या बाहरी सीक्रेट स्टोर उपयोग करें।
- △:latest के बजाय छवि को अपरिवर्तनीय संस्करण या digest पर पिन करें।
- △प्रकाशित पोर्ट सभी इंटरफ़ेस पर खुला लगता है; जब संभव हो 127.0.0.1 से बाँधें।
- △जब रूट फ़ाइलसिस्टम लिखने योग्य न हो तो read_only: true पर विचार करें।
परिचय
Compose वैलिडेटर चिपकाए गए compose.yaml को पाँच कंटेनर-सुरक्षा जोखिमों के लिए जाँचता है जो उत्पादन घटनाओं में दिखते हैं: privileged मोड, सादे पाठ में रहस्य, अनपिन छवियाँ, सभी इंटरफ़ेस पर बंधे पोर्ट और लिखने योग्य रूट फ़ाइलसिस्टम।
Compose फ़ाइलें कॉन्फ़िगरेशन जैसी लगती हैं, लेकिन वे आपके कंटेनरों की सुरक्षा सीमा बन जाती हैं। यहाँ छोटी गलतियाँ सीधे होस्ट-स्तरीय जोखिम से जुड़ती हैं।
उद्देश्य
- privileged: true चिह्नित करना, जो लगभग होस्ट-स्तरीय पहुँच है।
- फ़ाइल में इनलाइन लिखे पासवर्ड और क्रेडेंशियल पहचानना।
- :latest छवि टैग पर चेतावनी देना, जो पुनरुत्पादनीय नहीं हैं।
- सभी इंटरफ़ेस पर खुले प्रकाशित पोर्ट और read_only: true की अनुपस्थिति पर चेतावनी देना।
इनपुट
- compose.yaml (या उसका services अनुभाग) की चिपकाई गई सामग्री।
- YAML संरचना गहराई से पार्स नहीं होती; जाँचें दृश्य पाठ पर पैटर्न-आधारित हैं।
यह कैसे काम करता है
फ़ाइल पाँच पैटर्न जाँचों से स्कैन होती है। privileged: true उच्च निष्कर्ष है क्योंकि यह लगभग हर capability देता है और अधिकांश अलगाव बंद करता है।
पासवर्ड असाइनमेंट (password: या PASSWORD=) वाली कोई भी पंक्ति उच्च निष्कर्ष है: रहस्य Docker secrets या बाहरी सीक्रेट स्टोर में होने चाहिए।
image: ...:latest चेतावनी देता है क्योंकि वही फ़ाइल समय के साथ अलग सामग्री खींच सकती है; अपरिवर्तनीय digest या पिन किया संस्करण पुनरुत्पादनीय है।
127.0.0.1 से न बंधा प्रकाशित पोर्ट (host:container) चेतावनी है, साथ ही अपने रूट फ़ाइलसिस्टम पर read_only: true के बिना सेवा भी।
परीक्षण योग्य उदाहरण
आज़माएँ — विश्लेषण आपके ब्राउज़र में स्थानीय रूप से चलता है।
उदाहरण
services:
api:
image: example/api:latest
ports:
- "8080:8080"
environment:
- DB_PASSWORD=change-me
privileged: trueअपेक्षित आउटपुट
उच्च: privileged: true लगभग होस्ट-स्तरीय पहुँच देता है। उच्च: पासवर्ड इनलाइन दिख रहा है। Secrets या बाहरी सीक्रेट स्टोर उपयोग करें। चेतावनी: :latest के बजाय छवि को अपरिवर्तनीय संस्करण या digest पर पिन करें। चेतावनी: प्रकाशित पोर्ट सभी इंटरफ़ेस पर खुला लगता है। चेतावनी: जब रूट फ़ाइलसिस्टम लिखने योग्य न हो तो read_only: true पर विचार करें।
आउटपुट पढ़ना
- जब संभव हो privileged मोड हटाएँ; अधिकांश कार्यभारों को केवल विशिष्ट capabilities चाहिए।
- इनलाइन रहस्य Docker secrets या बाहरी vault में ले जाएँ और जो कुछ भी commit हुआ उसे rotate करें।
- पिन किए टैग या digest तैनाती को पुनरुत्पादनीय और rollback को अनुमानित बनाते हैं।
- पोर्ट को 127.0.0.1 से बाँधना सेवाओं को निजी रखता है, जब तक कोई proxy जानबूझकर उन्हें उजागर न करे।
जोखिम
- समझौता किए गए कंटेनर पर privileged: true प्रभावी रूप से होस्ट समझौता है।
- इनलाइन पासवर्ड छवियों, रजिस्ट्रियों और लॉग में लीक होते हैं और कभी साफ़ rotate नहीं होते।
- :latest rollback तोड़ता है: कल की काम करती छवि आज की टूटी build से अधिलेखित हो सकती है।
सीमाएँ
- पैटर्न जाँचें YAML anchors, environment फ़ाइलों या Dockerfile निर्देशों से व्यक्त जोखिमों को खो सकती हैं।
- यह Compose पार्सर नहीं चलाता, इसलिए YAML सिंटैक्स त्रुटियाँ यहाँ रिपोर्ट नहीं होतीं।
- यह छवियों में स्वयं कमज़ोरियाँ नहीं पहचान सकता।
आधिकारिक संदर्भ
FAQ
privileged: true कब उचित है?
उत्पादन में लगभग कभी नहीं। कुछ लीगेसी ड्राइवर और विशेष डिवाइस पहुँच के लिए चाहिए; सुरक्षित मार्ग है बिल्कुल आवश्यक capabilities देना और हार्डवेयर पहुँच के लिए devices: उपयोग करना।
इनलाइन पासवर्ड के बजाय क्या उपयोग करूँ?
swarm के लिए Docker secrets, प्रतिबंधित अनुमतियों वाली environment फ़ाइलें और vault-शैली रहस्यों के लिए बाहरी संदर्भ। मुद्दा यह है कि रहस्य कभी compose फ़ाइल या छवि में न हों।
क्या read_only: true फ़ाइलें लिखने वाली apps तोड़ता है?
केवल यदि वे रूट फ़ाइलसिस्टम में लिखती हैं। लिखने योग्य पथ (uploads, caches) को volumes के रूप में माउंट किया जा सकता है या tmpfs से घोषित किया जा सकता है, बाकी केवल-पठनीय रहता है।