प्रॉम्प्ट और दायरा
आपकी कंपनी GitHub Actions और सेल्फ-होस्टेड रनर्स से प्रतिदिन हज़ारों कंटेनर इमेज बनाती है। एक ऐसी सर्विस डिज़ाइन करें जो प्रत्येक इमेज के लिए ट्रेस करने योग्य बिल्ड प्रोवेनेंस उत्पन्न और सत्यापित करे, जिससे संगठनात्मक नीतियों (policies) के पास होने पर ही डिप्लॉयमेंट की अनुमति मिले। डेटा मॉडल, इश्युअंस, वेरिफिकेशन, ट्रस्ट रूट्स, की-रोटेशन, कॉम्प्रोमाइज़्ड रनर्स, ऑफ़लाइन डिप्लॉयमेंट, रोलबैक और ऑब्ज़र्वेबिलिटी को कवर करें।
पब्लिक सप्लाई-चेन सिक्योरिटी हायरिंग गाइडेंस एक व्यावहारिक सिस्टम-डिज़ाइन प्रॉम्प्ट का उपयोग करती है: हज़ारों सर्विसेज़ और मिक्स्ड रनर्स में प्रत्येक कंटेनर इमेज के लिए सत्यापन योग्य प्रोवेनेंस उत्पन्न करना। SLSA प्रोवेनेंस के उत्पादन, वितरण और सत्यापन को अलग करता है; Sigstore पहचान (identity), जारीकर्ता (issuer), हस्ताक्षर (signature) और आर्टिफ़ैक्ट-डाइजेस्ट जांचों का दस्तावेज़ीकरण करता है। समस्या ऑपरेशनल पॉलिसी के साथ एक ट्रस्ट चेन की है, न कि रजिस्ट्री रिकॉर्ड पर केवल एक सिग्नेचर फ़ील्ड की।
इंटरव्यूअर क्या जांच रहा है
- क्या आप आर्टिफ़ैक्ट डाइजेस्ट, प्रोवेनेंस क्लेम, सिग्नेचर, ट्रांसपेरेंसी लॉग और एडमिशन पॉलिसी के बीच अंतर करते हैं।
- क्या अनट्रस्टेड सोर्स, डिपेंडेंसीज़, बिल्ड कॉन्फ़िगरेशन और रनर्स थ्रेट मॉडल में दिखाई देते हैं।
- क्या क्लेम्स किसी म्यूटेबल टैग या असंबंधित टेक्स्ट के बजाय किसी इम्यूटिएबल आर्टिफ़ैक्ट से बंधते हैं।
- क्या वेरिफिकेशन विफलता, की-रोटेशन, रिवोकेशन, ऑफ़लाइन मोड और रोलबैक के स्पष्ट सेमेंटिक्स हैं।
- क्या आप राइट, क्वेरी, कैश, रिटेंशन और ऑडिट लागत का अनुमान लगाते हैं और पॉलिसी वर्ज़न्स को प्रदर्शित करते हैं।
पहले पूछे जाने वाले स्पष्टीकरण
- क्या लक्ष्य डिप्लॉयमेंट की रोकथाम है या ऑडिट साक्ष्य? मान लें कि एडमिशन एक हार्ड गेट है और ऑडिट साक्ष्य अलग से संग्रहीत किया जाता है।
- क्या आर्टिफ़ैक्ट्स केवल कंटेनर हैं? OCI इमेज से शुरुआत करें और बायनेरिज़ व पैकेजों के लिए एक एक्सटेंशन पॉइंट छोड़ें।
- क्या सभी बिल्डर्स ऑनलाइन हैं? मान लें कि प्रतिबंधित या ऑफ़लाइन वातावरणों को प्रीलोड किए गए रूट्स और बंडल्स की आवश्यकता होती है।
- क्या पहचान किसी व्यक्ति, रिपॉजिटरी, वर्कफ़्लो या बिल्डर से जुड़ी है? वर्कफ़्लो पहचान और प्रबंधित बिल्डर्स मान लें, केवल एक ईमेल पता नहीं।
- साक्ष्य को कितने समय तक बनाए रखा जाना चाहिए? स्टोरेज और इंडेक्स का आकार निर्धारित करने से पहले अनुपालन और ऑडिट अवधि के बारे में पूछें।
30-सेकंड का उत्तर
मैं चार सीमाओं को अलग करूंगा: एक बिल्डर प्रोवेनेंस उत्सर्जित करता है जिसमें सोर्स रिवीज़न, डिपेंडेंसीज़, पैरामीटर्स और बिल्डर पहचान शामिल होती है; एक जारीकर्ता क्लेम्स को एक इम्यूटिएबल आर्टिफ़ैक्ट डाइजेस्ट से बांधता है और उन्हें एक ट्रांसपेरेंसी लॉग में रिकॉर्ड करता है; एक सत्यापनकर्ता (verifier) सिग्नेचर चेन, पहचान, डाइजेस्ट, पॉलिसी वर्ज़न और समय विंडो की जांच करता है; एक एडमिशन कंट्रोलर अनुमति (allow), क्वारंटीन (quarantine) या अस्वीकार (deny) लौटाता है। सोर्स, डिपेंडेंसीज़ और रनर्स अनट्रस्टेड इनपुट हैं, इसलिए एक सफल CI रन अपने आप में कोई प्रमाण नहीं है। पॉलिसी वर्ज़न्स और विफलता के कारण ट्रेस करने योग्य हैं, जबकि ऑफ़लाइन वातावरण पिन किए गए रूट्स और सीमित-आयु (bounded-age) वाले बंडलों का उपयोग करते हैं।
चरण-दर-चरण गहन विश्लेषण
चरण 1: ट्रस्ट सीमाओं और खतरों का नक्शा बनाएं
सोर्स कंट्रोल, डिपेंडेंसी रिज़ॉल्यूशन, बिल्ड कॉन्फ़िगरेशन, रनर्स, रजिस्ट्री, जारीकर्ता और डिप्लॉयमेंट कंट्रोलर को सूचीबद्ध करें। हमलावर डिपेंडेंसीज़ बदल सकते हैं, रनर क्रेडेंशियल्स चुरा सकते हैं, टैग बदल सकते हैं, जाली क्लेम्स बना सकते हैं, या पुराने साक्ष्य को फिर से चला (replay) सकते हैं। साबित करने योग्य क्लेम यह है कि किस विश्वसनीय बिल्डर ने किन इनपुट्स से कौन सा डाइजेस्ट तैयार किया; प्रोवेनेंस यह साबित नहीं करता कि कोड भेद्यता-मुक्त (vulnerability-free) है।
चरण 2: प्रोवेनेंस और आर्टिफ़ैक्ट बाइंडिंग को परिभाषित करें
सोर्स रिवीज़न, बिल्डर पहचान, एंट्री पॉइंट, लॉक्ड डिपेंडेंसीज़, पैरामीटर्स, स्टेप डाइजेस्ट, बिल्ड समय और आउटपुट डाइजेस्ट शामिल करें। डाइजेस्ट ऑथराइजेशन कुंजी है; टैग केवल एक डिस्कवरी उपनाम (alias) है। क्लेम्स, सिग्नेचर्स और निर्णयों में स्कीमा वर्ज़न्स रिकॉर्ड करें ताकि फ़ील्ड का अर्थ चुपचाप न बदले।
artifact_digest -> provenance_digest -> signature -> log_entry
policy_version + identity + builder + time_window -> admission_decisionचरण 3: इश्युअंस और ट्रांसपेरेंसी डिज़ाइन करें
बिल्डर एक क्लेम सबमिट करता है। जारीकर्ता वर्कफ़्लो पहचान और क्लेम के आकार को मान्य करता है, फिर हस्ताक्षर करता है या एक सत्यापन योग्य बंडल लौटाता है। हस्ताक्षरित पेलोड में आर्टिफ़ैक्ट डाइजेस्ट और महत्वपूर्ण क्लेम्स शामिल होने चाहिए। एक ट्रांसपेरेंसी लॉग असामान्य इश्युअंस का पता लगाने में मदद करता है लेकिन डिप्लॉयमेंट पॉलिसी की जगह नहीं लेता है। उच्च-मात्रा वाले राइट्स पहले इम्यूटिएबल स्टोरेज में जा सकते हैं, जिसमें डाइजेस्ट, रिपॉजिटरी और पहचान द्वारा एसिंक्रोनस इंडेक्स होते हैं।
चरण 4: डिप्लॉयमेंट वेरिफिकेशन लागू करें
सत्यापनकर्ता एक इम्यूटिएबल डाइजेस्ट को हल करता है, चेन, ट्रस्ट रूट, सर्टिफिकेट पहचान, जारीकर्ता, क्लेम अखंडता और लॉग साक्ष्य की जांच करता है, फिर पॉलिसी लागू करता है। उदाहरण नियम केवल वर्तमान डिपेंडेंसी जांच वाले प्रबंधित रनर्स से मुख्य-शाखा (main-branch) के बिल्ड की अनुमति देते हैं। केवल बूलियन के बजाय पॉलिसी वर्ज़न और कारण कोड के साथ allow, quarantine, या deny लौटाएं।
चरण 5: कीज़, पहचान और रनर के खतरे (compromise) को संभालें
कम समय तक चलने वाली वर्कफ़्लो पहचान या प्रतिबंधित ऑडियंस और इश्युअंस अनुमतियों वाली प्रबंधित कीज़ को प्राथमिकता दें। रोटेशन से प्रत्येक ऐतिहासिक आर्टिफ़ैक्ट अमान्य नहीं होना चाहिए; पुराने रूट्स को उनकी वैधता और रिवोकेशन विंडो के लिए बनाए रखें। यदि कोई रनर कॉम्प्रोमाइज़ हो जाता है, तो उसकी पहचान रद्द करें, प्रभावित वर्कफ़्लोज़ को फ़्रीज़ करें, संबंधित क्लेम्स को चिह्नित करें और नए एडमिशन को ब्लॉक करें। पर्यावरण जोखिम के आधार पर तैनात आर्टिफ़ैक्ट्स को फिर से सत्यापित करें या रोल बैक करें।
चरण 6: रीप्ले, रोलबैक और ऑफ़लाइन वेरिफिकेशन को कवर करें
क्लेम्स में बिल्ड समय, वर्ज़न और पॉलिसी विंडो शामिल हैं; समय समाप्त या डाइजेस्ट-बेमेल साक्ष्य को अस्वीकार करें। रोलबैक अभी भी जांचता है कि पुराना डाइजेस्ट वर्तमान या स्पष्ट रूप से संगत पॉलिसी को पूरा करता है या नहीं। ऑफ़लाइन वातावरण रूट्स, रिवोकेशन स्नैपशॉट और बंडल्स को प्रीलोड करते हैं और स्नैपशॉट की आयु रिकॉर्ड करते हैं; एक समाप्त स्नैपशॉट डिप्लॉयमेंट को अलग (isolate) कर देता है बजाय इसके कि यह दिखावा किया जाए कि वर्तमान वेरिफिकेशन हुआ था।
चरण 7: क्षमता, रिटेंशन और विफलता मोड का आकार निर्धारित करें
आर्टिफ़ैक्ट वॉल्यूम, औसत क्लेम आकार, सिग्नेचर राइट्स, वेरिफिकेशन QPS और डिप्लॉयमेंट बर्स्ट्स का अनुमान लगाएं। क्लेम्स को सस्ते इम्यूटिएबल स्टोरेज में और हाल के डाइजेस्ट्स को हॉट इंडेक्स में रखें। यदि इश्युअंस डाउन है, तो नए आर्टिफ़ैक्ट्स को रोकें या क्वारंटीन करें। यदि वेरिफिकेशन डाउन है, तो प्रोडक्शन फ़ेल-क्लोज़्ड (fail-closed) हो जाता है; कम जोखिम वाले वातावरण एक स्पष्ट अपवाद रिकॉर्ड के साथ एक छोटी, पूर्व-स्वीकृत कैश विंडो का उपयोग कर सकते हैं।
चरण 8: ऑब्ज़र्वेबिलिटी और माइग्रेशन जोड़ें
अनावश्यक सोर्स या सीक्रेट्स को संग्रहीत किए बिना डाइजेस्ट, पॉलिसी वर्ज़न, ट्रस्ट-रूट वर्ज़न, कारण कोड और लेटेंसी रिकॉर्ड करें। प्रोवेनेंस कवरेज, सिग्नेचर विफलता, पहचान विसंगतियों, पॉलिसी अस्वीकृतियों, कैश हिट्स, लॉग विलंब और रद्द किए गए रनर्स की निगरानी करें। चरणबद्ध रोलआउट से पहले पॉलिसी अपग्रेड का शैडो-टेस्ट (shadow-test) करें; प्रत्येक अस्वीकृति दोबारा चलाने योग्य (replayable) और व्याख्या योग्य होनी चाहिए।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं सिस्टम को बिल्ड साक्ष्य, इश्युअंस और ट्रांसपेरेंसी, डिप्लॉयमेंट वेरिफिकेशन और एडमिशन पॉलिसी में विभाजित करूंगा। बिल्डर्स सोर्स रिवीज़न, डिपेंडेंसीज़, पैरामीटर्स, बिल्डर पहचान और आउटपुट डाइजेस्ट को बांधने वाला प्रोवेनेंस उत्पन्न करते हैं। जारीकर्ता वर्कफ़्लो पहचान की पुष्टि करता है, हस्ताक्षर को इम्यूटिएबल डाइजेस्ट से बांधता है, और घटना को रिकॉर्ड करता है। डिप्लॉयमेंट से पहले, सत्यापनकर्ता चेन, सर्टिफिकेट पहचान, जारीकर्ता, क्लेम अखंडता, ट्रस्ट रूट, समय विंडो और पॉलिसी वर्ज़न की जांच करता है, फिर एक व्याख्या योग्य allow, quarantine, या deny लौटाता है। टैग कभी भी अधिकृत नहीं करते हैं। अल्पकालिक पहचान, प्रबंधित रनर्स, की-रोटेशन और रिवोकेशन क्रेडेंशियल जोखिम का समाधान करते हैं; ऑफ़लाइन वातावरण सीमित-आयु वाले रूट्स, रिवोकेशन स्नैपशॉट और बंडलों का उपयोग करते हैं। क्लेम्स डाइजेस्ट इंडेक्स के साथ इम्यूटिएबल स्टोरेज में रहते हैं। विफलताएं पूरी पॉलिसी और निर्णय साक्ष्य के साथ पर्यावरण द्वारा फ़ेल-क्लोज़्ड, क्वारंटीन या एक सीमित कैश का उपयोग करती हैं।
सामान्य गलतियाँ
- केवल एक म्यूटेबल इमेज टैग पर हस्ताक्षर करना।
- पहचान, जारीकर्ता या क्लेम जांच के बिना केवल गणितीय सिग्नेचर वैधता की पुष्टि करना।
- SBOM, प्रोवेनेंस, सिग्नेचर और वल्नेरेबिलिटी स्कैन को एक फ़ील्ड में समेटना।
- प्रत्येक CI रनर पर भरोसा करना और रिवोकेशन ब्लास्ट रेडियस की उपेक्षा करना।
- सभी इतिहास को अमान्य करके कीज़ को रोटेट करना या रद्द की गई पहचानों को हमेशा के लिए स्वीकार करना।
- जब भी सत्यापनकर्ता अनुपलब्ध हो, फ़ेल-ओपन (fail-open) होना।
- पॉलिसी वर्ज़न, कारण कोड या दोबारा चलाने योग्य साक्ष्य के बिना केवल पास/फ़ेल रखना।
फॉलो-अप प्रश्न और उत्तर
आप कैसे साबित कर सकते हैं कि किसी बिल्डर ने अपने क्लेम में झूठ नहीं बोला?
प्रोवेनेंस यह साबित करता है कि एक विश्वसनीय बिल्ड प्रक्रिया ने क्या दावा किया था, न कि यह कि हर कदम ईमानदार था। पृथक (isolated) बिल्डर्स, न्यूनतम विशेषाधिकार (least privilege), प्रतिलिपि प्रस्तुत करने योग्य (reproducible) या तुलनीय बिल्ड, स्वतंत्र लॉग और पॉलिसी बाधाओं के साथ मान्यताओं को कम करें। उच्च जोखिम वाले आर्टिफ़ैक्ट्स के लिए द्वितीय-पक्ष समीक्षा या अतिरिक्त अटेस्टेशन की आवश्यकता हो सकती है।
क्या होगा यदि रजिस्ट्री से समझौता (compromise) हो जाए?
डाइजेस्ट द्वारा डिप्लॉय करें और हस्ताक्षर सत्यापित करें; किसी टैग या रजिस्ट्री मेटाडेटा को बदलने से हस्ताक्षरित डाइजेस्ट नहीं बदलता है। साक्ष्य और बंडलों को एक स्वतंत्र इम्यूटिएबल स्टोर में रखें। नई रिलीज़ को रोकें, लॉग प्रविष्टियों और डाइजेस्ट की तुलना करें, प्रभावित पहचानों को रद्द करें, और किसी घटना के बाद तैनात वातावरण को फिर से सत्यापित करें।
आप कई बिल्डर्स और वेंडर्स का समर्थन कैसे करते हैं?
GitHub Actions, सेल्फ-होस्टेड रनर्स और वेंडर बिल्डर्स के लिए एक क्लेम स्कीमा और एक पहचान-मैपिंग परत का उपयोग करें। एडेप्टर क्लेम्स को सामान्य बनाते हैं; एक सत्यापनकर्ता अभी भी डाइजेस्ट, पहचान, समय और पॉलिसी की जांच करता है। वेंडर्स को अलग बायपास नियम नहीं मिलने चाहिए।
टीमें कहती हैं कि वेरिफिकेशन रिलीज़ को धीमा कर देता है। आप क्या समझौता (trade-off) करेंगे?
पहले वेरिफिकेशन लेटेंसी, कैश हिट्स और विफलता के कारणों को मापें। ट्रस्ट बाउंड्री को कम किए बिना इंडेक्स और समानांतर रीड्स को अनुकूलित करें। कम जोखिम वाले वातावरणों के लिए एक ऑडिट योग्य संक्षिप्त कैश प्रदान करें, प्रोडक्शन में मजबूत सत्यापन बनाए रखें, और वास्तविक दोषों को पॉलिसी की गलतियों से अलग करने के लिए शैडो मोड का उपयोग करें। प्रत्येक अपवाद के लिए एक मालिक, समाप्ति (expiry) और स्वचालित सफ़ाई की आवश्यकता होती है।