በቀደመው ጽሑፋችን ስለ CI/CD Pipelines, አየን እንዴት ሀክ ማድረግ እንደሚቻል CI/CD ሁኔታው መገመት ይቻላል ተጠብቆ ነበር።
ባለፈው ጽሁፍ ላይ ያነሳነውን ነጥብ እናስታውስ፡- በአንዳንድ ጀምረናል pipeline ለዚያ ተጋላጭ ነበር በተዘዋዋሪ የተመረዘ Pipeline ማስፈጸም (I-PPE) እና ለማስተካከል፣ ለመለያየት ወሰንን pipeline ወደ ሁለት፦
- The 1st pipeline (CI ግንባታ)፣ ለD-PPE እና I-PPE ደህንነቱ የተጠበቀ፣ የህዝብ ግንኙነት ኮዱን ይፈትሻል፣ ግንባታውን ያዘጋጃል እና ቅርስ ያመነጫል
- 2nd pipeline (Test CI)፣ እንዲሁም ለD-PPE እና I-PPE ደህንነቱ የተጠበቀ ነው (የሼል ስክሪፕት ማሻሻያን ለማስቀረት) የመሠረት ኮዱን ይፈትሹ እና የመጀመሪያዎቹን ስክሪፕቶች ከቅርስ ጋር ያከናውናሉ።
- የሙከራ CIን ለማመሳሰል pipeline ከግንባታ CI በኋላ ለማስኬድ pipeline፣ ተጠቀምን። የስራ ፍሰት_ሩጫ ቀስቅሴ
ይህንን ሁኔታ #3 ብለን ሰየምነው።
ምንም እንኳን፣ በዚያ ጽሑፍ ላይ እንደጠቀስነው፣ ሌሎች መፍትሄዎች ቢኖሩም፣ ይህንን “መፍትሄ” ለትምህርታዊ ምክንያቶች ተግባራዊ ለማድረግ ወስነናል፣ ስለዚህም ወደ ተጋላጭነቶች በጥልቀት ዘልቀን እንድንገባ CI/CD pipelines.
ከዚያ በኋላ፣ ይህንን ሁኔታ እንዴት መጥለፍ እንደሚቻል አይተናል ቅርሱን መመረዝእኛ የምንጠራው ይህ ነው የቅርስ መርዝ, ማለትም የመቀየር (የመጥለፍ) ችሎታ pipeline ሎጂክን በማሻሻል pipeline ቅርስ።
የዚህ አካሄድ ችግር ምንድነው? ችግሩ የሚፈጠረው ማንኛውም ተጠቃሚ አዲስ "ሲፈጥር" እንደሆነ አይተናል። pipeline.
አንድ ተጠቃሚ አዲስ የህዝብ ግንኙነት (PR) የያዘ ከሆነ pipelineጊትቡክ ያንን ያስፈጽማል pipeline (እንደተመለከትነው አንዳንድ ቅድመ ሁኔታዎችን ከግምት ውስጥ በማስገባት) በፖስታው ውስጥ).
ከዚያ ተጠቃሚው አዲስ መፍጠር ይችላል pipeline ከBuild CI ጋር ተመሳሳይ ስም ያለው!! አዎ፣ አስገራሚ ነው፣ ግን GitHub ሁለት እንዲፈጥሩ ይፈቅድልዎታል pipelineዎች በተመሳሳይ ስም!!
ተጠቃሚው እነዚህን ለውጦች የያዘ የህዝብ ግንኙነት (PR) ሲከፍት፣ "አዲሱ" pipeline ይፈጸማል (የተመረዘ ቅርስ በመስቀል ላይ) እና የDeploy CI pipeline ከዚያ በኋላ ይፈጸማል፣ በዚህም ምክንያት “የተሻሻለው” የሼል ስክሪፕት በ"ኦርጅናል" የሼል ስክሪፕት ላይ እንዲተካ ያደርጋል። pipeline የስራ ቦታ። ስለዚህ፣ ይህ "መፍትሄ" የI-PPE ተጋላጭነትን አያስወግድም (ከታች እንደምናየው)
ችግሮቹ ምንድናቸው? ቢያንስ ሁለት ችግሮች አሉ፡
- አንደኛ, የግንባታ ሂደቱ እንዳልተነካ እንዴት ማረጋገጥ ይቻላል? በዚህ ሁኔታ፣ ተንኮል አዘል ተጠቃሚው የእነሱን በመጠቀም የታሰበውን የግንባታ ሂደት ማሻሻል ችሏል pipeline የተመረዘ ቅርስ ለመፍጠር።
- ሁለተኛ, የአንድን ቅርስ አመጣጥ እንዴት መገምገም እንችላለን?
እነዚህ ጥያቄዎች ወደ እቅፍ ውስጥ ይጥሉናል የሶፍትዌር ማረጋገጫዎች ዶሜይን!!
የሶፍትዌር ማረጋገጫዎች
An ማረጋገጫ ቁራጭ ነው መረጃ የሚወክለው የአንድ ክስተት ማረጋገጫበእውነተኛው ዓለም፣ በአጠቃላይ እነዚህን እንላቸዋለን ማረጋገጫዎች.
ለምሳሌ፣ የላብራቶሪ ደምዎን ሲመረምር፣ ስለ ምርመራው የሚገልጽ መረጃ ይመዘገባል እና የተረጋገጠ ይሆናል። የደም ምርመራ ውጤቶቹ የሚከተሉት ናቸው ሊረጋገጥ የሚችል ና ሊታወቅ የሚችል.
ከ IT ጎራችን ጋር ቅርብ፣ የዚህ ሂደት ትርጉም ምን ሊሆን እንደሚችል መገመት ይችላሉ፣ ለምሳሌ የማጠናቀር ሂደት።
ስለ ማጠናቀሪያ አገልጋይ አካባቢ እና መሳሪያዎች፣ ቁሳቁሶች (የምንጭ ኮዱ) እና ምርቶች/ቅርሶች (የሁለትዮሽ ኮዱ) መረጃ የዚህ ማረጋገጫ አካል ይሆናል።
በግልጽ ለማየት እንደሚቻለው፣ ማረጋገጫው ተአማኒነት እንዲኖረው በተፈቀደለት ማረጋገጫ ሰጪ (በተረጋገጠ እና ውድቅ ባልሆነ) መፈጠር አለበት።
ምናልባት አንዳንዶቻችሁ እያሰባችሁ ይሆናል… እና ምንድነው? በፊርማዎች እና በምስክር ወረቀቶች መካከል ያለው ልዩነት?
የኮድ ፊርማዎች እና ማረጋገጫዎች
በከፍተኛ ደረጃ፣ ኤ. ፊርማ የቁልፍ ጥንድ እና የቅርስ ጥንድ በመጠቀም ይፈጠራል። የቁልፍ ጥንድ የህዝብ ቁልፍ እና የግል ቁልፍ ያካትታል።
ተጠቃሚው የግል ቁልፉን በመጠቀም አንድ ቅርስ ይፈርማል፣ ሌሎች ደግሞ ይፋዊ ቁልፉን በመጠቀም ፊርማውን ማረጋገጥ ይችላሉ። የግል ቁልፉ በሚስጥር መያዝ አለበት፣ ነገር ግን የህዝብ ቁልፉ በስፋት ይሰራጫል።
ፊርማዎች ጥቅም ላይ ሊውሉ ይችላሉ የግል ቁልፉ ባለቤት ቅርሱን ለመፈረም የግል ቁልፉን እንደተጠቀመ ለማረጋገጥ.
ፊርማዎች አታረጋግጥ
- የተጠቃሚው ሐሳብ ቅርሱን ለመፈረም (ሊታለሉ ይችላሉ)፣ ወይም
- የተጠቃሚው ፍላጎት ማንኛውንም ነገር ለማድረግ ስለ ቅርሱ የተወሰነ የይገባኛል ጥያቄ
ጋር ማረጋገጫዎችተጠቃሚዎች በቀጥታ አንድን ቅርስ ከመፈረም ይልቅ የሆነ ዓይነት ነገር ይፈጥራሉ ሰነድ ያ ዓላማቸውን ይይዛቸዋል ቅርሱን ከመፈረም ጀርባ እና ማንኛውንም የተወሰኑ የይገባኛል ጥያቄዎች የዚህ ፊርማ አካል ሆኖ የተሰራ።
የውስጠ-ቶ ማረጋገጫ ማዕቀፍ
በጣም የተለመደው ማዕቀፍ ነው የውስጠ-ቶቶ የምስክርነት ማዕቀፍ
- ይገልጻል ሀ standard የምስክር ወረቀቶች ቅርጸት ርዕሰ ጉዳዮችን፣ የሚገለጹትን ቅርሶች፣ ስለ ቅርሱ ከተረጋገጡ ሜታዳታዎች ጋር የሚያያይዙ
- የሚከተሉትን ስብስብ ያቀርባል አስቀድሞ የተገለጹ ተተኪዎች የተረጋገጠ ሜታዳታ በመላው እና በሶፍትዌር አቅርቦት ሰንሰለቶች ውስጥ ለማስተላለፍ
ስለ ማረጋገጫው ቅርጸት በዝርዝር እንመልከት።
An ማረጋገጫ ነው በዲጂታል የተፈረመ ሰነድ ይ containsል መግለጫዎች.
የ ሐሳብ የምስክር ወረቀቱ መካከለኛ ንብርብር ሲሆን ከአንድ የተወሰነ ማረጋገጫ ጋር የተያያዘ ነው። ያስተያየትዎ ርዕስ እና የዝርዝሮቹን ዓይነቶች በግልጽ መለየት ተንብዮ:
- ያስተያየትዎ ርዕስ: ሀ ለቅርሱ ሚስጥራዊ በሆነ መልኩ ደህንነቱ የተጠበቀ ማጣቀሻ (ብዙውን ጊዜ በሃሽ)፣ እና
- ትንቢቶች: የተወሰኑ ስብስቦች የይገባኛል ጥያቄዎች ስለዚያ ቅርስ መግለጫ ተብሎ ይጠራል። እነዚህ የይገባኛል ጥያቄዎች ሊያስቡበት የሚችሉትን ማንኛውንም ነገር ለመግለጽ (እና በኋላም ለማረጋገጥ) ሊያገለግሉ ይችላሉ! በእጅ ማፅደቅን፣ የቅርስ አመጣጥን፣ አውቶማቲክ የፈተና ውጤቶችን፣ የኦዲት ዱካን ወይም ሌሎችንም ሊወክሉ ይችላሉ!
ይህ መግለጫ በክሪፕቶግራፊያዊ መንገድ ሲፈረም፣ ከዚያም እንደ ማረጋገጫ
በዚህ መንገድ፣ ለምሳሌ፣ አሊስ ስለ አንድ ቅርስ መግለጫ ትፈጥራለች እና የግል ቁልፏን በመጠቀም ትፈርማለች፣ ማረጋገጫም ትፈጥራለች።
- ቦብ ከዚያ ይችላል ፊርማውን ያረጋግጡ በዚያ የምስክር ወረቀት ውስጥ፣ እሱን በመፍቀድ የይገባኛል ጥያቄዎችን ማመን ውስጥ.
ቦብ ከዚያ እነዚያን የይገባኛል ጥያቄዎች ሊጠቀም ይችላል መወሰን ይህ ቅርስ ጥቅም ላይ እንዲውል መፍቀድ ወይም አለመፍቀድ።
የምስክር ወረቀቶች የቅርስ መርዝን ለመፍታት ይረዳሉ?
ከዚህ የማረጋገጫ ጽሑፍ መግቢያ በኋላ፣ ወደ ችግራችን እንመለስ። የምስክርነት ቃሎች ችግራችንን ለመፍታት እንዴት ሊረዱን ይችላሉ፣ ማለትም የቅርስ መመረዝን ለማስወገድ?
ተንኮል አዘል ተጠቃሚው “ኦፊሴላዊውን” ዘዴ በማለፍ ቅርስ መፍጠር ችሏል፣ ማለትም የእሱን/የእሷን በመጠቀም። pipeline ቅርሱን ለመፍጠር።
የሚወርዱት ቅርሶች ከባለስልጣኑ ጋር የተገነቡ መሆናቸውን ማረጋገጥ ብንችል አስደናቂ ይሆናል። pipelines. ይህ “የመስተጓጎል ነጥቦች” ብለን ልንጠራቸው ከምንችላቸው ነገሮች አንዱ ምሳሌ ብቻ ነው፣ ነገር ግን ሌሎች ብዙ ሊሆኑ ይችላሉ።
ከላይ ባለው ሥዕል ላይ እንደሚታየው፣ የማስተባበያ ነጥቦቹ በርካታ ናቸው። በዚህ መንገድ፣ ሸማቹ pipeline (በምሳሌያችን የሙከራ CI) መገምገም አለበት የግንባታ ሂደቱ ትክክለኛነት እና እንዲሁም የቅርሱ ትክክለኛነት ራሱ.
በእኛ ምሳሌ፣ የተመረዘው ቅርስ የተፈጠረው አዲስ (የተመረዘ) በማስተዋወቅ ነው pipeline ይህ የግንባታ ሂደቱን ያዛባል። ነገር ግን ተንኮል አዘል ተጠቃሚው የሚከተሉትን ማድረግ ይችል ነበር፦
- ኮዱን ከወጡ በኋላ ያስተካክሉት SCM ተንኮል አዘል ባይነሪ ለመፍጠር
- በማጠናቀር የተፈጠረውን ትክክለኛውን ባይነሪ ከሌላ ተንኮል አዘል ባይነሪ ጋር ይተኩ
- የቅርስ መዝገብ ቤትን ማበላሸት እና በሌላ መንገድ የተገነባ መርዛማ ቅርስ መስቀል
- ወዘተ
እንደምታየው፣ በርካታ "የማስተጓጎል" ነጥቦች ሊኖሩ ይችላሉ።
እዚህ ላይ ምን አስፈላጊ ነው? እነዚያን "የሚያበላሹ" ነጥቦች ሁሉ ለመጠበቅ ግልጽ ነው። ግን በመጨረሻ፣ በጣም አስፈላጊው ነገር የቅርሱ "ሸማች" የቅርሱ ትክክለኛነት መገምገም እና ወደፊት መሄድ ወይም አለመቀጠል መወሰን እንደሚችል።
እንችላለን የአንድ ቅርስ ትክክለኛነት መገምገም በሁለት መንገዶች።
አንደኛው በመገምገም ነው provenance የቅርስ ቅርሱ።
በማመንጨት አንድ የመነሻ ማረጋገጫስለ ቅርሱ ጠቃሚ ሜታዳታ (በአግባቡ የተረጋገጠ እና ያልተካደ) እናቀርባለን። በሚከተሉት ምሳሌዎች ውስጥ፣ እንጠቀማለን የዚጀኒ ጨው (የሶፍትዌር ማረጋገጫ ንብርብር ለእምነት)፣ የሶፍትዌር ማረጋገጫዎችን ለማመንጨት፣ ለመመዝገብ እና ለማረጋገጥ የሚያገለግል አካል።
- 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
ከላይ ባለው ኮድ ውስጥ፣ የጦርነት ፋይልን የሚገነባ ደረጃ እና ሁለተኛውን የሚያመነጭ ደረጃ እንዳለ ማየት ይችላሉ። የመነሻ ማረጋገጫለማድረግ፣ pipeline የግል ቁልፉን የሚጠቀም ሲሆን በማረጋገጫው ውስጥም የህዝብ ቁልፉን ያካትታል።
ከትዕይንቱ በስተጀርባ፣ የዚጌኒ ጨው ትዕዛዝ የምስክር ወረቀቱን በ ውስጥ ያከማቻል ያሰኘንን (የማረጋገጫ መዝገብ በመባልም ይታወቃል፣ ሬኮር በእኛ ሁኔታ ግን ሌላ ማንኛውንም መጠቀም ይችላሉ)። ይህንን ካደረግን በኋላ፣ ሸማቹ pipeline የ Xygeni's ሊያካትት ይችላል የማረጋገጫ ፕሮግራም የቅርሱ አመጣጥ ለማረጋገጥ እና የቅርሱ ትክክለኛነት ለመገምገም።
- 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
የማረጋገጫ ሂደቱ የሚከተሉትን ይገመግማል፦
- የ ቅርስ sha256sum ትክክለኛ ነው (ማለትም ስለዚያ "ርዕሰ ጉዳይ" ማረጋገጫ አለ)፣ እና
- የ ማረጋገጫው በትክክል የተረጋገጠ ነው (በቂ የሆነ የግል ቁልፍ በመጠቀም የተፈጠረ ነው)
ይህ የማረጋገጫ ሂደት ሁለቱም ቅርሶች እና ማረጋገጫው ትክክለኛ መሆናቸውን መገምገም ይችላል።
ግን እንደምታስታውሱት፣ በእኛ ሁኔታ፣ ቅርሱ የተፈጠረው “ተንኮል አዘል” በሆነ ሰው ነው። pipeline (ማለትም በተሻሻለው የመጀመሪያው አይደለም pipeline) ከዚያም ወደ ሌላ ገጽታ መሄድ አለብን፤ ያ ቅርሱ የተፈጠረው በ"ኦሪጅናል" ነው pipeline, ሌላ ማንም አይደለም።
ይህንን ለማድረግ፣ ለዚያ ሁኔታ ለመፈተሽ ቀላል መስመር ብቻ ያካትቱ፣ ለምሳሌ፡
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
ይህ ተጨማሪ ፍተሻ በ"ደህንነታችን" ካልተፈጠረ አይሳካም። pipeline.
ቅርሱ የተፈጠረው በዋናው ቅርሳችን ከሆነ pipeline (cicd_top10_3_salt/.github/workflows/build.yml)፣ የgrep ትዕዛዙ ይሳካል፣ አለበለዚያ ይከሽፋል፣ ይህም ይጥሳል። pipeline እና ማንኛውንም ተጨማሪ እርምጃዎች ማቋረጥ።
"ገንቢው" pipeline አንድ የማስተባበያ ነጥብ ብቻ ነው ነገር ግን ቀደም ሲል እንደተጠቀሰው ልንፈትሻቸው የሚገቡ ሌሎች የማስተባበያ ነጥቦች አሉ።
ለምሳሌ, የምንጭ ኮዱ ከመጠባበቂያ ክፍያ በኋላ እና ከግንባታ ትዕዛዙ በፊት ከተበላሸስ? በዚህ ሁኔታ፣ የሚገነባው ኮድ በ ውስጥ ከተከማቸው ጋር ተመሳሳይ አይደለም። SCM.
ይህንን የማጭበርበር ነጥብ ማረጋገጥ በጣም ቀላል ነው ምክንያቱም በእያንዳንዱ ደረጃ የቁሳቁሱን ሃሽዎች መፈተሽ በጣም ቀላል ነው።
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[])
ታሰላስል
ባጭሩ፣ አንድ የሶፍትዌር ማረጋገጫ ስለ አንድ የሶፍትዌር ክፍል፣ ማለትም ስለ አንድ የሶፍትዌር ቅርስ ወይም የሶፍትዌር ቅርሶች ስብስብ የተረጋገጠ መግለጫ (ሜታዳታ) ነው።
የሶፍትዌር ማረጋገጫዎች ጥሬ ቅርስ/ኮድ ፊርማ አጠቃላይ መግለጫ ናቸው። ማረጋገጫው የተፈረመበት ሰነድ (በተለየ ቅርጸት፣ በተለምዶ በJSON ላይ የተመሠረተ) ሲሆን ሜታዳታ ከአንድ ቅርስ ጋር ያቆራኛል። በእያንዳንዱ የግንባታ ደረጃ ግብዓቶችን (ቁሳቁሶችን) እና ውጤቶችን (የተመረቱ ቅርሶችን) የሚያገናኙ ማስረጃዎችን ይወክላሉ።
የምስክር ወረቀቶች የመጨረሻውን የሶፍትዌር ቅርሶች ለመገንባት የተከናወኑትን እርምጃዎች ሊረጋገጥ የሚችል መዝገብ ይሰጣሉ፣ ይህም ለእያንዳንዱ ደረጃ የግብዓት ቁሳቁሶችን እና የሚሄዱትን የግንባታ ትዕዛዞችን ጨምሮ።
ለማጠቃለል ያህል፣ የሶፍትዌር ማረጋገጫዎች የግንባታ ሂደታችንን የተለያዩ የታማኝነት ገጽታዎችን ለመፈተሽ በጣም ጥሩ ዘዴ ናቸው።
ተከታታዩን ጨርሰዋል? አይጨነቁ! ወደ 'ለመመለስ ነፃነት ይሰማዎ።የተመረዘ Pipeline አፈፃፀም (PPE)' ወይም እንደገና ፍላጎትዎን የሚነካ ሌላ ማንኛውም ልጥፍ!
ይጠብቁን፣ በሶፍትዌር ማረጋገጫዎች ላይ በጥልቀት እንመረምራለን እና build security በሚቀጥሉት የብሎግ ልጥፎች ውስጥ።
