Yn ein postiad blaenorol, gwelsom sut i ganfod ac amddiffyn rhag Gwenwyno Uniongyrchol Pipeline Gweithredu (D-PPE). Gwelsom hefyd sut i ganfod y bregusrwydd hwnnw gan ddefnyddio Sganiwr Xygeni, yn ogystal â rhai mecanweithiau amddiffyn.
Gwenwynig Pipeline Gweithredu (PPE) yn cael ei gynhyrchu pan all yr ymosodwr addasu'r pipeline rhesymeg mewn un o ddwy ffordd:
- Drwy addasu'r ffeil ffurfweddu CI (y pipeline) -> PPE Uniongyrchol (D-PPE)
- Drwy addasu ffeiliau y cyfeirir atynt gan y pipeline (er enghraifft: sgriptiau y cyfeirir atynt o fewn y pipeline ffeil ffurfweddu) -> PPE Anuniongyrchol (I-PPE)
Yn y swydd hon, byddwn yn ymchwilio'n fanwl i PPE Anuniongyrchol. Ond, cyn hynny, ac i ategu fy swydd flaenorol, gadewch i ni weld yn gyntaf sut mae GitHub yn rheoli gweithrediad pipelinea beth yw'r mecanweithiau amddiffyn yn erbyn D-PPE.
Sut mae GitHub yn amddiffyn gweithrediad pipelines yn dod gan PRs?
Sut mae GitHub yn gweithio o ran gweithredu addasiadau pipelines?
Addaswyd pipelinegall s ddod o Gwthiadau neu Pull Requests (PR). Fel arfer gorau pwysig, argymhellir yn gryf osgoi unrhyw "wthio" uniongyrchol i gangen warchodedig a defnyddio Pull Requests fel mecanwaith i orfodi rhywfaint o adolygiad cyn derbyn unrhyw god a gyfrannwyd.
Pull Requests gall ddod o ddwy ffynhonnell wahanol:
- PRs yn dod o forciau
- PRs yn dod o canghennau
PRs o forciau gall ddod naill ai o cyhoeddus or preifat ystorfeydd.
Gan ein bod yn delio â PPE (Gwenwyno Pipeline (Gweithredu), nid “derbyn” PR yw ein prif bwynt ond gweithredu addasedig pipeline yn ystod proses dderbyn/cymeradwyo'r PR. Wrth wraidd ymosodiad PPE, mae gweithrediad anfwriadol o addasiad "maleisus" pipeline.
Mewn ychydig eiriau, Gwenwynig Pipeline Cynhyrchir gweithredu (PPE) pan gall yr ymosodwr addasu'r pipeline rhesymeg.
Mae dau amrywiadau:
- PPE uniongyrchol (D-PPE): Mewn senario D-PPE, mae'r ymosodwr yn addasu'r ffeil ffurfweddu CI mewn storfa y mae ganddyn nhw fynediad iddi, naill ai drwy wthio'r newid yn uniongyrchol i gangen bell heb ei diogelu ar y repo, neu drwy gyflwyno PR gyda'r newid o gangen neu fforc. Ers y CI pipeline diffinnir y gweithrediad gan y gorchmynion yn y ffeil ffurfweddu CI wedi'i haddasu, mae gorchmynion maleisus yr ymosodwr yn rhedeg yn y nod adeiladu yn y pen draw unwaith y bydd yr adeiladwaith wedi'i wneud pipeline yn cael ei sbarduno.
- PPE anuniongyrchol (I-PPE): Mewn rhai achosion, nid yw'r posibilrwydd o D-PPE ar gael i wrthwynebydd sydd â mynediad at SCM ystorfa (e.e. os yw'r pipeline wedi'i ffurfweddu i dynnu'r ffeil ffurfweddu CI o gangen ar wahân, wedi'i diogelu yn yr un storfa). Mewn senario o'r fath, yn hytrach na gwenwyno'r pipeline ei hun, mae ymosodwr yn chwistrellu cod maleisus i ffeiliau y cyfeirir atynt gan y pipeline (er enghraifft: sgriptiau y cyfeirir atynt o fewn y pipeline ffeil ffurfweddu)
Yn y ddau achos, Bydd GitHub yn gweithredu'r hyn a addaswyd pipeline heb fod angen adolygiad na chymeradwyaeth flaenorol.
PRs o fforc ymlaen cyhoeddus repos
Mae GitHub yn caniatáu ffurfweddu'r ymddygiad wrth brosesu PRs yn dod o fforciau mewn repos cyhoeddus.
Pan fydd PR yn dod o fforc, mae GitHub bob amser yn gorfodi rhywfaint o "gymeradwyaeth" cyn gweithredu'r pipeline sy'n gysylltiedig â'r PRMae'r lefel hon o gymeradwyaeth yn amrywio o gymeradwyaeth wan i gymeradwyaeth lem.
At Lefel sefydliad (Sefydliad>>Gosodiadau>>Gweithredoedd>>Cyffredinol), gallwch ddewis rhwng sawl opsiwn "cymeradwyo":
Y mwyaf llym yw'r un olaf (“Angen cymeradwyaeth gan bob cydweithiwr allanol”) oherwydd bydd GitHub bob amser angen cymeradwyaeth pan fydd y PR yn dod o fforciau gan gydweithwyr allanol.
Ond hyd yn oed yn yr achos llym hwn, mae yna gwahaniaethau rhwng cydweithwyr sydd â chaniatâd darllen ac ysgrifennu.
- Pan ddaw'r cysylltiadau cyhoeddus o darllen defnyddiwr, y dienyddiad y pipeline wedi'i STOPIO nes bod cymeradwyaeth i'r newidiadau. Os yw'r gymeradwyaeth yn iawn, yna'r newidiadau wedi'u haddasu pipeline yn cael ei weithredu.
- Pan ddaw'r cysylltiadau cyhoeddus o ysgrifennu defnyddiwr, y nid oes angen cymeradwyaeth a'r addasiad pipeline yn cael ei weithredu bob amser!!
I gloi, mae PRs sy'n dod o fforciau ar ystorfeydd cyhoeddus wedi'u diogelu'n ysgafn rhag PPE. Mae rhywfaint o ddiogelwch yn erbyn defnyddwyr allanol (darllen), ond dim byd sy'n gysylltiedig â defnyddwyr mewnol (ysgrifennu).
Beth am PRs yn dod o fforciau o repos preifat?
PRs o fforc ymlaen preifat repos
Yn y senario hwn, mae GitHub yn darparu rhai gosodiadau ffurfweddu defnyddiol.
Gellir ffurfweddu'r gosodiadau uchod naill ai yn organ neu yn Storfa lefel.
Pryd nid oes unrhyw opsiwn wedi'i wirio, Bydd GitHub gofyn am gymeradwyaeth ac ni fydd yn gweithredu'r hyn a addaswyd pipelineDyma'r cyfluniad mwyaf diogel!!
The ffurfweddiad mwyaf diogel yw pryd "Rhedeg llifau gwaith o fforc pull request" wedi'i wirioYn yr achos hwn, yr un peth ar gyfer defnyddwyr darllen ac ysgrifennu, bydd Github yn gweithredu'r addasiad yn awtomatig. pipeline!! A gall y sefyllfa hon fod hyd yn oed yn fwy waeth os “Anfon tocynnau ysgrifennu i lifau gwaith o fforc pull requests"A"Anfon cyfrinachau a newidynnau i lifau gwaith o fforc pull requests" wedi'u gwirio. Peidiwch â gwneud hyn oni bai bod cyfiawnhad clir dros hynny!!
Os “Angen cymeradwyaeth ar gyfer fforch pull request Llif gwaith" wedi'i wirio, mae'r sefyllfa uchod wedi'i gwella rhywfaint: bydd GitHub yn gofyn am gymeradwyaeth ac ni fydd yn gweithredu'r addasiad. pipeline ar gyfer y defnyddiwr darllen, ond bydd yn dal i'w weithredu ar gyfer defnyddiwr ysgrifennu.
Fforciau wedi'u gweld, beth amdano PRs yn dod o ganghennau?
PRs o canghennau
Er mwyn amddiffyn y senario hwn rhaid i chi ddibynnu ar Rheolau Diogelu Cangen.
Ar lefel y storfa, gallwch greu rheolau amddiffyn cangen ar gyfer unrhyw gangen. Mae'r rheolau hyn yn ychwanegu rhai cyfyngiadau ar addasu canghennau gwarchodedig.
Er eich bod chi'n ffurfweddu rheol i “Angen a pull request cyn uno"A"Angen cymeradwyaethau", yr addasedig pipeline yn cael ei weithredu'n awtomatig ar ôl creu PRDim ond i'r weithred uno y bydd y "gymeradwyaeth" yn berthnasol.
Beth am Wenwyno Anuniongyrchol Pipeline Gweithredu
Fel y gwelsom uchod, gellir lliniaru D-PPE trwy ddefnyddio targed_cais_tynnu, ond mae'n nid yw'n berthnasol i I-PPE.
Os ydych chi'n defnyddio pull_request_target, y cod sylfaenol fydd y gwiriad diofyn. Ond os ydych chi eisiau dilysu rhai gwiriadau ar y cod a gyfrannwyd (cod PR) mae angen i chi wirio'r cod PR yn benodol. Felly, os yw'r cod PR wedi addasu unrhyw sgript cragen a alwwyd gan y pipeline, y “sylfaen” (diogel) pipeline bydd yn galw'r sgript cragen “wedi'i haddasu” → PPE Anuniongyrchol!!
Mae'r ateb i hyn ychydig yn fwy cymhleth (nid oes ateb hud fel pull_request_target).
Mae ein pipeline mae bellach yn ddiogel i D-PPE oherwydd ein bod yn defnyddio pull_request_target. Ond mae'n dal yn agored i niwed i I-PPE.
Yn ein enghraifft brawf, mae angen i ni wirio'r cod PR yn y bôn i wneud yr adeiladwaith, ond mae'r profion yn cael eu gweithredu ar yr arteffact a gynhyrchir gan yr adeiladwaith.
Felly .. pam na wnewch chi edrych ar y ddau gronfa god?
- Cod PR gwirio oherwydd mai'r cod a gyfrannwyd yw'r hyn yr ydym am ei adeiladu a'i brofi
- Cod Sylfaenol Checkout i redeg y fersiwn wreiddiol o'r pipeline a'r sgriptiau adeiladu/profi
Efallai y bydd hyn yn cael ei wneud gan gwirio'r cronfeydd cod hynny i wahanol ffolderi: gellid gwirio'r cod sylfaenol i'r ffolder gwraidd, a'r PR i ffolder wahanol. Yn yr achos hwn, byddem yn gweithredu'r adeiladwaith a'r sgript prawf o'r ffolder gwraidd yn erbyn y cod a osodwyd yn y ffolder newydd.
Mae hwn yn ateb hawdd, wrth gwrs!! Ond, at ddibenion dysgu, hoffwn gyflwyno amrywiad eithaf diddorol (…)
GitHub rhedeg_llif_gwaith digwyddiad sbarduno
Ar wahân i targed_cais_tynnu, mae GitHub yn darparu digwyddiad sbarduno arall: rhedeg_llif_gwaithMae'r digwyddiad hwn yn caniatáu gweithredu pipeline wedi'i gyflyru i un arall pipelinedienyddiad.
rhedeg_llif_gwaith ac targed_cais_tynnu mae sbardunau'n debyg mewn un agwedd: bydd y ddau yn cael eu gweithredu mewn modd breintiedig a, er gwaethaf y newidiadau PR, y sylfaen pipeline bydd yn cael ei ddienyddio!!
Gadewch i ni weld ein presennol pipeline:
Mae'r adran adeiladu yn ddiogel i D-PPE, ond mae'r adran brawf yn dal i fod yn agored i niwed i I-PPE.
The pipeline ei hun yn ddiogel i D-PPE oherwydd y targed_cais_tynnu sbardun. Ond mae'r cam prawf yn dal yn agored i I-PPE oherwydd galw ar sgript cragen allanol.
Osgoi I-PPE
Pwrpas yr uchod pipeline yw adeiladu a phrofi'r cod a gyfrannwyd, gan fod yn ddiogel i PPE.
Felly .. Pam na ddylid rhannu'r pipeline yn ddau? Un ar gyfer adeiladu ac un arall ar gyfer profi..
- Y 1af pipeline (Adeiladu CI) fyddai gwiriwch y cod PR (i'w adeiladu), gwneud yr adeiladwaith a chynhyrchu arteffact.
- Yr 2il pipeline (Prawf CI) fyddai edrychwch ar y cod Sylfaenol (i osgoi addasu sgriptiau cragen) a gweithredu'r sgriptiau gwreiddiol yn erbyn yr arteffact.
- I gydamseru'r Prawf CI pipeline i redeg AR ÔL y CI Adeiladu pipeline, byddwn yn defnyddio'r rhedeg_llif_gwaith sbardun.
Fel hyn:
- pipeline Adeiladu CI is ddiogel i'r ddau D-PPE (oherwydd targed_cais_tynnu) A I-PPE (oherwydd nad yw'n gweithredu'r sgript cragen mwyach).
- pipeline Prawf CI Mae hefyd yn ddiogel i'r ddau D-PPE (oherwydd rhedeg_llif_gwaith) A I-PPE (oherwydd ei fod yn gwirio'r cod sylfaenol i gael y sgript cragen wreiddiol)
Gadewch i ni weld cod y ddau pipelineyn ôl yr addasiadau hyn …
1st pipeline (Adeiladu CI):
2il pipeline (Prawf CI):
Wow… ateb braf!! Ond ….. Ydyn ni'n ddiogel? Mae arna i ofn nad ydyn ni 😭
Yn wir, rydym wedi cyflwyno gwendid newydd!! Pa un? Dyma fydd pwnc ein post nesaf 🙂 … Daliwch ati i wylio!!
PS: Mae'n ddrwg gen i, alla i ddim cadw'n dawel 🤐 ..Ydych chi wedi clywed am Gwenwyno Arteffactau ? 😂
