ഞങ്ങളുടെ മുൻ പോസ്റ്റിൽ ഇതിനെക്കുറിച്ച് CI/CD Pipelines, ഞങ്ങൾ കണ്ടു എങ്ങനെ ഹാക്ക് ചെയ്യാം CI/CD സാഹചര്യം ഒരുപക്ഷേ സംരക്ഷിക്കപ്പെട്ടു.
മുൻ പോസ്റ്റിലെ നമ്മുടെ പോയിന്റ് ഓർമ്മിക്കാം: ഞങ്ങൾ ചിലതിൽ നിന്നാണ് തുടങ്ങിയത് pipeline അത് ദുർബലമായിരുന്നു പരോക്ഷ വിഷബാധ Pipeline വധശിക്ഷ (I-PPE) കൂടാതെ, അത് പരിഹരിക്കുന്നതിനായി, ഞങ്ങൾ വിഭജിക്കാൻ തീരുമാനിച്ചു pipeline രണ്ടായി:
- ആദ്യത്തേത് pipeline (ബിൽഡ് സിഐ), ഡി-പിപിഇ, ഐ-പിപിഇ എന്നിവയ്ക്ക് സുരക്ഷിതമാണ്, പിആർ കോഡ് പരിശോധിക്കുകയും, ബിൽഡ് നിർമ്മിക്കുകയും, ഒരു ആർട്ടിഫാക്റ്റ് സൃഷ്ടിക്കുകയും ചെയ്യും.
- 2-ാമത് pipeline (ടെസ്റ്റ് CI), D-PPE യ്ക്കും I-PPE യ്ക്കും സുരക്ഷിതമാണ്, ഷെൽ സ്ക്രിപ്റ്റ് മോഡിഫിക്കേഷൻ ഒഴിവാക്കാൻ ബേസ് കോഡ് പരിശോധിക്കുകയും ആർട്ടിഫാക്റ്റിനെതിരെ യഥാർത്ഥ സ്ക്രിപ്റ്റുകൾ എക്സിക്യൂട്ട് ചെയ്യുകയും ചെയ്യും.
- ടെസ്റ്റ് CI സമന്വയിപ്പിക്കുന്നതിന് pipeline ബിൽഡ് CI-ക്ക് ശേഷം പ്രവർത്തിപ്പിക്കാൻ pipeline, ഞങ്ങൾ ഉപയോഗിച്ചു വർക്ക്ഫ്ലോ_റൺ ട്രിഗർ.
ഞങ്ങൾ ഇതിനെ സീനാരിയോ #3 എന്ന് പേരിട്ടു.
ആ പോസ്റ്റിൽ ഞങ്ങൾ സൂചിപ്പിച്ചതുപോലെ, മറ്റ് പരിഹാരങ്ങളുണ്ടെങ്കിലും, വിദ്യാഭ്യാസപരമായ കാരണങ്ങളാൽ ഈ "പരിഹാരം" നടപ്പിലാക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, അതിനാൽ നമുക്ക് ദുർബലതകളെക്കുറിച്ച് ആഴത്തിൽ മനസ്സിലാക്കാൻ കഴിയും. CI/CD pipelines.
പിന്നീട്, ഈ സാഹചര്യം എങ്ങനെ ഹാക്ക് ചെയ്യാമെന്ന് നമ്മൾ കണ്ടു, പുരാവസ്തുവിൽ വിഷം കലർത്തൽ. ഇതിനെയാണ് നമ്മൾ വിളിക്കുന്നത് ആർട്ടിഫാക്റ്റ് വിഷബാധ, അതായത് പരിഷ്കരിക്കാനുള്ള (ഹാക്ക്) കഴിവ് pipeline ഒരു പരിഷ്‌ക്കരണത്തിലൂടെ യുക്തി pipeline പുരാവസ്തു.
ഈ സമീപനത്തിലെ പ്രശ്നം എന്താണ്? ഏതെങ്കിലും ഉപയോക്താവ് ഒരു പുതിയ "സൃഷ്ടിക്കുമ്പോൾ" പ്രശ്നം ഉണ്ടാകുമെന്ന് ഞങ്ങൾ കണ്ടു. pipeline.
ഒരു ഉപയോക്താവ് പുതിയൊരു പിആർ തുറന്നാൽ pipeline, GitHub അത് എക്സിക്യൂട്ട് ചെയ്യും pipeline (ചില വ്യവസ്ഥകൾ നൽകിയാൽ, നമ്മൾ കണ്ടതുപോലെ പോസ്റ്റിൽ).
ഉപയോക്താവിന് പിന്നീട് പുതിയൊരു pipeline ബിൽഡ് സിഐ എന്ന അതേ പേരിൽ!! അതെ, ഇത് ആശ്ചര്യകരമാണ്, പക്ഷേ രണ്ടെണ്ണം സൃഷ്ടിക്കാൻ GitHub നിങ്ങളെ അനുവദിക്കുന്നു pipelineഅതേ പേരിൽ!!
ഈ മാറ്റങ്ങളോടെ ഉപയോക്താവ് ഒരു PR തുറക്കുമ്പോൾ, "പുതിയത്" pipeline നടപ്പിലാക്കും (വിഷം കലർന്ന ഒരു പുരാവസ്തു അപ്‌ലോഡ് ചെയ്യുന്നു) ഡിപ്ലോയ് സി.ഐ.യും pipeline അതിനുശേഷം എക്സിക്യൂട്ട് ചെയ്യപ്പെടും, അതിന്റെ ഫലമായി "പരിഷ്കരിച്ച" ഷെൽ സ്ക്രിപ്റ്റ് "ഒറിജിനൽ" ഷെൽ സ്ക്രിപ്റ്റിനെ ഓവർറൈറ്റ് ചെയ്യും. pipeline ജോലിസ്ഥലം. അതിനാൽ, ഈ "പരിഹാരം" I-PPE ദുർബലത ഒഴിവാക്കുന്നില്ല (താഴെ നമുക്ക് കാണാൻ കഴിയുന്നതുപോലെ)
എന്തൊക്കെയാണ് പ്രശ്നങ്ങൾ? കുറഞ്ഞത്, രണ്ട് പ്രശ്നങ്ങളെങ്കിലും ഉണ്ട്:
- ആദ്യം, നിർമ്മാണ പ്രക്രിയയിൽ കൃത്രിമം നടന്നിട്ടില്ലെന്ന് എങ്ങനെ ഉറപ്പാക്കാം? ഈ സാഹചര്യത്തിൽ, ക്ഷുദ്ര ഉപയോക്താവിന് അവരുടെ pipeline വിഷം കലർന്ന ഒരു പുരാവസ്തു സൃഷ്ടിക്കാൻ.
- രണ്ടാമതായി, ഒരു പുരാവസ്തുവിന്റെ ഉത്ഭവം നമുക്ക് എങ്ങനെ വിലയിരുത്താൻ കഴിയും?
ഈ ചോദ്യങ്ങൾ നമ്മെ കൈകളിലേക്ക് എറിയുന്നു സോഫ്റ്റ്‌വെയർ അറ്റസ്റ്റേഷനുകൾ ഡൊമെയ്ൻ!!
സോഫ്റ്റ്‌വെയർ അറ്റസ്റ്റേഷനുകൾ
An അറ്റസ്റ്റേഷൻ ഒരു കഷണം ആണ് ഡാറ്റ പ്രതിനിധീകരിക്കുന്നു ഒരു സംഭവത്തിന്റെ തെളിവ്. യഥാർത്ഥ ലോകത്ത്, നമ്മൾ സാധാരണയായി ഇവയെ സർട്ടിഫിക്കേഷൻ.
ഉദാഹരണത്തിന്, ഒരു ലാബ് നിങ്ങളുടെ രക്തം പരിശോധിക്കുമ്പോൾ, പരിശോധനയെക്കുറിച്ചുള്ള ഡാറ്റ രേഖപ്പെടുത്തുകയും സാക്ഷ്യപ്പെടുത്തുകയും ചെയ്യുന്നു. രക്തപരിശോധനാ ഫലങ്ങൾ പരിശോധിക്കുക ഒപ്പം കണ്ടെത്താൻ കഴിയും.
നമ്മുടെ ഐടി മേഖലയോട് അടുത്ത്, ഈ പ്രക്രിയയുടെ വിവർത്തനം, ഉദാഹരണത്തിന്, ഒരു സമാഹരണ പ്രക്രിയയിലേക്ക് എന്താണെന്ന് നിങ്ങൾക്ക് ഊഹിക്കാം.
കംപൈലേഷൻ സെർവർ പരിസ്ഥിതി, ഉപകരണങ്ങൾ, മെറ്റീരിയലുകൾ (സോഴ്സ് കോഡ്), ഉൽപ്പന്നങ്ങൾ/ആർട്ടിഫാക്റ്റുകൾ (ബൈനറി കോഡ്) എന്നിവയെക്കുറിച്ചുള്ള വിവരങ്ങൾ അത്തരം സാക്ഷ്യപ്പെടുത്തലിന്റെ ഭാഗമായിരിക്കും.
വ്യക്തമായും, വിശ്വാസ്യത നൽകുന്നതിന് അംഗീകൃത (ആധികാരികവും നിഷേധിക്കാനാവാത്തതുമായ) സാക്ഷ്യപ്പെടുത്തൽ ഒരു അംഗീകൃത അറ്റസ്റ്റർ സൃഷ്ടിക്കണം.
നിങ്ങളിൽ ചിലർ ചിന്തിക്കുന്നുണ്ടാകാം.. എന്താണ് ഒപ്പുകളും സാക്ഷ്യപ്പെടുത്തലുകളും തമ്മിലുള്ള വ്യത്യാസം?
കോഡ് ഒപ്പുകളും സാക്ഷ്യപ്പെടുത്തലുകളും
ഉയർന്ന തലത്തിൽ, ഒരു കയ്യൊപ്പ് ഒരു കീ ജോഡിയും ഒരു ആർട്ടിഫാക്റ്റും ഉപയോഗിച്ചാണ് ഇത് സൃഷ്ടിച്ചിരിക്കുന്നത്. ഒരു പബ്ലിക് കീയും ഒരു പ്രൈവറ്റ് കീയും അടങ്ങുന്നതാണ് കീ ജോഡി.
ഉപയോക്താവ് സ്വകാര്യ കീ ഉപയോഗിച്ച് ഒരു ആർട്ടിഫാക്റ്റിൽ ഒപ്പിടുന്നു, മറ്റുള്ളവർക്ക് പബ്ലിക് കീ ഉപയോഗിച്ച് ഒപ്പ് പരിശോധിക്കാൻ കഴിയും. സ്വകാര്യ കീ രഹസ്യമായി സൂക്ഷിക്കണം, പക്ഷേ പൊതു കീ വ്യാപകമായി വിതരണം ചെയ്യപ്പെടുന്നു.
ഒപ്പുകൾ ഉപയോഗിക്കാം സ്വകാര്യ താക്കോലിന്റെ ഉടമയാണ് ആർട്ടിഫാക്ടിൽ ഒപ്പിടാൻ സ്വകാര്യ താക്കോൽ ഉപയോഗിച്ചതെന്ന് തെളിയിക്കാൻ.
ഒപ്പുകൾ തെളിയിക്കരുത്
- ഉപയോക്താവിന്റെ ഉദ്ദേശം പുരാവസ്തുവിൽ ഒപ്പിടാൻ (അവരെ കബളിപ്പിച്ചിരിക്കാം), അല്ലെങ്കിൽ
- ഉപയോക്താവിന്റെ ഉദ്ദേശ്യം എന്തെങ്കിലും ഉണ്ടാക്കുക എന്നതാണ് പുരാവസ്തുവിനെക്കുറിച്ചുള്ള പ്രത്യേക അവകാശവാദം
കൂടെ അറ്റസ്റ്റേഷനുകൾ, ഒരു പുരാവസ്തു നേരിട്ട് ഒപ്പിടുന്നതിനുപകരം, ഉപയോക്താക്കൾ എന്തെങ്കിലും തരത്തിലുള്ളത് സൃഷ്ടിക്കുന്നു പ്രമാണം ആ അവരുടെ ഉദ്ദേശ്യം പിടിച്ചെടുക്കുന്നു പുരാവസ്തുവിൽ ഒപ്പിടുന്നതിന് പിന്നിലും മറ്റേതെങ്കിലും പ്രത്യേക ക്ലെയിമുകൾ ഈ ഒപ്പിന്റെ ഭാഗമായി നിർമ്മിക്കപ്പെടുന്നു.
ഇൻ-ടോട്ടോ അറ്റസ്റ്റേഷൻ ഫ്രെയിംവർക്ക്
ഏറ്റവും സാധാരണമായ ചട്ടക്കൂട് ആണ് ഇൻ-ടോട്ടോ അറ്റസ്റ്റേഷൻ ഫ്രെയിംവർക്ക്
- a നിർവചിക്കുന്നു standard സാക്ഷ്യപ്പെടുത്തലുകൾക്കുള്ള ഫോർമാറ്റ് വിവരിക്കപ്പെടുന്ന വസ്തുക്കളെ, ആ വസ്തുവിനെക്കുറിച്ചുള്ള ആധികാരിക മെറ്റാഡാറ്റയുമായി ബന്ധിപ്പിക്കുന്ന
- ഒരു സെറ്റ് നൽകുന്നു മുൻകൂട്ടി നിശ്ചയിച്ച പ്രവചനങ്ങൾ സോഫ്റ്റ്‌വെയർ വിതരണ ശൃംഖലകളിലുടനീളവും ഉടനീളവും ആധികാരികമാക്കിയ മെറ്റാഡാറ്റ ആശയവിനിമയം നടത്തുന്നതിന്
അറ്റസ്റ്റേഷൻ ഫോർമാറ്റിനെക്കുറിച്ച് നമുക്ക് കുറച്ച് വിശദമായി നോക്കാം.
An അറ്റസ്റ്റേഷൻ ഒരു ആണ് ഡിജിറ്റൽ ഒപ്പിട്ട പ്രമാണം അതിൽ അടങ്ങിയിരിക്കുന്നു പ്രസ്താവനകൾ.
ദി പ്രസ്താവന അറ്റസ്റ്റേഷന്റെ മധ്യ പാളിയാണ്, അത് ഒരു പ്രത്യേകവുമായി ബന്ധിപ്പിക്കുന്നു വിഷയം കൂടാതെ തരങ്ങൾ വ്യക്തമായി തിരിച്ചറിയുകയും ചെയ്യുന്നു പ്രവചിക്കുക:
- വിഷയം: a പുരാവസ്തുവിന്റെ ക്രിപ്റ്റോഗ്രാഫിക്കലി സുരക്ഷിതമായ റഫറൻസ് (സാധാരണയായി ഒരു ഹാഷ് വഴി), കൂടാതെ
- പ്രവചിക്കുന്നു: നിർദ്ദിഷ്ടമായ ഒരു കൂട്ടം ക്ലെയിമുകൾ ആ ആർട്ടിഫാക്റ്റിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഒരു പ്രസ്താവന എന്ന് വിളിക്കുന്നു. നിങ്ങൾക്ക് ചിന്തിക്കാൻ കഴിയുന്ന എന്തും പ്രകടിപ്പിക്കാനും (പിന്നീട് തെളിയിക്കാനും) ഈ അവകാശവാദങ്ങൾ ഉപയോഗിക്കാം! അവയ്ക്ക് മാനുവൽ അംഗീകാരം, ആർട്ടിഫാക്റ്റ് ഉറവിടം, ഓട്ടോമേറ്റഡ് പരിശോധനാ ഫലങ്ങൾ, ഒരു ഓഡിറ്റ് ട്രയൽ അല്ലെങ്കിൽ അതിലേറെയും പ്രതിനിധീകരിക്കാൻ കഴിയും!
ഈ പ്രസ്താവന ക്രിപ്റ്റോഗ്രാഫിക്കായി ഒപ്പിടുമ്പോൾ, അത് ഒരു എന്ന് വിളിക്കപ്പെടുന്നു അറ്റസ്റ്റേഷൻ
ഈ രീതിയിൽ, ഒരു ഉദാഹരണമായി, ആലീസ് ഒരു പുരാവസ്തുവിനെക്കുറിച്ച് ഒരു പ്രസ്താവന സൃഷ്ടിക്കുകയും അവളുടെ സ്വകാര്യ താക്കോൽ ഉപയോഗിച്ച് അതിൽ ഒപ്പിടുകയും ഒരു അറ്റസ്റ്റേഷൻ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.
- ബോബിന് അപ്പോൾ കഴിയും ഒപ്പ് പരിശോധിക്കുക ആ സാക്ഷ്യപത്രത്തിൽ, അവനെ അനുവദിക്കുന്നു അവകാശവാദങ്ങളിൽ വിശ്വസിക്കാൻ അകത്ത്.
ബോബിന് ആ അവകാശവാദങ്ങൾ ഉപയോഗിക്കാൻ കഴിയും തീരുമാനിക്കാൻ ഈ പുരാവസ്തു ഉപയോഗിക്കാൻ അനുവദിക്കണോ വേണ്ടയോ എന്ന്.
ആർട്ടിഫാക്റ്റ് വിഷബാധ പരിഹരിക്കാൻ അറ്റസ്റ്റേഷനുകൾ സഹായിക്കുമോ?
അറ്റസ്റ്റേഷനുകളുടെ ഈ ആമുഖത്തിനുശേഷം, നമുക്ക് നമ്മുടെ പ്രശ്നത്തിലേക്ക് മടങ്ങാം. നമ്മുടെ പ്രശ്നം പരിഹരിക്കാൻ, അതായത്, പുരാവസ്തു വിഷബാധ ഒഴിവാക്കാൻ, സാക്ഷ്യപ്പെടുത്തലുകൾ എങ്ങനെ സഹായിക്കും?
"ഔദ്യോഗിക" സംവിധാനത്തെ മറികടന്ന്, അതായത് അവന്റെ/അവളുടെ pipeline പുരാവസ്തു സൃഷ്ടിക്കാൻ.
ഡൗൺലോഡ് ചെയ്യുന്ന പുരാവസ്തുക്കൾ ഔദ്യോഗികമായി നിർമ്മിച്ചതാണെന്ന് തെളിയിക്കാൻ കഴിയുമെങ്കിൽ അത് അതിശയകരമായിരിക്കും. pipelines. "ടാമ്പറിംഗ് പോയിന്റുകൾ" എന്ന് നമുക്ക് വിളിക്കാവുന്നതിന്റെ ഒരു ഉദാഹരണം മാത്രമാണിത്, പക്ഷേ മറ്റു പലതും ഉണ്ടാകാം.
മുകളിലുള്ള ചിത്രത്തിൽ നിങ്ങൾക്ക് കാണാൻ കഴിയുന്നതുപോലെ, കൃത്രിമത്വം കാണിക്കുന്ന പോയിന്റുകൾ ഒന്നിലധികം ആണ്. ഈ രീതിയിൽ, ഉപഭോക്താവ് pipeline (ഞങ്ങളുടെ ഉദാഹരണത്തിൽ ടെസ്റ്റ് CI) വിലയിരുത്തണം നിർമ്മാണ പ്രക്രിയയുടെ സമഗ്രത അതുപോലെ തന്നെ പുരാവസ്തുവിന്റെ തന്നെ സമഗ്രത.
നമ്മുടെ ഉദാഹരണത്തിൽ, വിഷം കലർന്ന ഒരു പുരാവസ്തു പുതിയൊരു (വിഷം കലർന്ന) വസ്തുവിനെ അവതരിപ്പിച്ചുകൊണ്ടാണ് സൃഷ്ടിക്കപ്പെട്ടിരിക്കുന്നത്. pipeline അത് ബിൽഡ് പ്രക്രിയയെ തടസ്സപ്പെടുത്തുന്നു. എന്നാൽ ക്ഷുദ്ര ഉപയോക്താവിന് ഇവ ചെയ്യാമായിരുന്നു:
- പരിശോധിച്ച ശേഷം കോഡ് പരിഷ്കരിക്കുക SCM ഒരു ക്ഷുദ്രകരമായ ബൈനറി സൃഷ്ടിക്കാൻ
- കംപൈലേഷൻ വഴി ലഭിക്കുന്ന വലത് ബൈനറി മറ്റേതെങ്കിലും ക്ഷുദ്രകരമായ ബൈനറി ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുക.
- ആർട്ടിഫാക്റ്റ് രജിസ്ട്രിയിൽ വിട്ടുവീഴ്ച ചെയ്ത് മറ്റേതെങ്കിലും രീതിയിൽ നിർമ്മിച്ച വിഷം കലർന്ന ഒരു ആർട്ടിഫാക്റ്റ് അപ്‌ലോഡ് ചെയ്യുക.
- തുടങ്ങിയവ.
നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഒന്നിലധികം "കൈകാര്യം" പോയിന്റുകൾ ഉണ്ടാകാം.
ഇവിടെ എന്താണ് പ്രധാനം? തീർച്ചയായും ആ "കൈകാര്യ" പോയിന്റുകളെല്ലാം സംരക്ഷിക്കുക എന്നതാണ്. പക്ഷേ, ഒടുവിൽ, ഏറ്റവും പ്രധാനപ്പെട്ടത് അതായത്, ഒരു പുരാവസ്തുവിന്റെ "ഉപഭോക്താവിന്" അതിന്റെ സമഗ്രത വിലയിരുത്താനും അതുമായി മുന്നോട്ട് പോകണോ വേണ്ടയോ എന്ന് തീരുമാനിക്കാനും കഴിയും.
നമുക്ക് കഴിയും ഒരു പുരാവസ്തുവിന്റെ സമഗ്രത വിലയിരുത്തുക രണ്ട് തരത്തിൽ.
ഒന്ന്, ഉറവിട പുരാവസ്തുവിന്റെ.
സൃഷ്ടിക്കുന്നതിലൂടെ ഒരു പ്രോവെനൻസ് അറ്റസ്റ്റേഷൻ, ആർട്ടിഫാക്റ്റിനെക്കുറിച്ച് ഉപയോഗപ്രദമായ മെറ്റാഡാറ്റ (ശരിയായി പ്രാമാണീകരിച്ചതും നിരസിക്കാത്തതും) ഞങ്ങൾ നൽകുന്നു. താഴെ പറയുന്ന ഉദാഹരണങ്ങളിൽ, നമ്മൾ ഉപയോഗിക്കും സൈജെനി ഉപ്പ് (സോഫ്റ്റ്‌വെയർ അറ്റസ്റ്റേഷൻസ് ലെയർ ഫോർ ട്രസ്റ്റ്), സോഫ്റ്റ്‌വെയർ അറ്റസ്റ്റേഷനുകൾ സൃഷ്ടിക്കുന്നതിനും രജിസ്റ്റർ ചെയ്യുന്നതിനും പരിശോധിക്കുന്നതിനുമുള്ള ഘടകം.
- 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 സ്വകാര്യ കീ ഉപയോഗിക്കുന്നു, കൂടാതെ സാക്ഷ്യപ്പെടുത്തലിൽ പബ്ലിക് കീയും ഉൾപ്പെടുത്തുന്നു.
പിന്നിൽ, സൈജെനിയുടെ ഉപ്പ് കമാൻഡ് സാക്ഷ്യപ്പെടുത്തൽ a-യിൽ സൂക്ഷിക്കുന്നു ലഡ്ജർ (ഒരു അറ്റസ്റ്റേഷൻ രജിസ്ട്രി എന്നും അറിയപ്പെടുന്നു, റെക്കോർ ഞങ്ങളുടെ കാര്യത്തിൽ, പക്ഷേ നിങ്ങൾക്ക് മറ്റേതെങ്കിലും ഉപയോഗിക്കാം). അത് ചെയ്തു, ഉപഭോക്താവ് pipeline സൈജെനികൾ ഉൾപ്പെടാം പരിശോധനാ എഞ്ചിൻ പുരാവസ്തുവിന്റെ ഉറവിടം പരിശോധിക്കുന്നതിനും പുരാവസ്തുവിന്റെ സമഗ്രത വിലയിരുത്തുന്നതിനും.
- 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 ചെക്ക്ഔട്ടിന് ശേഷവും ബിൽഡ് കമാൻഡിന് മുമ്പും സോഴ്സ് കോഡിൽ കൃത്രിമം നടന്നിട്ടുണ്ടെങ്കിൽ എന്തുചെയ്യും? ഈ സാഹചര്യത്തിൽ, നിർമ്മിക്കേണ്ട കോഡ് സംഭരിച്ചിരിക്കുന്നതുപോലെയല്ല 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 കൂടുതൽ ബ്ലോഗ് പോസ്റ്റുകളിൽ.
