VPN Compose फ़ाइल साझा कर रहे हैं? रेंडर की गई कॉपी से गोपनीय जानकारी हटाएँ

जब भी आप कोई Compose फ़ाइल साझा करते हैं, दो आर्टिफ़ैक्ट होते हैं: जो आपने लिखा, और जो कोई टूल चर बदलने के बाद रेंडर करता है। दूसरा अक्सर पहले से अधिक संवेदनशील होता है, और लोग बिना पढ़े जिसे किसी समस्या रिपोर्ट में चिपकाते हैं वह यही होता है। यदि आप केवल स्रोत फ़ाइल की समीक्षा करते हैं, तो आप गलत दस्तावेज़ की समीक्षा कर रहे हैं।

यह तय करने से पहले कि क्या हटाना है, तुलना करें कि प्रत्येक कॉपी में क्या हो सकता है।

रेंडर किया गया मॉडल एक अलग दस्तावेज़ है

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

संलग्न करने से पहले फ़ाइल स्वयं रेंडर करें और उस आउटपुट को वही आर्टिफ़ैक्ट मानें जिसकी आप समीक्षा कर रहे हैं। यदि आप इसे रेंडर नहीं कर सकते, तो आप नहीं जान सकते कि आप क्या प्रकाशित करने जा रहे हैं।

गोपनीय जानकारी कुंजी फ़ील्ड से अधिक जगहों पर बैठती है

स्पष्ट से शुरू करें: निजी कुंजियाँ, पहले से साझा की गई कुंजियाँ, टोकन, पासवर्ड और ऐसे कनेक्शन URL जिनमें क्रेडेंशियल अंतर्निहित हों। फिर वह सब देखें जिसकी ओर फ़ाइल इशारा करती है, क्योंकि संदर्भ कोई रिडैक्शन नहीं है। सेवा में माउंट की गई env फ़ाइल, होस्ट से बाइंड-माउंट की गई कॉन्फ़िगरेशन फ़ाइल, टोकन ले जाने वाला लेबल और पासवर्ड वाला कमांड आर्ग्युमेंट, YAML साफ़ दिखने पर भी परिनियोजन के साथ जाते हैं। आश्वस्त करने वाले नाम वाले चर में चिपकाई गई कुंजी भी कुंजी ही है।

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

गोपनीयता की घोषणा गोपनीयता नहीं है

Compose की गोपनीय ऑब्जेक्ट घोषणा को सामग्री से अलग करती हैं: सेवा को एक पथ या लक्ष्य मिलता है, और सामग्री कहीं और रहती है। सामग्री बदलते समय घोषणा रखना आम तौर पर सही अदला-बदली है, क्योंकि समीक्षक को देखना होता है कि गोपनीयता मौजूद है और कैसे माउंट की गई है। जो बचना नहीं चाहिए वह सामग्री स्वयं है।

लेबल और टिप्पणियाँ भी इसी व्यवहार की हक़दार हैं। कौन-सा वॉल्ट पथ उत्पादन कुंजी रखता है, यह बताने वाली टिप्पणी हमलावर को बताती है कि कहाँ देखना है, भले ही उसमें कोई कुंजी न हो।

आकार बनाए रखें ताकि फ़ाइल अब भी निदान कर सके

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

docker compose -f compose.yaml config > rendered.yaml
grep -nE 'PRIVATE_KEY|PASSWORD|TOKEN|PSK|PrivateKey|passphrase' rendered.yaml
wc -l rendered.yaml

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

यदि सामग्री उजागर हुई है, तो उसे बदलें

संलग्नक हटाने से वे कॉपियाँ नहीं हटतीं जो दूसरों ने पहले ही बना ली हैं, और मिरर तथा कैश अपनी-अपनी रखते हैं। जो भी लीक हुआ उसके लिए जारीकर्ता की निरसन और प्रतिस्थापन प्रक्रिया अपनाएँ, फिर परिनियोजन अपडेट करें। क्रम मायने रखता है, क्योंकि पहले बदलना और बाद में निरसन करना दो वैध क्रेडेंशियल वाली खिड़की छोड़ देता है।

सहायता थ्रेड में सटीक त्रुटि, इमेज संस्करण, नेटवर्क मोड और एक महत्वपूर्ण गैर-गोपनीय सेटिंग से शुरुआत करें। यह संयोजन अनुपस्थित डिवाइस या टूटे रूट को कुंजी से कहीं अधिक बार समझाता है।