build और deployment पाइपलाइन में secrets कैसे संभालते हैं?

लंबे समय तक चलने वाले credentials पाइपलाइन से बाहर ही रखें। workload identity federation इस्तेमाल करें ताकि CI job एक अल्पजीवी OIDC token के बदले scoped role ले सके, और एप्लिकेशन secrets build time पर डालने की जगह runtime पर secrets manager से खींचें। हर secret को एक एनवायरनमेंट और एक consumer तक सीमित रखें, अपने आप rotate करें, access का audit रखें, और logs में उन्हें mask करें। secrets को कभी images में न पकाएं और key management के बिना उन्हें encrypted रूप में भी commit न करें।

मेरा शुरुआती रुख यह है कि पाइपलाइन के पास कोई भी लंबे समय तक चलने वाला cloud credential नहीं होना चाहिए। CI provider job के लिए एक signed identity token जारी करता है, cloud उस issuer पर भरोसा करता है, और job उसे बदलकर ऐसा role लेता है जो मिनटों तक चलता है और एक एनवायरनमेंट तक सीमित है। इससे वह पूरी श्रेणी मिट जाती है जिसमें कोई लीक हुई static key तीन साल तक रिपॉज़िटरी सेटिंग में पड़ी रहती है। एप्लिकेशन secrets अलग मामला हैं और उनकी जगह runtime है, जहां workload अपनी पहचान से secrets manager से उन्हें खींचता है, ताकि डेटाबेस पासवर्ड build से गुज़रे ही नहीं। अगर मुझे encrypted secrets git में रखने ही पड़ें, मसलन किसी GitOps रिपॉज़िटरी में, तो वे key management service के खिलाफ encrypted होते हैं, ताकि मैं असल में decryption का हक कंट्रोल कर रहा हूं, फाइल नहीं। सब कुछ कसकर scoped रहता है, तय समय पर rotate होता है, और access लॉग होता है। और मैं लीक के लिए तैयार रहता हूं: पहले revoke, फिर rotate, फिर audit trail से blast radius निकालो, क्योंकि revoke करने से पहले यह साबित करने बैठना कि किसी ने इस्तेमाल नहीं किया, उल्टा क्रम है।