අඛණ්ඩ ඒකාබද්ධතාවය සහ අඛණ්ඩ යෙදවීම (CI/CD) pipelineක්රමවත් මෘදුකාංග සංවර්ධනයට පහසුකම් සැලසීමේදී s වැදගත් කාර්යභාරයක් ඉටු කරයි. එහෙත්, මේවා ලෙස pipelineඅවදානම් වලින් ඔවුන්ව ආරක්ෂා කර ගැනීමේ අත්යවශ්යතාවය වඩ වඩාත් කැපී පෙනේ. මෙම ගැඹුරු විමර්ශනය OWASP Top-10 හි හඳුනාගෙන ඇති කැපී පෙනෙන අවදානමක් ආමන්ත්රණය කිරීම කෙරෙහි අවධානය යොමු කරයි. CI/CD ආරක්ෂක අවදානම්: විෂ සහිත Pipeline ක්රියාත්මක කිරීම (PPE).
විෂ වීම යනු කුමක්ද? Pipeline ක්රියාත්මක කිරීම (PPE)
OWASP ඉහළම-10 ට අනුව CI/CD ආරක්ෂක අවදානම්, "වස Pipeline ක්රියාත්මක (PPE) අවදානම යන්නෙන් අදහස් කරන්නේ ප්රභව පාලන පද්ධති වෙත ප්රවේශය ඇති - සහ ගොඩනැගීමේ පරිසරයට ප්රවේශය නොමැතිව - ප්රහාරකයෙකුගේ හැකියාවයි. ගොඩනැගීමට අනිෂ්ට කේත/විධාන එන්නත් කිරීමෙන් ගොඩනැගීමේ ක්රියාවලිය හැසිරවීමට pipeline වින්යාසය, අත්යවශ්යයෙන්ම 'විෂ' කිරීම pipeline සහ ගොඩනැගීමේ ක්රියාවලියේ කොටසක් ලෙස අනිෂ්ට කේත ක්රියාත්මක කිරීම"
වචන කිහිපයකින්, විෂ සහිතයි Pipeline ක්රියාත්මක කිරීම (PPE) නිපදවන විට ප්රහාරකයාට වෙනස් කළ හැකිය pipeline තර්කනය.
දෙකක් තියෙනවා ප්රභේද:
- සෘජු PPE (ඩී-පීපීඊ): D-PPE අවස්ථාවක, ප්රහාරකයා CI වින්යාස ගොනුව වෙනස් කරයි. repo හි අනාරක්ෂිත දුරස්ථ ශාඛාවකට වෙනස කෙලින්ම තල්ලු කිරීමෙන් හෝ ශාඛාවකින් හෝ දෙබලකින් වෙනස සමඟ PR එකක් ඉදිරිපත් කිරීමෙන් ඔවුන්ට ප්රවේශය ඇති ගබඩාවක. සීඅයි සිට pipeline ක්රියාත්මක කිරීම නවීකරණය කරන ලද CI වින්යාස ගොනුවේ ඇති විධාන මගින් අර්ථ දක්වා ඇත, ප්රහාරකයාගේ ද්වේෂසහගත විධාන අවසානයේ ගොඩනැගීමෙන් පසු ගොඩනැගීමේ නෝඩය තුළ ක්රියාත්මක වේ. pipeline ක්රියාත්මක වේ.
- වක්ර PPE (I-PPE): ඇතැම් අවස්ථාවලදී, D-PPE හි හැකියාව, ප්රවේශය ඇති විරුද්ධවාදියෙකුට ලබා ගත නොහැක. SCM ගබඩාව (උදා: නම් pipeline CI වින්යාස ගොනුව එකම ගබඩාවේ වෙනම ආරක්ෂිත ශාඛාවකින් ඇද ගැනීමට වින්යාස කර ඇත). එවැනි අවස්ථාවක, විෂ වීම වෙනුවට pipeline එයම, ප්රහාරකයෙකු විසින් යොමු කරන ලද ගොනු වලට අනිෂ්ට කේතය එන්නත් කරයි pipeline (උදාහරණයක් ලෙස: ඇතුළත සිට යොමු කරන ලද ස්ක්රිප්ට් pipeline වින්යාස ගොනුව)
අවස්ථා දෙකේදීම, GitHub විසින් වෙනස් කරන ලද දේ ක්රියාත්මක කරනු ඇත pipeline පෙර සමාලෝචනයක් හෝ අනුමැතියක් අවශ්ය නොවේ..
PPE කලින් හඳුනා ගැනීම
මේ ආකාරයේ අවදානමක් අපට හඳුනාගත හැක්කේ කෙසේද?
මේ උදාහරණය බලමු pipeline :
සහ ව්යාජ කවච ස්ක්රිප්ට් එකක අන්තර්ගතය (runtests.sh):
එම pipeline එය ඉතා සරලයි: එහි අරමුණ වන්නේ සමාලෝචකයාට මූලික ඉඟි කිහිපයක් ලබා දීමයි. Pull Request (PR) පිළිගැනීමේ ක්රියාවලිය:
- එය ක්රියාත්මක වන්නේ අදින්න_ඉල්ලීම (එනම් PR එකක් නිර්මාණය වන සෑම අවස්ථාවකම)
- එය PR කේතය (එනම් දායක කේතය) පරීක්ෂා කරයි.
- එය ගොඩනැගීම සිදු කරනු ඇත
- එය දායක කේතය මත පරීක්ෂණ ක්රියාත්මක කරනු ඇත (උදා: shell script එකක් ක්රියාත්මක කිරීමෙන්)
කේතය සම්පාදනය නොකළහොත් හෝ පරීක්ෂණ සමත් වීමට අසමත් වුවහොත් පියවර #3 (ගොඩනැගීම සාදන්න) සහ #4 (ධාවන පරීක්ෂණය) අසාර්ථක වනු ඇත. එබැවින්, මෙම පියවර PR පිළිගැනීමට අවශ්ය, නමුත් ප්රමාණවත් නොවන කොන්දේසියක් ලෙස ක්රියා කරයි. සාර්ථක නම්, repo පරිපාලක දායක කේතය සමාලෝචනය කිරීමට ඉදිරියට යන අතර, ඒ මත පදනම්ව, ඔහු/ඇය PR පිළිගනී/ප්රතික්ෂේප කරයි/අදහස් දක්වයි.
සයිජෙනි ස්කෑනරය
සයිජෙනි CLI එකක් සපයයි (“සයිජෙනි ස්කෑනරය”) එය a තුළට ඇතුළත් කළ හැකිය pipeline නැතහොත් විධාන රේඛාවකින් ධාවනය කරන්න. Xygeni ස්කෑනරය මඟින් pipelineඅවදානම් පරීක්ෂා කිරීමට s භාවිතා කරන අතර, GitHub PAT එකක් සපයා ඇත්නම්, එය org/repo මට්ටමින් අවදානම් සොයා ගැනීමට GitHub වෙත සම්බන්ධ වනු ඇත.
සයිජෙනි ඉන්වෙන්ටරි
අපි මෙම ගබඩාවේ Xygeni ස්කෑනරය ක්රියාත්මක කරන විට, එය ප්රයෝජනවත් වත්කම් සමූහයක් සොයා ගනී (the සයිජෙනි ඉන්වෙන්ටරි). ඉන්වෙන්ටරිය විවිධ වර්ග වලින් පිරී යනු ඇත CI/CD වත්කම්, එවැනි:
- එම SCM පද්ධතිය repo ගබඩා කර ඇති තැන
- එම SCM ප්ලගින ස්ථාපනය කර ඇත/භාවිතා කර ඇත
- එම කේත ගබඩාව ම ය
- එම SCM ආයතනය repo එක අයිති තැනට
- එම CI/CD Pipelineරැකියා සහ රැකියා
- එම CI/CD පද්ධතිය ධාවනය pipelines
- IaC සම්පත් repo වෙත අර්ථ දක්වා ඇත
- බාහිර යැපීම්
- ආදිය ..
අපගේ උදාහරණයේ දී, අපට යම් නිශ්චිත වත්කම් වර්ගයක් අනුව ඉන්වෙන්ටරි පෙරහන් කළ හැකිය (SCM- සහ CICD ආශ්රිත වත්කම්), එබැවින් අපට එය දැකිය හැකිය:
- SCM පද්ධතිය GitHub Cloud වේ
- Repo GitHub Cloud හි ගබඩා කර ඇති අතර එය විශේෂිත GitHub සංවිධානයකට අයත් වේ.
- දෙකක් තියෙනවා pipelineGitHub මගින් බලගන්වන ලද (CI/CD පද්ධතියක්)
- සෑම pipeline එක් නිශ්චිත පියවරක් අඩංගු වේ
ඉහත සඳහන් දේ තෝරා ගැනීමෙන් pipeline අපට සමහර දුර්වලතා දැකිය හැකිය:
- At pipeline මට්ටමින්, එය දෙකටම ගොදුරු විය හැකිය සෘජුය සහ වක්ර PPE.
විෂ වූ අයගේ විස්තර අපට දැක ගත හැකිය Pipeline ක්රියාත්මක කිරීමේ දුර්වලතා
සයිජෙනි එය හඳුනා ගනී D-PPE වලට ගොදුරු විය හැකි මන්ද එය ක්රියාත්මක වන්නේ Pull Request සිදුවීම සහ අමතර ආරක්ෂක පාලනයන් නොමැත, එබැවින් ඕනෑම repo පරිශීලකයෙකුට වෙනස් කළ හැකිය pipeline සහ එම වෙනස් කිරීම් කිසිදු සමාලෝචනයක් හෝ අනුමැතියකින් තොරව ක්රියාත්මක කරනු ලැබේ.
ඒ අර්ථයෙන් ගත් කල, සයිජෙනි ද එය හඳුනා ගනී I-PPE වලට ගොදුරු විය හැකි shell script එකට ඇමතුමක් ලැබුණු නිසා pipeline: ඕනෑම repo පරිශීලකයෙකුට shell script වෙනස් කළ හැකි අතර එම වෙනස් කිරීම් කිසිදු සමාලෝචනයක් හෝ අනුමැතියකින් තොරව ක්රියාත්මක කෙරේ.
ඔබට තවත් දැන ගැනීමට අවශ්යද?
PPE සූරාකෑම
PPE උපයෝගී කර ගැනීම සඳහා, පවතින අවස්ථාවක් සලකා බලමු repo පරිශීලකයින් වර්ග දෙකක්:
- An අභ්යන්තර පරිශීලකයා (එම ගබඩාවේ වැඩ කරන අභ්යන්තර සංවර්ධකයෙක්), ගබඩාවේ ලිවීමේ අවසරයන් සහිතව
- An බාහිර පරිශීලකයා (එම repo එකේ වැඩ කරන නමුත් repo එකේ කියවීමේ අවසර ඇති බාහිරින් ලබාගත් සංවර්ධකයෙක්), එනම් repo එක ශාඛා කිරීමට අවසර නොමැති අතර දෙබලක වැඩ කිරීමට බල කෙරෙයි.
දෙදෙනාම ද්වේෂසහගත ප්රහාරකයින් (නැතහොත් ද්වේෂසහගත නළුවෙකු විසින් අනුකරණය කරන ලද) යැයි සිතමු. repo හි යම් රහසක් අඩංගු වන අතර දෙදෙනාටම අවශ්ය වන්නේ repo රහස සොරකම් කිරීමට සහ එය හැකර්-පාලිත සේවාදායකයකට යවන්න. එය කිරීමට, ඔවුන් විෂ සහිත දේවලින් ප්රයෝජන ගනු ඇත. Pipeline ක්රියාත්මක කිරීමේ දුර්වලතා pipeline.
අවස්ථා දෙකේදීම (බාහිර සහ අභ්යන්තර පරිශීලක), ඔවුන් විවෘත කරන්නේ Pull Request එකම වෙනස් කිරීම් සමඟ:
- එම pipeline සහ shell script වෙනස් කර ඇත. දක්වා රහස කියවන්න පරිසරයෙන් සහ හැකර්-පාලිත සේවාදායකයකට එය යවන්න.
වෙනස්කම් පහත පරිදි විය හැකිය:
පරිශීලකයන් දෙදෙනාම නිර්මාණය කරනු ඇත Pull Request සංශෝධන සමඟ. PR නිර්මාණය කිරීමෙන් පසු, GitHub විසින් වෙනස් කිරීම් දෙකම ක්රියාත්මක කරනු ඇත (පෙර සමාලෝචනයක් හෝ අනුමැතියක් අවශ්ය නොවේ), පහත සඳහන් දේ ඇති කරයි:
ලිවීමේ සහ කියවීමේ පරිශීලකයින් සඳහාද එයම වේ, අවස්ථා දෙකේදීම D-PPE සහ I-PPE ක්රියාත්මක වේ., වෙනස සමඟ කියවන පරිශීලකයාට රහස් වෙත ප්රවේශ විය නොහැක. (!!!!)
මෙයට හේතුව, දෙබලකින් එන PR එකකදී, GitHub repo රහස් වෙත ප්රවේශ වීමට ඉඩ නොදේ. කියවන පරිශීලකයාට රහස් කියවිය නොහැකි වුවද, ඔහුට/ඇයට තවමත් වෙනත් ඕනෑම වැඩසටහනක් ක්රියාත්මක කළ හැකිය. සාමාන්ය ප්රහාරක උදාහරණයක් වන්නේ ක්රිප්ටෝ මයිනර් එකක් බාගත කරන PR නිර්මාණය කිරීමයි, එබැවින් විෂ සහිත pipeline.
මේක ආරක්ෂිත පරිසරයක් නෙවෙයි, ඇත්තෙන්ම!! එය වළක්වා ගැනීමට repo පරිපාලකට කළ හැක්කේ කුමක්ද?
ගූගල් කිරීමෙන් පසු, repo පරිපාලක විසින් වෙනස් කිරීමට තීරණය කරයි pipeline මත ක්රියාත්මක වීමට නියමිත අදින්න_ඉල්ලුම්_ඉලක්කය සිදුවීම. ඇයි? මොකද pipelinepull_request_target මත ක්රියාත්මක වන s ක්රියාත්මක කිරීමට ඉඩ නොදේ. pipeline වෙනස් කිරීම්, එනම් ඕනෑම පරිශීලක වෙනස් කිරීමක් තිබියදීත් “මුල් පිටපත” pipeline ක්රියාත්මක කරනු ලැබේ.
අපගේ උදාහරණය අනුගමනය කරමින්, ප්රහාරය පෙර පරිදිම වනු ඇත. මෙයින් පසු කුමක් සිදුවේද? pipeline වෙනස් කිරීම?
බලාපොරොත්තු වූ පරිදි, D-PPE ක්රියාත්මක නොවේ. නමුත්, I-PPE තවමත් පවතින නිසා, කියවන පරිශීලකයාට දැන් repo රහසට ප්රවේශ විය හැක!!!
කියවන පරිශීලකයාට දැන් රහස් වෙත ප්රවේශය ඇත්තේ කුමන හේතුව නිසාද? pipeline වෙනස් කළ නොහැක, නමුත් shell script වෙනස් කිරීමට තවමත් හැකිය. A pipeline pull_request_target මත ක්රියාරම්භ කර ඇත, එය වරප්රසාදිත ආකාරයෙන් ක්රියාත්මක කෙරේ. so එය shell script එකත් වේවි., එහි ප්රතිඵලයක් ලෙස shell script එකට repo රහස් වෙත ප්රවේශය ලැබේ!!
නිවාරණ පියවර
ද්වේශසහගත PR වලින් ආරක්ෂා වීමට GitHub යම් යම් පියවර සපයයි.
ශාඛා ආරක්ෂණ නීති
GitHub සමඟින් ඔබට තෝරාගත් ශාඛා හරහා ශාඛා ආරක්ෂණ නීති නිර්වචනය කළ හැකිය.
ඔබගේ ආරක්ෂිත ශාඛා සඳහා, ඔබට ප්රතිපත්තියක් නියම කළ හැකිය a අවශ්ය වේ pull request ඒකාබද්ධ වීමට පෙර (මෙන්ම අවශ්ය අනුමැතීන් සංඛ්යාව, කේත හිමිකරුවන්ගෙන් සමාලෝචන ආදිය වැනි අමතර කොන්දේසි)
විශේෂ සලකා බැලීමක් ලැබිය යුතු කොන්දේසි කිහිපයක් නම්:
- "නිශ්චිත නළුවන්ට අවශ්ය මඟ හැරීමට ඉඩ දෙන්න pull requests".
- "ඉහත සැකසුම් මඟ හැරීමට ඉඩ නොදෙන්න."
බොහෝ කොන්දේසි ප්රතිපත්තියට දැඩි බවක් එක් කළද, මේවා ප්රතිපත්තිය ලිහිල් කරන අතර එය ද්වේෂසහගත ක්රියාකාරකම් සඳහා විවෘත දොරක් ඇති කළ හැකිය, උදාහරණයක් ලෙස, “වරප්රසාද ලත්” ක්රියාකාරීන් විසින් අක්තපත්ර සොරකම් කරන විට.
GITHUB_TOKEN අවසර සීමා කරන්න (අඩුම-වරප්රසාද)
GitHub ටෝකන් අවසරයන් අවශ්ය ඒවාට පමණක් සීමා කරන්න; මේ ආකාරයෙන්, ප්රහාරකයින් ඔබේ pipeline, ඔවුන්ට එතරම් දෙයක් කිරීමට නොහැකි වනු ඇත.
භාවිතා කිරීමෙන් නූල් අන්තර් මැදිහත්වීම වළක්වා ගන්න pipeline env විචල්යයන්
ඔබ ඔබේ පරිගණකයේ යම් ආදාන විචල්යයන් භාවිතා කරන සෑම විටම pipeline, ඒවා පෙරනිමියෙන් “විශ්වාස නොකළ” දත්ත ලෙස සැලකිය යුතු බව මතක තබා ගන්න (ඒවායේ අන්තර්ගතය අවසාන පරිශීලකයා විසින් පාලනය කරනු ලැබේ). බලන්න විශ්වාස නොකළ ක්රියා සහ කාර්ය ප්රවාහ ආරක්ෂිතයි සහ ගිතුබ් ක්රියා ඉගෙන ගන්න.
ස්ක්රිප්ට් තුළට ආදාන විචල්යයන් ඇතුළු කිරීමට, ඔබ සැමවිටම string interpolation භාවිතා කිරීම වෙනුවට පරිසර විචල්යයන් භාවිතා කළ යුතුය.
කාර්ය ප්රවාහ ධාවනය සහ අනුමත කිරීමේ අවශ්යතා
සදහා පොදු repos, GitHub මඟින් නියම කිරීමට ඉඩ සලසයි "බාහිර" PR සමඟ වැඩ කරන්නේ කෙසේද?.
GitHub සංවිධාන සැකසුම් (“Org >> සැකසුම් >> ක්රියා >> සාමාන්ය”) මඟින් බාහිර PR කළමනාකරණය කරන්නේ කෙසේදැයි සඳහන් කිරීමට ඉඩ දෙන්න:
පෙරනිමියෙන්, GitHub පළමු වරට දායක වන අයට PR අනුමැතිය අවශ්ය වනු ඇත, එමඟින් ද්වේෂසහගත ඉල්ලීම් ප්රහාර වඩාත් සංකීර්ණ වේ. එසේ වුවද, ප්රහාරකයාට ව්යාපෘති නඩත්තුකරුවන්ගේ විශ්වාසය දිනා ගත හැකිය, උදාහරණයක් ලෙස අහිංසක pull request සැබෑ ප්රහාරයට පෙර.
මෙම අර්ථයෙන්, ද 3 වන විකල්පය (සියලුම බාහිර සහයෝගිතාකරුවන් සඳහා අනුමැතිය අවශ්ය වේ) ඉහළ මට්ටමේ පාලනයක් එක් කරයි.
සදහා පුද්ගලික repos සමඟින්, GitHub සංවිධානය සහ repo මට්ටමින් ප්රයෝජනවත් පාලනයක් ද සපයයි.
"සිට කාර්ය ප්රවාහ ධාවනය කරන්න Pull Requests” (පෙරනිමියෙන් පරීක්ෂා කර නැත) පරිශීලකයින්ට fork PR වලින් වැඩ ප්රවාහ ක්රියාත්මක කිරීමට ඉඩ සලසයි (කියවීමට පමණක් අවසර ඇති සහ රහස් වෙත ප්රවේශයක් නොමැති GITHUB_TOKEN භාවිතා කරමින්). අවසාන විකල්පය සමඟ මෙම විකල්පය තේරීමෙන් (“fork PRs වැඩ ප්රවාහ සඳහා අනුමැතිය අවශ්යයි”), ඔබට පුද්ගලික ගබඩාවලට සමාන ප්රතිපත්තියකට ළඟා විය හැකිය (ඉහත පෙන්වා ඇති පරිදි).
කියවන පරිශීලකයෙකුගෙන් PPE සූරාකෑමේදී අප දැක ඇති පරිදි, දෙබලක සිට වැඩ ප්රවාහ ක්රියාත්මක කිරීමට ඉඩ දීම pull requests අනාරක්ෂිතයි!!
ඉතිරි විකල්ප ("දෙබලක සිට වැඩ ප්රවාහ වෙත ලිවීමේ ටෝකන යවන්න. pull requests" සහ "සඳහා සිට වැඩ ප්රවාහ වෙත රහස් සහ විචල්යයන් යවන්න pull requests") ආරක්ෂක මට්ටම අඩු කරන්න දෙබලක PR වලට යොදන ලදී.
ඔබට මෙම දෙබලක ප්රතිපත්තිය සංවිධාන මට්ටමින් හෝ Repo මට්ටමින් අර්ථ දැක්විය හැක. ප්රතිපත්තිය org මට්ටමින් අක්රිය කර ඇත්නම්, එය repo මට්ටමින් සක්රීය කළ නොහැක. නමුත්, ප්රතිපත්තිය org මට්ටමින් සක්රීය කර ඇත්නම්, එය repo මට්ටමින් අක්රිය කළ හැක.
පානදුර හිරණ
අපි බලාපොරොත්තු වෙනවා ඔබ යම් යම් දේවල් තිබීමේ ඇඟවුම් දැක ඇති කියලා. pipeline විෂ වීමට ගොදුරු විය හැකි Pipeline ක්රියාත්මක කිරීම. එය ඉතා පහසුයි commit අවදානමට ලක්විය හැකි pipeline, ඒ වගේම ආරක්ෂිත එකක් ලිවීම අපහසුයි.
එබැවින් එවැනි අවදානම් පිළිබඳව දැනුවත් වීමට Xygeni ස්කෑනරය භාවිතා කිරීම ඉතා වටිනවා.
ඔබ එහි පැවැත්ම ගැන දැනුවත් නම් මිස, ඔබට වල්න් එකක් විසඳිය නොහැක!!
නමුත්... තවමත් ඉතිරිව ඇති ප්රශ්නයක් තිබේ... I-PPE වළක්වා ගන්නේ කෙසේද?
මෙය අපගේ ඊළඟ සටහනේ මාතෘකාව වනු ඇත 🙂 … වක්රව විෂ වීම Pipeline ක්රියාත්මක කිරීම (I-PPE) !!
