اسان جي پوئين پوسٽ ۾ بابت CI/CD Pipelines, اسان ڏٺو ڪيئن هيڪ ڪجي CI/CD اهو منظرنامو جيڪو شايد محفوظ ڪيو ويو.
اچو ته پوئين پوسٽ ۾ اسان جي ڳالهه ياد رکون: اسان ڪجھ سان شروع ڪيو pipeline جيڪو ڪمزور هو اڻ سڌي طرح زهر ڏنو ويو Pipeline Execution (آءِ-پي پي اي) ۽، ان کي درست ڪرڻ لاءِ، اسان ورهائڻ جو فيصلو ڪيو pipeline ٻن ۾:
- 1 pipeline (بلڊ سي آءِ)، ڊي-پي پي اي ۽ آءِ-پي پي اي لاءِ محفوظ، پي آر ڪوڊ چيڪ ڪندو، بلڊ ٺاهيندو، ۽ هڪ آرٽيفيڪٽ پيدا ڪندو.
- 2nd pipeline (ٽيسٽ سي آءِ)، جيڪو ڊي-پي پي اي ۽ آءِ-پي پي اي لاءِ پڻ محفوظ آهي، بنيادي ڪوڊ چيڪ آئوٽ ڪندو (شيل اسڪرپٽ جي ترميم کان بچڻ لاءِ) ۽ اصل اسڪرپٽ کي آرٽيڪلفيڪٽ جي خلاف عمل ۾ آڻيندو.
- ٽيسٽ سي آءِ کي هم وقت سازي ڪرڻ لاءِ pipeline بلڊ سي آءِ کان پوءِ هلائڻ لاءِ pipeline، اسان استعمال ڪيو ورڪ فلو_رن ڇڪڻ.
اسان هن کي منظرنامو #3 جو نالو ڏنو آهي.
جيتوڻيڪ، جيئن اسان ان پوسٽ ۾ ذڪر ڪيو آهي، ٻيا حل به آهن، اسان هن "حل" کي تدريسي سببن جي ڪري لاڳو ڪرڻ جو فيصلو ڪيو، تنهن ڪري اسان انهن ڪمزورين ۾ گهرائي سان غوطه هڻون ٿا CI/CD pipelines.
بعد ۾، اسان ڏٺو ته هن منظرنامي کي ڪيئن هيڪ ڪجي شين کي زهر ڏيڻ. هي اهو آهي جيڪو اسان چئون ٿا مصنوعي زهر ڏيڻ، يعني تبديل ڪرڻ (هيڪ) ڪرڻ جي صلاحيت pipeline منطق کي تبديل ڪندي a pipeline آرٽيفيڪٽ.
هن طريقي سان ڇا مسئلو آهي؟ اسان ڏٺو ته مسئلو تڏهن پيدا ٿئي ٿو جڏهن ڪو به استعمال ڪندڙ هڪ نئون "ٺاهي" ٿو pipeline.
جيڪڏهن ڪو صارف هڪ نئون پي آر کوليندو آهي جنهن ۾ هڪ نئون pipeline، GitHub ان تي عمل ڪندو pipeline (ڪجهه شرطن سان، جيئن اسان ڏٺو پوسٽ ۾).
پوءِ استعمال ڪندڙ هڪ نئون ٺاهي سگهي ٿو pipeline ساڳئي نالي سان Build CI !! ها، اهو حيرت انگيز آهي، پر GitHub توهان کي ٻه ٺاهڻ جي اجازت ڏئي ٿو pipelineساڳئي نالي سان!!
جڏهن صارف انهن تبديلين سان هڪ پي آر کوليندو آهي، "نئون" pipeline (زهر سان ڀريل نموني اپ لوڊ ڪرڻ) کي قتل ڪيو ويندو. ۽ ڊيپلائي سي آءِ pipeline ان کان پوءِ عمل ڪيو ويندو، جنهن جي نتيجي ۾ "ترميم ٿيل" شيل اسڪرپٽ "اصل" شيل اسڪرپٽ کي اوور رائٽ ڪندي جيڪا pipeline ڪم جي جڳهه. تنهن ڪري، هي "حل" I-PPE ڪمزوري کان بچي نٿو سگهي (جيئن اسان هيٺ ڏسي سگهون ٿا)
مسئلا ڪهڙا آهن؟ گهٽ ۾ گهٽ، ڪجهه مسئلا آهن:
- پهريون، ڪيئن پڪ ڪجي ته تعمير جي عمل ۾ ڪا خرابي نه ڪئي وئي آهي؟ هن منظرنامي ۾، بدسلوڪي ڪندڙ استعمال ڪندڙ پنهنجي استعمال ڪندي ارادي جي تعمير جي عمل کي تبديل ڪرڻ جي قابل ٿي ويو آهي pipeline زهر آلود شيءِ ٺاهڻ لاءِ.
- ٻيو، اسان ڪنهن شيءِ جي اصليت جو اندازو ڪيئن لڳائي سگهون ٿا؟
اهي سوال اسان کي انهن جي هٿن ۾ اڇلائي ڇڏيندا آهن سافٽ ويئر تصديق ڊومين!!
سافٽ ويئر تصديق
An تعارف جو هڪ ٽڪرو آهي ڊيٽا نمائندگي ڪرڻ ڪنهن واقعي جو ثبوت. حقيقي دنيا ۾، اسين عام طور تي انهن کي سڏيندا آهيون سرٽيفڪيٽ.
مثال طور، جڏهن ڪا ليبارٽري توهان جي رت جي جانچ ڪري ٿي، ته ٽيسٽ بابت ڊيٽا رڪارڊ ڪيو ويندو آهي ۽ تصديق ڪئي ويندي آهي. رت جي ٽيسٽ جا نتيجا آهن تصديق ڪندڙ ۽ ڳولڻ لائق.
اسان جي آئي ٽي ڊومين جي ويجهو، توهان اندازو لڳائي سگهو ٿا ته هن عمل جو ترجمو ڇا هوندو، مثال طور، هڪ تاليف جي عمل ۾.
ڪمپائليشن سرور ماحول ۽ اوزارن، مواد (سورس ڪوڊ)، ۽ پراڊڪٽس/آرٽيفيڪٽس (بائنري ڪوڊ) بابت معلومات اهڙي تصديق جو حصو هوندي.
ظاهر آهي، اعتبار فراهم ڪرڻ لاءِ تصديق هڪ بااختيار تصديق ڪندڙ (تصديق ٿيل ۽ غير رد ٿيندڙ) پاران تيار ڪئي وڃي.
ممڪن آهي ته، توهان مان ڪجهه سوچي رهيا هوندا .. ۽ ڇا آهي دستخط ۽ تصديق جي وچ ۾ فرق?
ڪوڊ دستخط ۽ تصديقون
هڪ اعليٰ سطح تي، هڪ دستخط هڪ چاٻي جوڙو ۽ هڪ نموني استعمال ڪندي ٺاهيو ويو آهي. چاٻي جوڙو هڪ عوامي چاٻي ۽ هڪ خانگي چاٻي تي مشتمل آهي.
استعمال ڪندڙ پرائيويٽ ڪي استعمال ڪندي هڪ آرٽيڪل تي دستخط ڪري ٿو، ۽ ٻيا پوءِ پبلڪ ڪي استعمال ڪندي دستخط جي تصديق ڪري سگهن ٿا. پرائيويٽ ڪي کي راز ۾ رکڻ گهرجي، پر پبلڪ ڪي وڏي پيماني تي ورهايل آهي.
دستخط استعمال ڪري سگھجن ٿا اهو ثابت ڪرڻ لاءِ ته خانگي چاٻي جي هولڊر آرٽيفيڪٽ تي دستخط ڪرڻ لاءِ خانگي چاٻي استعمال ڪئي هئي.
صحيحات ثابت نه ڪريو
- استعمال ڪندڙ جو نيت نموني تي دستخط ڪرڻ لاءِ (شايد انهن کي ٺڳيو ويو هجي)، يا
- استعمال ڪندڙ جو ڪو به ڪرڻ جو ارادو هن نموني بابت مخصوص دعويٰ
سان اشتهارن، ڪنهن نموني تي سڌو سنئون دستخط ڪرڻ بدران، استعمال ڪندڙ ڪنهن قسم جو ٺاهيندا آهن دستاويز ته انهن جي ارادي کي پڪڙي ٿو آرٽيڪل تي دستخط ڪرڻ جي پويان ۽ ڪنهن به مخصوص دعوائون هن دستخط جي حصي طور ٺاهيو پيو وڃي.
مڪمل طور تي تصديق جو فريم ورڪ
سڀ کان وڌيڪ عام فريم ورڪ آهي مڪمل طور تي تصديق جو فريم ورڪ
- وضاحت ڪري ٿو a standard تصديق لاءِ فارميٽ جيڪي مضمونن کي، بيان ڪيل نمونن کي، نموني بابت تصديق ٿيل ميٽا ڊيٽا سان ڳنڍين ٿا
- جو هڪ سيٽ مهيا ڪري ٿو اڳ ۾ بيان ڪيل اڳڪٿيون سافٽ ويئر سپلائي چينز ۾ ۽ ان ۾ تصديق ٿيل ميٽا ڊيٽا جي رابطي لاءِ
اچو ته تصديق جي فارميٽ بابت ڪجهه تفصيل ۾ وڃون.
An تصديق ڪريو هڪ آهي ڊجيٽل طور تي دستخط ٿيل دستاويز اھو مشتمل آھي بيان.
هن بيان تصديق جي وچين پرت آهي، ان کي هڪ خاص سان پابند ڪري ٿي موضوع ۽ غير واضح طور تي قسمن جي سڃاڻپ ڪرڻ گستاخ:
- موضوع: a آرٽيڪل جو ڪرپٽوگرافڪ طور تي محفوظ حوالو (عام طور تي هيش ذريعي)، ۽
- اڳڪٿي ڪري ٿو: مخصوص جو هڪ سيٽ دعوى ان نموني بابت بيان جي طور تي حوالو ڏنو ويو آهي. اهي دعوائون ڪنهن به شيءِ کي ظاهر ڪرڻ (۽ بعد ۾ ثابت ڪرڻ) لاءِ استعمال ڪري سگهجن ٿيون جيڪو توهان سوچي سگهو ٿا! اهي دستي منظوري، نموني جي اصليت، خودڪار ٽيسٽ جا نتيجا، هڪ آڊٽ ٽريل، يا وڌيڪ نمائندگي ڪري سگهن ٿا!
جڏهن هي بيان ڪرپٽوگرافڪ طور تي دستخط ٿيل آهي، ته پوءِ ان کي هڪ طور حوالو ڏنو ويندو آهي تصديق ڪريو
هن طريقي سان، مثال طور، ايلس هڪ نموني بابت هڪ بيان ٺاهي ٿي ۽ پنهنجي خانگي ڪي استعمال ڪندي ان تي دستخط ڪري ٿي، هڪ تصديق ٺاهي ٿي.
- باب پوءِ ڪري سگهي ٿو دستخط جي تصديق ڪريو انهي تصديق ۾، کيس اجازت ڏيندي دعويٰ تي اعتبار ڪرڻ اندر.
پوءِ باب انهن دعوائن کي استعمال ڪري سگهي ٿو فيصلو ڪرڻ هن نموني کي استعمال ڪرڻ جي اجازت ڏني وڃي يا نه.
ڇا تصديقون آرٽيڪل پوائزننگ کي حل ڪرڻ ۾ مدد ڪري سگھن ٿيون؟
تصديق جي هن تعارف کان پوءِ، اچو ته پنهنجي مسئلي ڏانهن واپس هلون. ڪيئن تصديقون اسان جي مسئلي کي حل ڪرڻ ۾ مدد ڪري سگهن ٿيون، يعني مصنوعي زهر کان بچڻ لاءِ؟
بدسلوڪي ڪندڙ استعمال ڪندڙ "سرڪاري" ميڪانيزم کي نظرانداز ڪندي هڪ آرٽيڪل ٺاهڻ جي قابل هو، يعني پنهنجي استعمال ڪندي pipeline آرٽيڪل ٺاهڻ لاءِ.
اهو حيرت انگيز هوندو جيڪڏهن اسان اهو ثابت ڪري سگهون ته ڊائون لوڊ ڪيل شيون سرڪاري سان ٺهيل آهن pipelines. هي صرف هڪ مثال آهي جنهن کي اسين "ٽيمپرنگ پوائنٽس" سڏي سگهون ٿا، پر ٻيا به ڪيترائي مثال ٿي سگهن ٿا.
جيئن توهان مٿي ڏنل تصوير ۾ ڏسي سگهو ٿا، ڇڪتاڻ جا ڪيترائي نقطا آهن. هن طريقي سان، صارف pipeline (اسان جي مثال ۾ ٽيسٽ CI) کي جائزو وٺڻ گهرجي تعمير جي عمل جي سالميت انهي سان گڏو گڏ پاڻ آرٽيڪل جي سالميت.
اسان جي مثال ۾، زهر ٿيل شيءِ هڪ نئين (زهر ٿيل) متعارف ڪرائڻ سان ٺاهي وئي آهي. pipeline جيڪو تعمير جي عمل سان مداخلت ڪري ٿو. پر خراب استعمال ڪندڙ اهو ڪري سگهي ٿو:
- چيڪ آئوٽ ٿيڻ کان پوءِ ڪوڊ کي تبديل ڪريو SCM هڪ خراب بائنري پيدا ڪرڻ لاءِ
- ڪمپليشن پاران تيار ڪيل صحيح بائنري کي ڪنهن ٻئي خراب بائنري سان تبديل ڪريو.
- آرٽيفيڪٽ رجسٽري سان سمجهوتو ڪريو ۽ ڪنهن ٻئي طريقي سان ٺهيل زهر ٿيل آرٽيفيڪٽ اپ لوڊ ڪريو
- وغيره.
جيئن توهان ڏسي سگهو ٿا، اتي ڪيترائي "ڇڪتاڻ" نقطا ٿي سگهن ٿا.
هتي ڇا اهم آهي؟ ظاهر آهي ته انهن سڀني "ڇڪتاڻ" وارين نقطن کي بچائڻ لاءِ. پر، آخر ۾، جيڪو سڀ کان اهم آهي اهو آهي ته نموني جو "صارف" نموني جي سالميت جو جائزو وٺي سگهي ٿو، ۽ فيصلو ڪري سگهي ٿو ته ان سان اڳتي وڌڻ گهرجي يا نه.
اسان ڪري سگهون ٿا هڪ آرٽيڪل جي سالميت جو جائزو وٺو ٻن طريقن سان.
هڪ اهو آهي ته جائزو وٺڻ سان اصل نموني جو.
پيدا ڪندي هڪ اصليت جي تصديق، اسان آرٽيڪل بابت مفيد ميٽا ڊيٽا (صحيح طور تي تصديق ٿيل ۽ غير رد ٿيل) مهيا ڪندا آهيون. هيٺ ڏنل مثالن ۾، اسين استعمال ڪنداسين زائيگيني سالٽ (ٽرسٽ لاءِ سافٽ ويئر تصديق پرت)، سافٽ ويئر تصديق پيدا ڪرڻ، رجسٽر ڪرڻ ۽ تصديق ڪرڻ لاءِ جزو.
مٿي ڏنل ڪوڊ ۾، توهان ڏسي سگهو ٿا ته هڪ قدم آهي جيڪو جنگ فائل ٺاهي ٿو ۽ ٻيو قدم جيڪو پيدا ڪري ٿو اصليت جي تصديق. اهو ڪرڻ لاءِ، pipeline پرائيويٽ ڪي استعمال ڪري ٿو ۽ تصديق ۾ عوامي ڪي پڻ شامل ڪري ٿو.
پردي پويان، زائيگيني جو لوڻ حڪم تصديق کي هڪ ۾ محفوظ ڪري ٿو لوح محفوظ (اڪا هڪ تصديق رجسٽري، ريڪور اسان جي صورت ۾ پر توهان ڪو ٻيو استعمال ڪري سگهو ٿا). اهو ڪيو، صارف pipeline زائيگيني شامل ٿي سگھي ٿو تصديق انجڻ نموني جي اصليت جي تصديق ڪرڻ ۽ نموني جي سالميت جو جائزو وٺڻ لاءِ.
تصديق جي عمل جو جائزو وٺندو آهي:
- هن آرٽيڪل sha256sum صحيح آهي (يعني ان "موضوع" بابت هڪ تصديق آهي)، ۽
- هن تصديق صحيح طور تي تصديق ٿيل آهي (اهو مناسب خانگي ڪي استعمال ڪندي پيدا ڪيو ويو آهي)
هي تصديق جي عمل پوءِ اندازو لڳائي سگهي ٿو ته نموني ۽ تصديق ٻئي صحيح آهن.
پر، جيئن توهان کي ياد آهي، اسان جي صورت ۾، اهو نمونو هڪ "بدڪار" پاران پيدا ڪيو ويو هو. pipeline (يعني اصل نه ڪنهن تبديل ٿيل طرفان pipeline). پوءِ اسان کي اڳتي وڌڻ گهرجي ۽ هڪ ٻيو پهلو جانچڻ گهرجي: اهو اهو نمونو "اصل" پاران پيدا ڪيو ويو آهي pipeline، ٻيو ڪو به نه.
اهو ڪرڻ لاءِ، صرف ان حالت جي جانچ ڪرڻ لاءِ هڪ سادي لائن شامل ڪريو، مثال طور:
هي اضافي چيڪ ناڪام ٿيندو جيڪڏهن آرٽيڪل اسان جي "محفوظ" پاران پيدا نه ڪيو ويو هجي ها. pipeline.
جيڪڏهن اهو نمونو اسان جي اصل طرفان پيدا ڪيو ويو هو pipeline (cicd_top10_3_salt/.github/workflows/build.yml)، grep ڪمانڊ ڪامياب ٿيندو، ٻي صورت ۾، اهو ناڪام ٿيندو، ٽوڙيندو pipeline ۽ ڪنهن به وڌيڪ قدم کي رد ڪرڻ.
"ٺاهڻ وارو" pipeline اهو صرف هڪ ٽمپرنگ پوائنٽ آهي جنهن کي چيڪ ڪرڻ گهرجي پر، جيئن اڳ ذڪر ڪيو ويو آهي، ڪجهه ٻيا ٽمپرنگ پوائنٽ آهن جن کي اسان کي چيڪ ڪرڻ گهرجي.
مثال طور، جيڪڏهن ريپو چيڪ آئوٽ کان پوءِ ۽ بلڊ ڪمانڊ کان اڳ سورس ڪوڊ سان خرابي ڪئي وئي هجي ته ڇا ٿيندو؟ هن صورت ۾، جيڪو ڪوڊ ٺاهيو ويندو اهو ساڳيو ناهي جيڪو ۾ ذخيرو ٿيل آهي SCM.
هن ڇڪتاڻ واري نقطي کي جانچڻ ايترو آسان آهي جو هر قدم تي مواد جي هيش کي چيڪ ڪرڻ.
conclusions
خلاصو، هڪ سافٽ ويئر جي تصديق سافٽ ويئر جي هڪ ٽڪري بابت ڪيل هڪ دعويٰ آهي، يعني هڪ تصديق ٿيل بيان (ميٽا ڊيٽا) جيڪو سافٽ ويئر آرٽيفيڪٽ يا سافٽ ويئر آرٽيفيڪٽ جي مجموعي بابت آهي.
سافٽ ويئر تصديق خام آرٽيڪل/ڪوڊ سائننگ جو هڪ عام ڪرڻ آهي. تصديق هڪ دستخط ٿيل دستاويز آهي (هڪ ڏنل فارميٽ ۾، عام طور تي JSON تي ٻڌل) جيڪو ميٽا ڊيٽا کي هڪ آرٽيڪل سان ڳنڍيندو آهي. اهي هر تعمير جي مرحلي تي ان پٽ (مواد) ۽ آئوٽ پُٽ (پيدا ڪيل آرٽيڪل) کي ڳنڍڻ واري ثبوت جي نمائندگي ڪن ٿا.
تصديقون آخري سافٽ ويئر آرٽيفيڪٽس جي تعمير لاءِ ڪيل قدمن جو هڪ تصديق ٿيل رڪارڊ فراهم ڪن ٿيون، جنهن ۾ هر قدم لاءِ ان پٽ مواد ۽ بلڊ ڪمانڊ هلايا وڃن ٿا.
نتيجي ۾، سافٽ ويئر تصديق اسان جي تعمير جي عمل جي ڪيترن ئي مختلف سالميت جي پهلوئن کي جانچڻ لاءِ هڪ بهترين طريقو آهي.
سيريز ختم ٿي وئي؟ پريشان نه ٿيو! واپس وڃڻ لاءِ آزاد محسوس ڪريو 'زهر ٿيل Pipeline عملدرآمد (پي پي اي)' يا ڪا ٻي پوسٽ جيڪا توهان جي دلچسپي کي ٻيهر وڌائي!
ڏسندا رهو، اسين سافٽ ويئر جي تصديق ۾ گهرائي سان جاچ ڪنداسين ۽ build security وڌيڪ بلاگ پوسٽن ۾.
