Di nivîsa me ya berê de li ser CI/CD Pipelines, me dît çawa hackek bikim CI/CD senaryoya ku tê texmîn kirin hat parastin.
Em ê gotina xwe ya di nivîsa berê de bi bîr bînin: me bi hin dest pê kir pipeline ku li hember xeternak bû Jehrîbûna Nerasterast Pipeline Birêverbirî (I-PPE) û, ji bo çareserkirina wê, me biryar da ku em parçe bikin pipeline li duyan:
- 1st pipeline (Avakirina CI), ji bo D-PPE û I-PPE ewle ye, dê koda PR kontrol bike, avakirinê çêbike, û artefaktek çêbike.
- Ya 2yemîn pipeline (Test CI), her weha ji bo D-PPE ewle ye û I-PPE dê koda bingehîn kontrol bike (ji bo dûrketina ji guhertina skrîptên qalikê) û skrîptên orîjînal li dijî artefaktê bicîh bîne.
- Ji bo senkronîzekirina Test CI pipeline ji bo xebitandina PIŞTÎ Build CI pipeline, me bikar anî workflow_run kişok.
Me ev wekî Senaryoya #3 bi nav kir.
Her çend, wekî ku me di wê postê de behs kir, çareseriyên din jî hene, me biryar da ku vê "çareseriyê" ji ber sedemên pedagojîk bicîh bînin, da ku em bikaribin kûrtir bikevin nav qelsiyên CI/CD pipelines.
Paşê, me dît ka meriv çawa vê senaryoyê hack dike jehrîkirina berhemêEv tiştê ku em jê re dibêjin e Jehrîbûna Berhemên Hunerî, ango şiyana guherandina (hackkirina) pipeline mentiq bi guhertina a pipeline berhem.
Pirsgirêka vê rêbazê çi ye? Me dît ku pirsgirêk dema ku bikarhênerek "diafirîne" sîstemek nû derdikeve holê. pipeline.
Eger bikarhêner PR-yek veke ku tê de nameyek nû heye pipeline, GitHub dê wê bicîh bîne pipeline (bi hin mercan, wekî ku me dît) di postê de).
wê demê bikarhêner dikare peyamek nû çêbike, pipeline bi heman navî wekî Build CI !! Erê, ecêb e, lê GitHub dihêle hûn du biafirînin pipelinebi heman navî!!
Dema ku bikarhêner PR-yek bi van guhertinan vedike, "nû" pipeline dê were bicîhanîn (barkirina berhemeke jehrî) û CI-ya Bicîhkirinê pipeline piştî wê dê were bicîhanîn, di encamê de skrîpta qalikê ya "guhertî" skrîpta qalikê ya "orîjînal" a ku di nav de ye, li ser binivîse. pipeline qada xebatê. Ji ber vê yekê, ev "çareserî" ji lawaziya I-PPE dûr naxe (wekî ku em dikarin li jêr bibînin)
Pirsgirêk çi ne? Bi kêmanî, çend pirsgirêk hene:
- Yekem, meriv çawa piştrast dibe ku pêvajoya avakirinê nehatiye destwerdan kirin? Di vê senaryoyê de, bikarhênerê xerabkar kariye pêvajoya avakirina armanckirî bi karanîna xwe biguherîne. pipeline ji bo çêkirina berhemeke jehrî.
- Duyemîn Em çawa dikarin afirîna berhemeke orîjînal binirxînin?
Ev pirs me diavêjin nav lepên Eşkerekirinên Nermalavê domain!!
Eşkerekirinên Nermalavê
An pejirandin perçeyek ji ye jimare temsîl dike delîla bûyerekêDi cîhana rastîn de, em bi gelemperî van wekî belgeyan.
Bo nimûne, dema ku laboratîfek xwîna we diceribîne, daneyên derbarê testê de têne tomar kirin û pejirandin. Encamên testa xwînê piştrast kirin û şopandin.
Nêzîkî qada me ya IT-ê, hûn dikarin texmîn bikin ka wergerandina vê pêvajoyê dê çi be, wek mînak, pêvajoyek berhevkirinê.
Agahiyên li ser jîngeha servera berhevkirinê û amûran, materyalan (koda çavkaniyê), û berhem/berheman (koda dualî) dê beşek ji wê belgekirinê bin.
Bê guman, ji bo ku pêbawerî were peyda kirin, divê şahidî ji hêla şahidekî destûrdar (pejirandî û ne-înkarbar) ve were çêkirin.
Dibe ku hin ji we bifikirin .. û çi ye Cûdahiya di navbera îmze û şahidan de?
Îmze û Tesdîqên Kodê
Di asteke bilind de, yek destnîşan bi karanîna cotek mifte û artefaktekê tê afirandin. Cotek mifte ji mifteyek giştî û mifteyek taybet pêk tê.
Bikarhêner bi karanîna mifteya taybet berhemeke îmze dike, û yên din dikarin îmzeyê bi karanîna mifteya giştî verast bikin. Divê mifteya taybet veşartî bimîne, lê mifteya giştî bi berfirehî tê belavkirin.
Îmze dikarin werin bikar anîn ji bo îspatkirina ku xwediyê mifteya taybet mifteya taybet ji bo îmzekirina berhemê bi kar aniye.
Îmzeyan îspat neke
- Bikarhêner nêt ji bo îmzekirina berhemê (dibe ku ew hatibin xapandin), an
- Niyeta bikarhêner ji bo çikirina her îdiayeke taybet li ser berhemê
Bi Belgekirin, li şûna ku rasterast îmze bikin berhemeke nerast, bikarhêner cureyekî diafirînin belge va niyeta wan pêk tîne li pişt îmzekirina berhemê û her tiştî îdîayên taybetî wekî beşek ji vê îmzeyê tê çêkirin.
Çarçoveya Tesdîqkirinê ya Bi Tevahî
Çarçoveya herî gelemperî ew e ku Çarçoveya Tesdîqkirinê ya Bi Tevahî
- diyar dike a standard formata ji bo şahidiyan ku mijaran, ango berhemên ku têne vegotin, bi metadatayên rastkirî yên li ser berhemê ve girêdidin.
- komek ji peyda dike pêşgotinên pêşwext-diyarkirî ji bo ragihandina metadatayên pejirandî li seranserê zincîrên dabînkirina nermalavê û li seranserê wan
Werin em bi hûrgulî li ser forma pejirandinê rawestin.
An Belgekirin e ku belgeyeke bi îmzeya dîjîtal ku tê de heye Daxuyaniyên.
Ew Îfade qata navîn a belgekirinê ye, ku wê bi cîhek taybetî ve girêdide Mijar û bi awayekî bê guman cureyên Pêvek:
- Mijar: a referansa krîptografîk a ewle ji bo berhemê (bi gelemperî bi rêya hashekê), û
- Predicates: komek ji taybetî îdîaya derbarê wê berhemê de wekî Daxuyanî tê binavkirin. Ev îdîa dikarin ji bo îfadekirina (û paşê îspatkirina) her tiştê ku hûn dikarin bifikirin werin bikar anîn! Ew dikarin pejirandina destanî, çavkaniya berhemê, encamên ceribandina otomatîk, şopa denetimê, an bêtir temsîl bikin!
Dema ku ev Daxuyanî bi krîptografîkî tê îmzekirin, wê hingê wekî Belgekirin
Bi vî awayî, wek mînak, Alice Daxuyaniyek li ser berhemeke çêkirî diafirîne û bi karanîna mifteya xwe ya taybet îmze dike, bi vî awayî Wesfiyenameyekê diafirîne.
- Hingê Bob dikare îmzeyê piştrast bike di wê belgenameyê de, rê dide wî baweriya xwe bi îdîayan bînin nav.
Dûv re Bob dikare wan îdîayan bikar bîne biryar dan gelo destûr bide ku ev berhem were bikar anîn an na.
Ma şahidname dikarin ji bo çareserkirina Jehrîbûna Hunerî bibin alîkar?
Piştî vê pêşgotina li ser Wesfandinan, em vegerin ser pirsgirêka xwe. Çawa belgename dikarin ji bo çareserkirina pirsgirêka me, ango ji bo dûrketina ji jehrîbûna berhemên dîrokî, alîkariya me bikin?
Bikarhênerê xerabkar karibû bêyî ku mekanîzmaya "fermî" derbas bike, ango bi karanîna xwe/xwe, artefaktek biafirîne. pipeline ji bo çêkirina hunerî.
Ew ê ecêb be ger em bikaribin îspat bikin ku berhemên ku têne dakêşandin bi fermî hatine çêkirin pipelines. Ev tenê yek mînak e ji wan tiştên ku em dikarin wekî "xalên destwerdanê" bi nav bikin, lê dibe ku gelekên din jî hebin.
Wekî ku hûn di wêneyê jorîn de dibînin, xalên destwerdanê pirjimar in. Bi vî rengî, xerîdar pipeline (Test CI di mînaka me de) divê binirxîne yekparçeyiya pêvajoya avakirinê û herweha yekparçeyiya berhemê bi xwe.
Di mînaka me de, berhema jehrî bi danasîna berhemeke nû (jehrîkirî) hatiye afirandin. pipeline ku destwerdanê di pêvajoya avakirinê de dike. Lê bikarhênerê xerabkar dikaribû:
- kodê piştî ku ji kontrolkirinê hate derxistin biguherînin SCM ji bo çêkirina binaryeyek xirabkar
- pelê binary yê rast ê ku ji hêla berhevkirinê ve hatî hilberandin bi her pelê binary yê din ê xerabkar biguherînin
- Qeyda Berhemên Nesneyî xera bike û berhemeke jehrîkirî ya ku bi awayekî din hatiye çêkirin bar bike
- hwd.
Wekî ku hûn dibînin, dibe ku gelek xalên "destwerdanê" hebin.
Li vir çi girîng e? Bêguman parastina hemû wan xalên "destwerdanê". Lê di dawiyê de, ya herî girîng ev e ku "xerîdar"ê berhemê dikare yekparçeyiya berhemê binirxîne û biryar bide ka bi wê re berdewam bike an na.
Em dikarin yekparçeyiya berhemeke dîrokî binirxînin bi du awayan.
Yek jê bi nirxandina provenance ya berhemê.
Bi çêkirina Belgeya Jêderkê, em metadatayên kêrhatî (bi rêkûpêk hatine pejirandin û ne-înkarkirin) li ser berhemê peyda dikin. Di mînakên jêrîn de, em ê bi kar bînin Xwêya Xygenî (Qata Tesdîqkirina Nermalavê ji bo Baweriyê), pêkhateya ji bo çêkirin, qeydkirin û verastkirina tesdîqkirinên nermalavê.
- name: Building ...
run: |
# mvn will compile and create target/MyApp.war
mvn clean package
- name: Generating provenance
run: |
#!/usr/bin/env bash
shopt -s expand_aliases
alias salt=$PWD/salt_pro/xygeni_salt/salt
echo " "
echo "-----------"
echo "Generating Provenance with CLI ..."
salt at slsa \
--basedir ${GITHUB_WORKSPACE}/target \
--key="${PRIVATE_KEY}" \
--public-key=${GITHUB_WORKSPACE}/Test1_public.pem \
--key-password=${KEY_PASSWD} \
--output-unsigned=${GITHUB_WORKSPACE}/cli_provenance_${PIPELINE}_unsigned.json \
--pipeline ${PIPELINE} --pretty-print \
--file ./MyApp.war
Di koda jorîn de, hûn dikarin bibînin ku gavek heye ku pelê şer ava dike û gavek duyemîn heye ku Belgeya JêderkêJi bo kirina wê, pipeline mifteya taybet bikar tîne û mifteya giştî jî di belgeya pejirandinê de digire nav xwe.
Li pişt perdê, Xygeni's xwê ferman şahidiyê di a de tomar dike ledger (wekî qeyda şahidiyê, Rekor Di rewşa me de, lê hûn dikarin yên din bikar bînin). Bi vî awayî, xerîdar pipeline dikare Xygeni jî di nav xwe de bigire Motora Verastkirinê ji bo verastkirina çavkaniya berhemê û nirxandina yekparçeyiya berhemê.
- name: 'Verifying the attestation'
run: |
#!/usr/bin/bash
echo " "
echo "-------"
# Calculate sha256sum for the artifact
SHA_SUM=$(sha256sum ./MyApp.war | cut -f1 -d ' ')
# Recover the attestation Id from the sha256sum
ATT_ID=$(echo $(salt -q registry search --digest sha256:$SHA_SUM --format json) | jq -r .[-1].gitoidSha256)
echo " "
echo "-------"
# Download the provenance attestation
echo "Downloading the provenance attestation ..."
salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json
echo " "
echo "-------"
echo "Verifying provenance ..."
salt verify \
--basedir ${GITHUB_WORKSPACE} \
--attestation=${GITHUB_WORKSPACE}/provenance_kk.signed.json \
--public-key=${GITHUB_WORKSPACE}/Test1_public.pem \
--file ./MyApp.war
Pêvajoya piştrastkirinê van nirxandinan dike:
- Ew berhema sha256sum derbasdar e (ango derbarê wê "mijarê" de belgeyek heye), û
- Ew şahidname bi awayekî rast hatiye piştrastkirin (ew bi karanîna mifteya taybet a têrker hatiye çêkirin)
Ev pêvajoya verastkirinê dikare binirxîne ka hem belge û hem jî belgeya piştrastkirinê derbasdar in.
Lê, wekî ku hûn ji bîr dikin, di doza me de, artefakt ji hêla "xerabkar" ve hate çêkirin. pipeline (ango ne orîjînal bi guherînek pipeline). Hingê divê em pêşde biçin û aliyekî din kontrol bikin: ew berhem ji hêla "orîjînal" ve hatiye çêkirin pipeline, ne yekî din.
Ji bo vê yekê, tenê rêzek hêsan têxin nav xwe da ku ji bo wê şertê kontrol bikin, mînakî:
echo " "
echo "-------"
# Download the provenance attestation
echo "Downloading the provenance attestation ..."
salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json
WFR=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json |base64 -d | jq -r .predicate.buildDefinition.internalParameters.environment.GITHUB_WORKFLOW_REF)
echo $WFR | grep cicd_top10_3_salt\/.github\/workflows\/build.yml
Ev kontrolkirina zêde dê bi ser nekeve ger berhema "ewle" ya me nehatibe çêkirin. pipeline.
Heke berhem ji hêla orîjînala me ve hatibe çêkirin pipeline (cicd_top10_3_salt/.github/workflows/build.yml), fermana grep dê biserkeve, wekî din, ew ê têk biçe, û wê bişkîne. pipeline û rawestandina her gavên din.
"Avaker" pipeline tenê xalek destwerdanê ye ku were kontrol kirin lê, wekî berê jî hate gotin, hin xalên din ên destwerdanê hene ku divê em kontrol bikin.
Bo nimûne, Ger piştî kontrolkirina depoyê û berî fermana avakirinê koda çavkaniyê hatibe guhertin wê çi bibe? Di vê rewşê de, koda ku were çêkirin ne wekî koda ku di SCM.
Kontrolkirina vê xala destwerdanê ewqas hêsan e ku meriv di her gavê de hashên materyalê kontrol bike.
SHA_ATT_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[0].predicate.materials[].digest[])
SHA_STEP_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[3].predicate.materials[0].digest[])
encamên
Bi kurtasî, Pejirandina Nermalavê îdiayek e ku li ser perçeyek nermalavê tê kirin, ango daxuyaniyek pejirandî (metadata) li ser berhemeke nermalavê an berhevokeke berhemên nermalavê.
Wesfiyetkirinên nermalavê giştîkirinek ji îmzekirina kod/artefakta xav in. Wesfiyet belgeyek îmzekirî ye (bi formateke diyarkirî, bi gelemperî li ser bingeha JSON) ku metadata bi artefaktekê ve girêdide. Ew delîlên ku di her gava avakirinê de têketin (materyal) û derketin (artefaktên hilberandî) bi hev ve girêdidin temsîl dikin.
Wesfdan qeydeke verastkirî ya gavên ku ji bo avakirina berhemên nermalava dawîn hatine kirin peyda dikin, di nav de materyalên têketinê ji bo her gavê û fermanên avakirinê yên hatine xebitandin.
Di encamê de, Tesdîqkirinên Nermalavê mekanîzmayeke girîng e ji bo kontrolkirina gelek aliyên cuda yên yekparebûna pêvajoya avakirina me.
Rêzefîlm qedand? Xem meke! Hûn dikarin dîsa vegerin ser 'Bi poz kirin Pipeline Cihbicîhkirin (PPE)' an jî her postek din ku dîsa bala we dikişîne!
Li bendê bin, em ê bi kûrahî bikevin nav piştrastkirinên nermalavê û build security di nivîsên blogê yên din de.
