जब आप किसी क्रेडेंशियल को AMI में जड़ देते हैं, तो वह इमेज की हर प्रति के साथ फैलता है, स्नैपशॉट में उकेरा रह जाता है और ऐसे खातों या रीजनों तक पहुँच सकता है जिनकी आपने कल्पना भी नहीं की थी। बस इतना काफ़ी है कि इमेज पर पढ़ने की पहुँच रखने वाला कोई उसे निकाल ले। और चूँकि इमेज संस्करणों के हिसाब से सहेजी जाती हैं, वह सीक्रेट उस दिन के बहुत बाद तक ज़िंदा रह सकता है जब आपने उसे बदल दिया मान लिया था।
सुनहरा नियम: इमेज मशीन को परिभाषित करती है; सीक्रेट रनटाइम पर सौंपे जाते हैं।
सीक्रेट कहाँ रहने चाहिए
| सेवा | क्लाउड या परिवेश | किसके लिए आदर्श |
|---|---|---|
| AWS Secrets Manager | AWS | बदले जा सकने वाले क्रेडेंशियल, नेटिव एकीकरण |
| AWS SSM Parameter Store | AWS | सरल पैरामीटर और सीक्रेट, कम लागत |
| HashiCorp Vault | मल्टीक्लाउड | गतिशील सीक्रेट और सूक्ष्म नियंत्रण |
| Azure Key Vault / Google Secret Manager | Azure / GCP | हर क्लाउड में नेटिव समकक्ष |
सीक्रेट किसी समर्पित प्रबंधक में रखें, कभी इमेज में या साफ़ पाठ user-data में नहीं।
सही पैटर्न: पासवर्ड नहीं, पहचान
किसी इंस्टेंस को संसाधनों तक पहुँच देने का सबसे सुरक्षित तरीक़ा उसे पासवर्ड देना नहीं, बल्कि पहचान देना है। AWS में इंस्टेंस से जुड़ी IAM भूमिका उसे अस्थायी और स्वतः बदलने वाले क्रेडेंशियल दिलाती है, बिना किसी कुंजी को इमेज में ले जाए।
- इंस्टेंस IAM भूमिकाएँ: इंस्टेंस भूमिका ग्रहण कर अस्थायी क्रेडेंशियल पाता है।
- Kubernetes में IRSA: प्रति पॉड पहचान, नोड पर साझा कुंजियों के बिना।
- Vault से गतिशील सीक्रेट: माँग पर बनने वाले अल्पजीवी क्रेडेंशियल।
- रनटाइम इंजेक्शन: एप्लिकेशन आरंभ में सीक्रेट प्रबंधक से पढ़ता है, बेक की गई फ़ाइल से नहीं।
मेटाडेटा की रक्षा करें: IMDSv2
भूमिका के अस्थायी क्रेडेंशियल इंस्टेंस मेटाडेटा सेवा से मिलते हैं। SSRF दोष का लाभ उठाकर कोई हमलावर उन्हें चुराने की कोशिश कर सकता है। IMDSv2 सत्र टोकन माँगता है और इस श्रेणी के हमलों को घटाता है: अपने लॉन्च में इसे अनिवार्य कर दें।
स्वच्छता: इमेज में निशान न छोड़ें
- AMI सील करने से पहले शेल इतिहास, क्रेडेंशियल वाले लॉग, अस्थायी SSH कुंजियाँ और सीक्रेट वाली कॉन्फ़िगरेशन फ़ाइलें मिटा दें।
- फ़ाइल सिस्टम के लिए अनुकूलित gitleaks या trufflehog जैसे औज़ारों से इमेज में सीक्रेट खोजें।
~/.ssh/authorized_keysमें अतिरिक्त अधिकृत कुंजियाँ न छोड़ें।- सीक्रेट वाली सार्वजनिक AMI से बचें: प्रकाशित करें तो जाँच लें कि कुछ लीक न हो।
त्वरित चेकलिस्ट
- इमेज में शून्य बेक्ड सीक्रेट।
- भूमिकाओं या फ़ेडरेटेड पहचान के साथ सीक्रेट प्रबंधक।
- IMDSv2 अनिवार्य।
- पाइपलाइन में सीक्रेट स्कैन।
- सील करने से पहले निशानों की सफ़ाई।
अक्सर पूछे जाने वाले सवाल
अगर मेरे एप्लिकेशन को बूट पर ही सीक्रेट चाहिए तो?
वह इंस्टेंस की पहचान का उपयोग कर रनटाइम पर सीक्रेट प्रबंधक से पढ़े। इस तरह सीक्रेट कभी इमेज के भीतर नहीं जाता और बिना पुनर्निर्माण बदला जा सकता है।
क्या सीक्रेट भेजने के लिए user-data इस्तेमाल करना सुरक्षित है?
साफ़ पाठ में नहीं: user-data मेटाडेटा से पढ़ा जा सकता है। ज़्यादा से ज़्यादा इसका उपयोग यह बताने के लिए करें कि प्रबंधक से कौन-सा सीक्रेट लाना है, और मेटाडेटा को IMDSv2 से बचाएँ।
कैसे पता करूँ कि किसी इमेज में पहले से बेक्ड सीक्रेट हैं?
उसके फ़ाइल सिस्टम पर सीक्रेट पहचान औज़ारों से स्कैन करके, और उपयोग से पहले कॉन्फ़िगरेशन फ़ाइलें, इतिहास और अधिकृत कुंजियाँ जाँचकर।
imaxe.cloud में हम क्रेडेंशियल से मुक्त इमेज बनाते हैं, जो सीक्रेट प्रबंधकों और फ़ेडरेटेड पहचान के साथ जुड़ने के लिए सोची गई हैं।
