នៅក្នុងប្រកាសមុនរបស់យើងអំពី CI/CD Pipelines, យើងបានឃើញ របៀប hack CI/CD សេណារីយ៉ូដែល សន្មត ត្រូវបានការពារ។
ចូរយើងរំលឹកចំណុចរបស់យើងនៅក្នុងអត្ថបទមុន៖ យើងបានចាប់ផ្តើមជាមួយខ្លះ pipeline ដែលងាយរងគ្រោះដោយសារ ពុលដោយប្រយោល Pipeline ការប្រតិបត្តិ (I-PPE) ហើយដើម្បីជួសជុលវា យើងបានសម្រេចចិត្តបំបែក pipeline ទៅជាពីរ៖
- ទី ១ pipeline (សាងសង់ CI) មានសុវត្ថិភាពចំពោះ D-PPE និង I-PPE នឹងពិនិត្យមើលលេខកូដ PR ធ្វើការសាងសង់ និងបង្កើតវត្ថុបុរាណ។
- ទី ៤២ pipeline (សាកល្បង CI) ដែលក៏មានសុវត្ថិភាពចំពោះ D-PPE និង I-PPE ដែរ នឹងពិនិត្យមើលកូដមូលដ្ឋាន (ដើម្បីជៀសវាងការកែប្រែស្គ្រីបសែល) ហើយប្រតិបត្តិស្គ្រីបដើមប្រឆាំងនឹងវត្ថុបុរាណ។
- ដើម្បីធ្វើសមកាលកម្ម CI សាកល្បង pipeline ដើម្បីដំណើរការបន្ទាប់ពី Build CI pipeline, យើងបានប្រើ ដំណើរការការងារ កេះ។
យើងបានដាក់ឈ្មោះរឿងនេះថា សេណារីយ៉ូលេខ ៣។
ទោះបីជាដូចដែលយើងបានលើកឡើងនៅក្នុងការបង្ហោះនោះ មានដំណោះស្រាយផ្សេងទៀតក៏ដោយ យើងបានសម្រេចចិត្តអនុវត្ត “ដំណោះស្រាយ” នេះសម្រាប់ហេតុផលគរុកោសល្យ ដូច្នេះយើងអាចស្វែងយល់ស៊ីជម្រៅអំពីភាពងាយរងគ្រោះរបស់ CI/CD pipelines.
ក្រោយមក យើងបានឃើញពីរបៀប hack សេណារីយ៉ូនេះដោយ ការបំពុលវត្ថុបុរាណនេះជាអ្វីដែលយើងហៅថា ការពុលវត្ថុបុរាណពោលគឺសមត្ថភាពក្នុងការកែប្រែ (hack) pipeline តក្កវិជ្ជាដោយការកែប្រែ pipeline វត្ថុបុរាណ។
តើបញ្ហាជាមួយវិធីសាស្ត្រនេះជាអ្វី? យើងបានឃើញថា បញ្ហាកើតឡើងនៅពេលដែលអ្នកប្រើប្រាស់ណាម្នាក់ «បង្កើត» ថ្មី pipeline.
ប្រសិនបើអ្នកប្រើប្រាស់បើក PR ដែលមានថ្មី pipeline, GitHub នឹងប្រតិបត្តិវា pipeline (ដោយផ្តល់លក្ខខណ្ឌមួយចំនួន ដូចដែលយើងបានឃើញ នៅក្នុងប្រកាស).
បន្ទាប់មកអ្នកប្រើប្រាស់អាចបង្កើតថ្មីបាន pipeline ដែលមានឈ្មោះដូចគ្នានឹង Build CI !! មែនហើយ វាគួរឱ្យភ្ញាក់ផ្អើលណាស់ ប៉ុន្តែ GitHub អនុញ្ញាតឱ្យអ្នកបង្កើតពីរ pipelines ដែលមានឈ្មោះដូចគ្នា!!
នៅពេលដែលអ្នកប្រើប្រាស់បើក PR ជាមួយនឹងការផ្លាស់ប្តូរទាំងនេះ "ថ្មី" pipeline នឹងត្រូវបានប្រតិបត្តិ (ផ្ទុកឡើងវត្ថុបុរាណដែលមានជាតិពុល) និងការដាក់ពង្រាយ CI pipeline នឹងត្រូវបានប្រតិបត្តិបន្ទាប់ពីនោះ ដែលបណ្តាលឱ្យស្គ្រីបសែល "កែប្រែ" សរសេរជាន់លើស្គ្រីបសែល "ដើម" ដែលមានទីតាំងនៅក្នុង pipeline កន្លែងធ្វើការ។ ដូច្នេះ “ដំណោះស្រាយ” នេះមិនអាចជៀសវាងភាពងាយរងគ្រោះ I-PPE បានទេ (ដូចដែលយើងអាចមើលឃើញខាងក្រោម)
តើមានបញ្ហាអ្វីខ្លះ? យ៉ាងហោចណាស់ក៏មានបញ្ហាមួយចំនួនដែរ៖
- ជាលើកដំបូង, តើធ្វើដូចម្តេចដើម្បីប្រាកដថាដំណើរការសាងសង់មិនត្រូវបានរំខាន? នៅក្នុងសេណារីយ៉ូនេះ អ្នកប្រើប្រាស់ដែលមានគំនិតអាក្រក់អាចកែប្រែដំណើរការសាងសង់ដែលបានគ្រោងទុកដោយប្រើរបស់ពួកគេ pipeline ដើម្បីបង្កើតវត្ថុបុរាណដែលមានជាតិពុល។
- ទីពីរ, តើយើងអាចវាយតម្លៃប្រភពដើមនៃវត្ថុបុរាណដោយរបៀបណា?
សំណួរទាំងនេះធ្វើឲ្យយើងធ្លាក់ចូលទៅក្នុងកណ្តាប់ដៃរបស់ ការបញ្ជាក់កម្មវិធី ដែន!!
ការបញ្ជាក់កម្មវិធី
An ការបញ្ជាក់ គឺជាបំណែកមួយនៃ data subfolder តំណាង ភស្តុតាងនៃព្រឹត្តិការណ៍មួយនៅក្នុងពិភពពិត ជាទូទៅយើងហៅរឿងទាំងនេះថា ការបញ្ជាក់.
ឧទាហរណ៍ នៅពេលដែលមន្ទីរពិសោធន៍ធ្វើតេស្តឈាមរបស់អ្នក ទិន្នន័យអំពីការធ្វើតេស្តត្រូវបានកត់ត្រា និងបញ្ជាក់។ លទ្ធផលនៃការធ្វើតេស្តឈាមគឺ ផ្ទៀងផ្ទាត់ និង ដាន.
កាន់តែខិតជិតនឹងវិស័យព័ត៌មានវិទ្យារបស់យើង អ្នកអាចទាយបានថាតើដំណើរការនេះនឹងក្លាយជាការបកប្រែយ៉ាងដូចម្តេច ឧទាហរណ៍ ដំណើរការចងក្រង។
ព័ត៌មានអំពីបរិស្ថាន និងឧបករណ៍ម៉ាស៊ីនបម្រើចងក្រង សម្ភារៈ (កូដប្រភព) និងផលិតផល/វត្ថុបុរាណ (កូដគោលពីរ) នឹងជាផ្នែកមួយនៃការបញ្ជាក់បែបនេះ។
ជាក់ស្តែង ការបញ្ជាក់ត្រូវតែបង្កើតឡើងដោយអ្នកបញ្ជាក់ដែលមានការអនុញ្ញាត (មានការផ្ទៀងផ្ទាត់ និងមិនអាចបដិសេធបាន) ដើម្បីផ្តល់ភាពជឿជាក់។
ទំនងជាអ្នកខ្លះប្រហែលជាកំពុងគិតថា .. ហើយតើអ្វីទៅជា ភាពខុសគ្នារវាងហត្ថលេខា និង ភស្តុតាង?
ហត្ថលេខា និងលិខិតបញ្ជាក់កូដ
នៅកម្រិតខ្ពស់មួយ, ហត្ថលេខា ត្រូវបានបង្កើតឡើងដោយប្រើគូសោ និងសិប្បកម្មមួយ។ គូសោនេះមានសោសាធារណៈ និងសោឯកជន។
អ្នកប្រើប្រាស់ចុះហត្ថលេខាលើវត្ថុបុរាណដោយប្រើកូនសោឯកជន ហើយបន្ទាប់មកអ្នកផ្សេងទៀតអាចផ្ទៀងផ្ទាត់ហត្ថលេខាដោយប្រើកូនសោសាធារណៈ។ កូនសោឯកជនត្រូវតែរក្សាទុកជាសម្ងាត់ ប៉ុន្តែកូនសោសាធារណៈត្រូវបានចែកចាយយ៉ាងទូលំទូលាយ។
ហត្ថលេខាអាចប្រើបាន ដើម្បីបញ្ជាក់ថាអ្នកកាន់កូនសោឯកជនបានប្រើកូនសោឯកជនដើម្បីចុះហត្ថលេខាលើវត្ថុបុរាណ.
ហត្ថលេខា។ កុំបញ្ជាក់
- របស់អ្នកប្រើប្រាស់ ចេតនា ដើម្បីចុះហត្ថលេខាលើវត្ថុបុរាណ (ពួកគេប្រហែលជាត្រូវបានគេបោកបញ្ឆោត) ឬ
- ចេតនារបស់អ្នកប្រើប្រាស់ក្នុងការធ្វើអ្វីមួយ ការអះអាងជាក់លាក់អំពីវត្ថុបុរាណ
ជាមួយ ការទាក់ទាញជាជាងការចុះហត្ថលេខាលើវត្ថុបុរាណដោយផ្ទាល់ អ្នកប្រើប្រាស់បង្កើតប្រភេទមួយចំនួន ឯកសារ ថា ចាប់យកចេតនារបស់ពួកគេ នៅពីក្រោយការចុះហត្ថលេខាលើវត្ថុបុរាណ និងណាមួយ ការទាមទារជាក់លាក់ ធ្វើឡើងជាផ្នែកមួយនៃហត្ថលេខានេះ។
ក្របខ័ណ្ឌបញ្ជាក់ក្នុងស្រុក
ក្របខ័ណ្ឌទូទៅបំផុតគឺ ក្របខ័ណ្ឌបញ្ជាក់នៅក្នុង toto
- កំណត់ក standard ទម្រង់សម្រាប់ការបញ្ជាក់ ដែលភ្ជាប់ប្រធានបទ ដែលជាវត្ថុបុរាណដែលកំពុងត្រូវបានពិពណ៌នា ទៅនឹងទិន្នន័យមេតាដែលបានផ្ទៀងផ្ទាត់អំពីវត្ថុបុរាណ។
- ផ្តល់នូវសំណុំនៃ បុព្វបទដែលបានកំណត់ជាមុន សម្រាប់ការទំនាក់ទំនងទិន្នន័យមេតាដែលបានផ្ទៀងផ្ទាត់នៅទូទាំង និងឆ្លងកាត់ខ្សែសង្វាក់ផ្គត់ផ្គង់កម្មវិធី
ចូរយើងពិនិត្យមើលលម្អិតអំពីទម្រង់នៃការបញ្ជាក់។
An ការបញ្ជាក់ ជា ឯកសារដែលបានចុះហត្ថលេខាឌីជីថល ដែលមាន សេចក្តីថ្លែងការណ៍។
ចំពោះ សេចក្តីថ្លែងការណ៍ គឺជាស្រទាប់កណ្តាលនៃការបញ្ជាក់ ដែលចងវាទៅនឹងជាក់លាក់មួយ Subject និងកំណត់អត្តសញ្ញាណប្រភេទដោយមិនសង្ស័យ ទស្សន៍ទាយ:
- Subject: ក ឯកសារយោងដែលមានសុវត្ថិភាពតាមគ្រីបតូក្រាហ្វីទៅកាន់វត្ថុបុរាណ (ជាធម្មតាតាមរយៈហាស) និង
- ព្យាករណ៍: សំណុំជាក់លាក់ ការអះអាង អំពីវត្ថុបុរាណនោះត្រូវបានគេហៅថា សេចក្តីថ្លែងការណ៍។ ការអះអាងទាំងនេះអាចត្រូវបានប្រើដើម្បីបង្ហាញ (ហើយក្រោយមកបញ្ជាក់) អ្វីគ្រប់យ៉ាងដែលអ្នកអាចគិតបាន! ពួកវាអាចតំណាងឱ្យការអនុម័តដោយដៃ ប្រភពដើមនៃវត្ថុបុរាណ លទ្ធផលតេស្តដោយស្វ័យប្រវត្តិ ឯកសារសវនកម្ម ឬច្រើនទៀត!
នៅពេលដែលសេចក្តីថ្លែងការណ៍នេះត្រូវបានចុះហត្ថលេខាជាអក្សរគ្រីបតូ វាត្រូវបានគេហៅថា ការបញ្ជាក់
តាមវិធីនេះ ជាឧទាហរណ៍ Alice បង្កើតសេចក្តីថ្លែងការណ៍អំពីវត្ថុបុរាណមួយ ហើយចុះហត្ថលេខាលើវាដោយប្រើកូនសោឯកជនរបស់នាង ដោយបង្កើតការបញ្ជាក់។
- បន្ទាប់មកលោក Bob អាច ផ្ទៀងផ្ទាត់ហត្ថលេខា នៅក្នុងលិខិតបញ្ជាក់នោះ អនុញ្ញាតឱ្យគាត់ ដើម្បីទុកចិត្តលើការអះអាង នៅខាងក្នុង។
បន្ទាប់មកលោក Bob អាចប្រើប្រាស់ការអះអាងទាំងនោះ សម្រេចចិត្ត ថាតើត្រូវអនុញ្ញាតឱ្យប្រើប្រាស់វត្ថុបុរាណនេះឬអត់។
តើការបញ្ជាក់អាចជួយដោះស្រាយការពុលវត្ថុបុរាណបានទេ?
បន្ទាប់ពីការណែនាំអំពីការបញ្ជាក់នេះ សូមយើងត្រលប់ទៅបញ្ហារបស់យើងវិញ។ តើការបញ្ជាក់អាចជួយយើងដោះស្រាយបញ្ហារបស់យើងយ៉ាងដូចម្តេច ពោលគឺដើម្បីជៀសវាងការពុលវត្ថុបុរាណ?
អ្នកប្រើប្រាស់ដែលមានគំនិតអាក្រក់អាចបង្កើត artifact ដោយរំលងយន្តការ "ផ្លូវការ" ពោលគឺដោយប្រើរបស់គាត់/នាង pipeline ដើម្បីបង្កើតវត្ថុបុរាណ។
វានឹងអស្ចារ្យណាស់ ប្រសិនបើយើងអាចបញ្ជាក់ថា វត្ថុបុរាណដែលកំពុងត្រូវបានទាញយកត្រូវបានសាងសង់ឡើងជាមួយមន្ត្រី pipelineស. នេះគ្រាន់តែជាឧទាហរណ៍មួយនៃអ្វីដែលយើងអាចហៅថា "ចំណុចរំខាន" ប៉ុន្តែអាចមានចំណុចជាច្រើនទៀត។
ដូចដែលអ្នកអាចមើលឃើញនៅក្នុងរូបភាពខាងលើ ចំណុចក្លែងបន្លំមានច្រើន។ តាមវិធីនេះ អ្នកប្រើប្រាស់ pipeline (តេស្ត CI នៅក្នុងឧទាហរណ៍របស់យើង) ត្រូវតែវាយតម្លៃ ភាពសុចរិតនៃដំណើរការសាងសង់ ក៏ដូចជា ភាពសុចរិតនៃវត្ថុបុរាណខ្លួនឯង.
នៅក្នុងឧទាហរណ៍របស់យើង វត្ថុបុរាណដែលមានជាតិពុលត្រូវបានបង្កើតឡើងដោយការណែនាំថ្មី (ដែលមានជាតិពុល) pipeline ដែលរំខានដល់ដំណើរការសាងសង់។ ប៉ុន្តែអ្នកប្រើប្រាស់ដែលមានគំនិតអាក្រក់អាច៖
- កែប្រែលេខកូដបន្ទាប់ពីត្រូវបានពិនិត្យចេញពី SCM ដើម្បីបង្កើតប្រព័ន្ធគោលពីរព្យាបាទ
- ជំនួសប្រព័ន្ធគោលពីរត្រឹមត្រូវដែលបង្កើតឡើងដោយការចងក្រងជាមួយនឹងប្រព័ន្ធគោលពីរព្យាបាទផ្សេងទៀត
- ធ្វើឱ្យខូច Artifact Registry ហើយផ្ទុកឡើងនូវ Artifact ដែលមានជាតិពុលដែលបង្កើតឡើងតាមរបៀបផ្សេងទៀត
- ល
ដូចដែលអ្នកអាចឃើញអាចមានចំណុច "ក្លែងបន្លំ" ជាច្រើន។
តើអ្វីជារឿងសំខាន់នៅទីនេះ? ជាក់ស្តែង ដើម្បីការពារចំណុច «ក្លែងបន្លំ» ទាំងអស់នោះ។ ប៉ុន្តែនៅទីបញ្ចប់ អ្វីដែលសំខាន់បំផុតនោះគឺ ថា «អ្នកប្រើប្រាស់» នៃវត្ថុបុរាណអាចវាយតម្លៃភាពសុចរិតនៃវត្ថុបុរាណ ហើយសម្រេចចិត្តថាតើត្រូវបន្តជាមួយវាឬអត់។
យើងអាច វាយតម្លៃភាពសុចរិតនៃវត្ថុបុរាណ តាមពីរវិធី។
មួយគឺដោយការវាយតម្លៃលើ ប្រភពដើម នៃវត្ថុបុរាណ។
ដោយបង្កើតជា ការបញ្ជាក់ពីប្រភពដើមយើងផ្តល់ទិន្នន័យមេតាមានប្រយោជន៍ (មានការផ្ទៀងផ្ទាត់ត្រឹមត្រូវ និងមិនបដិសេធ) អំពីវត្ថុបុរាណនេះ។ នៅក្នុងឧទាហរណ៍ខាងក្រោម យើងនឹងប្រើ អំបិលស៊ីជីនី (ស្រទាប់បញ្ជាក់កម្មវិធីសម្រាប់ការទុកចិត្ត) ដែលជាសមាសភាគសម្រាប់បង្កើត ចុះឈ្មោះ និងផ្ទៀងផ្ទាត់ការបញ្ជាក់កម្មវិធី។
- 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 ប្រើប្រាស់កូនសោឯកជន ហើយក៏រួមបញ្ចូលកូនសោសាធារណៈនៅក្នុងការបញ្ជាក់ផងដែរ។
នៅពីក្រោយឆាក, Xygeni's អំបិល ពាក្យបញ្ជារក្សាទុកការបញ្ជាក់នៅក្នុង សៀវភៅ (ហៅម្យ៉ាងទៀតថា ការចុះបញ្ជីបញ្ជាក់ រេគរ ក្នុងករណីរបស់យើង ប៉ុន្តែអ្នកអាចប្រើអ្វីផ្សេងទៀតបាន)។ ធ្វើដូច្នោះហើយ អ្នកប្រើប្រាស់ 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 វាគ្រាន់តែជាចំណុចក្លែងបន្លំមួយដែលត្រូវពិនិត្យ ប៉ុន្តែដូចដែលបានរៀបរាប់ខាងលើ មានចំណុចក្លែងបន្លំមួយចំនួនទៀតដែលយើងគួរពិនិត្យ។
ឧទាហរណ៍, ចុះបើកូដប្រភពត្រូវបានកែប្រែបន្ទាប់ពីការត្រួតពិនិត្យ repo និងមុនពាក្យបញ្ជា build? ក្នុងករណីនេះ កូដដែលត្រូវបង្កើតមិនដូចគ្នានឹងកូដដែលរក្សាទុកក្នុង 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 នៅក្នុងប្រកាសប្លក់បន្ថែមទៀត។
