DevSecOps सुरक्षा से जुड़े फैसलों और सबूतों को सॉफ्टवेयर डिलीवरी के आखिरी रिव्यू के तौर पर देखने के बजाय, उन्हें डिलीवरी प्रोसेस में ही शामिल करता है। मल्टी-क्लाउड कंटीन्यूअस इंटीग्रेशन और कंटीन्यूअस डिलीवरी (CI/CD) पाइपलाइन में, मुख्य सवाल यह नहीं है कि एप्लीकेशन किस क्लाउड पर चल रही है। बल्कि सवाल यह है कि कौन सा कंपोनेंट सोर्स बदल सकता है, बिल्ड कोड चला सकता है, आर्टिफैक्ट पब्लिश कर सकता है, या प्रोवाइडर की डिप्लॉयमेंट API को कॉल कर सकता है। यही क्षमताएँ सुरक्षा की सीमा तय करती हैं।
इस कोर्स के लिए, प्रोवाइडर के तौर पर AWS, Microsoft Azure और Google Cloud का इस्तेमाल किया गया है। हर प्रोवाइडर के अपने रिसोर्स और आइडेंटिटी की सीमाएँ होती हैं, जबकि एक सेंट्रल CI कंट्रोल प्लेन पाइपलाइन की परिभाषाओं, जॉब शेड्यूलिंग, मंज़ूरी और रिकॉर्ड किए गए नतीजों को मैनेज करता है। यह लेसन एक सीमित वर्कलोड तय करता है ताकि बाद में ठोस आइडेंटिटी, आर्टिफैक्ट और डिप्लॉयमेंट टारगेट के आधार पर कंट्रोल का मूल्यांकन किया जा सके।
मल्टी-क्लाउड पाइपलाइन का सुरक्षा रिव्यू तब तक शुरू नहीं हो सकता जब तक यह साफ़ न हो कि कौन से हिस्से दायरे (स्कोप) में हैं, क्योंकि उस दायरे से बाहर का कोई रनर या रजिस्ट्री बिना रिव्यू के रिलीज़ में बदलाव कर सकता है। पाइपलाइन की सीमा उन रिपॉजिटरी, कंट्रोल-प्लेन सर्विस, रनर, आइडेंटिटी, आर्टिफैक्ट स्टोर और डिप्लॉयमेंट इंटरफेस का समूह है जो किसी बदलाव को रिलीज़ में बदलने में शामिल होते हैं। इसकी शुरुआत तब होती है जब रिपॉजिटरी में हुआ बदलाव पाइपलाइन के व्यवहार पर असर डाल सकता है, और यह उन प्रोवाइडर API एक्शन तक फैली होती है जो वर्कलोड बनाते या बदलते हैं। डिप्लॉय की गई एप्लीकेशन के लिए रनटाइम रिक्वेस्ट इस सीमा से बाहर होती हैं, हालाँकि बाद में सबूतों के ज़रिए रिलीज़ को रनटाइम व्यवहार से जोड़ा जा सकता है।
सेंट्रल कंट्रोल प्लेन, जिसका नाम ci-control है, अपने-आप AWS, Azure या Google Cloud के अंदर नहीं होता है। इसके रनर बिल्ड और डिप्लॉयमेंट जॉब चलाते हैं, और फिर AWS अकाउंट dev, Azure सब्सक्रिप्शन dev और Google Cloud प्रोजेक्ट orders-dev में अलग-अलग ऑथेंटिकेट करते हैं। कोई रनर प्रोवाइडर की सीमा का हिस्सा तभी बनता है जब उसे वहीं पर सेल्फ-होस्ट किया जाता है। इसकी लोकेशन से नेटवर्क एक्सपोज़र और उपलब्ध आइडेंटिटी मैकेनिज़्म बदलते हैं, लेकिन इससे सीमित दायरे वाले प्रोवाइडर ऑथराइज़ेशन की ज़रूरत खत्म नहीं होती।
अब हम यह पता लगा सकते हैं कि कौन से कंपोनेंट हर प्रोवाइडर की सीमा को पार करते हैं।
एक सेंट्रल पाइपलाइन डुप्लीकेशन को तभी कम करती है जब उसके कंट्रोल लगातार लागू किए जाएं। क्रेडेंशियल फैलाव (Credential sprawl) तब होता है जब कई जॉब, रिपॉजिटरी या प्रोवाइडर एनवायरनमेंट में व्यापक एक्सेस वाले अलग-अलग लंबे समय तक चलने वाले क्रेडेंशियल होते हैं। लीक हुआ डिप्लॉयमेंट क्रेडेंशियल उस जॉब से ज़्यादा समय तक चल सकता है जिसे इसकी ज़रूरत थी, और एक शेयर्ड क्रेडेंशियल ऑडिट रिकॉर्ड को एक पाइपलाइन रन को दूसरे से अलग करने में असमर्थ बना देता है। प्रति-रन, कम समय तक चलने वाले क्रेडेंशियल इस्तेमाल करने योग्य समय और प्रभावित डिप्लॉयमेंट लेन, दोनों को सीमित करते हैं।
स्कैन कंट्रोल भी बदल सकते हैं। AWS पाथ में एक विफलता थ्रेशोल्ड और Azure या Google Cloud पाथ में एक अलग थ्रेशोल्ड वाला वल्नरेबिलिटी स्कैन एक सुरक्षा निर्णय का प्रतिनिधित्व नहीं करता है, भले ही हर पाथ एक ही स्कैनर का उपयोग करे। पाइपलाइन को मूल्यांकन किए गए आर्टिफैक्ट, नियम सेट, परिणाम और गेट के नतीजे को रिकॉर्ड करना चाहिए। एक सफल जॉब लॉग यह साबित करता है कि जॉब ने अपने रिकॉर्ड किए गए समय के दौरान सफलता की सूचना दी; अकेले, यह साबित नहीं करता है कि सभी प्रोवाइडर-साइड संसाधन अब इच्छित स्थिति से मेल खाते हैं।
क्रॉस-क्लाउड कॉपीिंग एक और सीमा जोड़ती है। रजिस्ट्री के बीच कॉपी की गई इमेज को बदला जा सकता है, अधूरा कॉपी किया जा सकता है, या किसी परिचित टैग के तहत प्रमोट किया जा सकता है। टैग एक बदलने योग्य संदर्भ की पहचान करते हैं, जबकि डाइजेस्ट विशिष्ट इमेज सामग्री की पहचान करता है। दोबारा इस्तेमाल करने योग्य नियम यह है कि प्रत्येक प्रोवाइडर कार्रवाई को स्वतंत्र रूप से अधिकृत किया जाए और हर हैंडऑफ़ में सटीक आर्टिफैक्ट का प्रमाण साथ रखा जाए।
चल रहा वर्कलोड orders-api है, एक सेवा जो पोर्ट 8080 पर सुनती है। एप्लिकेशन सोर्स orders-api-repo में रहता है, जबकि इंफ्रास्ट्रक्चर घोषणाएं orders-infra-repo में रहती हैं। एक बिल्ड काल्पनिक कंटेनर इमेज orders-api:1.0 बनाता है; इंफ्रास्ट्रक्चर परिवर्तनों का मूल्यांकन Terraform स्टैक orders-infra के रूप में किया जाता है। सोर्स और इंफ्रास्ट्रक्चर रिपॉजिटरी को अलग रखने से बाद के कंट्रोल प्रत्येक परिवर्तन प्रकार के लिए अलग-अलग समीक्षा, निष्पादन और डिप्लॉयमेंट अनुमतियां असाइन कर सकते हैं।
इमेज को aws-ecr/orders-api, azure-acr/ordersapi, और gcp-ar/orders-api में प्रमोट किया जाता है, फिर प्रोवाइडर-विशिष्ट API क्रियाओं द्वारा उनके नामित विकास सीमाओं में डिप्लॉय किया जाता है। प्रमोशन का मतलब है प्रत्येक रजिस्ट्री में एक ही सत्यापित इमेज डाइजेस्ट को कॉपी करना, न कि प्रत्येक क्लाउड के लिए सोर्स से फिर से बनाना। फिर से बनाने से अलग-अलग आर्टिफैक्ट बनेंगे जिनकी सामग्री और प्रमाण orders-api:1.0 टैग साझा करने के बावजूद अलग-अलग हो सकते हैं।
हम उस आर्टिफैक्ट और इंफ्रास्ट्रक्चर पाथ की जांच कर सकते हैं जिन्हें यह वर्कलोड स्पष्ट करता है।