कॉन्फ़िगरेशन और सीक्रेट कहाँ रखें

सेवा URL और फ़ीचर फ़्लैग जैसी गैर-संवेदनशील सेटिंग को पासवर्ड, API key और निजी key जैसे क्रेडेंशियल से अलग तरीके से संभालें। असली क्रेडेंशियल कोड में न लिखें और उनमें वास्तविक मान वाली फ़ाइलें साझा रिपॉज़िटरी में कमिट न करें। पहले जाँचें कि ऐप कौन-से कॉन्फ़िगरेशन तरीके स्वीकार करता है।

टूल समर्थन करे तो हर डेवलपर के स्थानीय मान .env फ़ाइल में रखें और केवल वेरिएबल नामों व नमूना मानों वाला .env.example साझा करें। असली .env को .gitignore में जोड़ें और जाँचें कि Git उसे पहले से ट्रैक तो नहीं कर रहा। Git की अनदेखी नियमावली सुरक्षित भंडार नहीं है और पुराने इतिहास से मान नहीं हटाती।

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

प्रोडक्शन में होस्टिंग या क्लाउड प्रदाता के सीक्रेट स्टोर को प्राथमिकता दें और सीमित करें कि कौन-सी तैनाती तथा सेवा हर मान पढ़ सकती है। Docker Compose स्पष्ट अनुमति वाली सेवाओं में सीक्रेट को फ़ाइल के रूप में माउंट कर सकता है; क्षमताएँ और सीमाएँ प्लेटफ़ॉर्म के अनुसार बदलती हैं, इसलिए वास्तविक रनटाइम का दस्तावेज़ देखें। समर्थन उपलब्ध हो तो लंबे समय तक चलने वाली key की जगह OIDC जैसे अल्पकालिक क्रेडेंशियल पर विचार करें।

यदि सीक्रेट किसी commit, CI लॉग या बातचीत में आ गया हो सकता है, तो दिखाई देने वाली प्रति हटाना पर्याप्त नहीं है। पहले संबंधित key या token रद्द करें या बदलें, फिर पहुँच लॉग और संभावित उपयोग की जाँच करें। इसके बाद ज़रूरत के अनुसार रिपॉज़िटरी इतिहास और लॉग संभालें तथा दोबारा ऐसा होने से रोकने के लिए पहुँच नियंत्रण कड़े करें।