మా మునుపటి పోస్ట్లో, ప్రత్యక్ష విషప్రయోగాన్ని ఎలా గుర్తించాలో మరియు దాని నుండి ఎలా రక్షించుకోవాలో మనం చూశాము. Pipeline ఎగ్జిక్యూషన్ (D-PPE). ఆ దుర్బలత్వాన్ని ఎలా గుర్తించాలో కూడా మనం చూశాము. క్సైజెని స్కానర్అలాగే కొన్ని రక్షణ యంత్రాంగాలు.
విషప్రయోగం Pipeline అమలు (PPEదాడి చేసేవాడు సవరించగలిగినప్పుడు ) ఉత్పత్తి అవుతుంది pipeline రెండు విధాలుగా తర్కం:
- CI కాన్ఫిగ్ ఫైల్ను సవరించడం ద్వారా ( pipeline) -> ప్రత్యక్ష PPE (D-PPE)
- దీని ద్వారా సూచించబడిన ఫైల్లను సవరించడం ద్వారా pipeline (ఉదాహరణకు: లోపల నుండి సూచించబడిన స్క్రిప్ట్లు) pipeline కాన్ఫిగరేషన్ ఫైల్) -> పరోక్ష PPE (I-PPE)
ఈ పోస్ట్లో, మనం పరోక్ష PPE గురించి లోతుగా పరిశీలిద్దాం. కానీ, దానికి ముందు, మరియు నా మునుపటి పోస్ట్కు అనుబంధంగా, GitHub అమలును ఎలా నిర్వహిస్తుందో ముందుగా చూద్దాం. pipelineమరియు D-PPEకి వ్యతిరేకంగా రక్షణ యంత్రాంగాలు ఏమిటి.
గిట్హబ్ అమలును ఎలా రక్షిస్తుంది pipelinePRల నుండి వస్తున్నాయా?
సవరించిన వాటి అమలుకు సంబంధించి గిట్హబ్ ఎలా పనిచేస్తుంది? pipelines?
సవరించిన pipelines లు పుష్ల నుండి లేదా రావచ్చు Pull Requests (PR). ఒక ప్రధాన ఉత్తమ పద్ధతిగా, రక్షిత బ్రాంచ్కు ఎలాంటి ప్రత్యక్ష “పుష్” చేయకుండా ఉండాలని మరియు ఉపయోగించాలని గట్టిగా సిఫార్సు చేయబడింది. Pull Requests అందించబడిన ఏదైనా కోడ్ను అంగీకరించే ముందు కొంత సమీక్షను అమలు చేయడానికి ఒక యంత్రాంగంగా.
Pull Requests రెండు వేర్వేరు మూలాల నుండి రావచ్చు:
- PRలు వస్తున్నాయి ఫోర్కులు
- PRలు వస్తున్నాయి శాఖలు
PRలు నుండి ఫోర్కులు దీని నుండి రావచ్చు ప్రజా or ప్రైవేట్ సురక్షిత కేంద్రాలు.
మేము PPE (విషపూరితమైన) తో వ్యవహరిస్తున్నాము Pipeline అమలు), మా ముఖ్య ఉద్దేశ్యం ఒక PR యొక్క "ఆమోదం" కాదు, కానీ సవరించిన దానిని అమలు చేయడం. pipeline PR యొక్క అంగీకార/ఆమోద ప్రక్రియ సమయంలో. PPE దాడికి మూలంలో, ఒక "హానికరమైన" మార్పు చేయబడిన దానిని అనుకోకుండా అమలు చేయడం ఉంటుంది. pipeline.
కొన్ని మాటల్లో చెప్పాలంటే, విషపూరితమైన Pipeline Execution (PPE) ఈ క్రింది సందర్భంలో ఉత్పత్తి చేయబడుతుంది దాడి చేసేవాడు సవరించగలడు pipeline తర్కశాస్త్రం.
అక్కడ రెండు ఉన్నాయి వేరియంట్స్:
- ప్రత్యక్ష PPE (డి-పిపిఇ): D-PPE దృష్టాంతంలో, దాడి చేసేవాడు CI కాన్ఫిగ్ ఫైల్ను సవరిస్తాడు రిపోజిటరీలోని అసురక్షిత రిమోట్ బ్రాంచ్కు మార్పును నేరుగా పుష్ చేయడం ద్వారా గానీ, లేదా బ్రాంచ్ లేదా ఫోర్క్ నుండి మార్పుతో కూడిన PRను సమర్పించడం ద్వారా గానీ, వారికి యాక్సెస్ ఉన్న రిపోజిటరీలో ఈ మార్పును చేర్చవచ్చు. CI నుండి pipeline సవరించిన CI కాన్ఫిగరేషన్ ఫైల్లోని ఆదేశాల ద్వారా అమలు నిర్వచించబడుతుంది, బిల్డ్ పూర్తయిన తర్వాత దాడి చేసేవారి హానికరమైన ఆదేశాలు చివరికి బిల్డ్ నోడ్లో అమలు అవుతాయి. pipeline ప్రేరేపించబడింది.
- పరోక్ష PPE (ఐ-పిపిఇ): కొన్ని సందర్భాల్లో, యాక్సెస్ ఉన్న శత్రువుకు D-PPE అవకాశం అందుబాటులో ఉండదు SCM రిపోజిటరీ (ఉదా. pipeline అదే రిపోజిటరీలోని ఒక ప్రత్యేక, రక్షిత బ్రాంచ్ నుండి CI కాన్ఫిగరేషన్ ఫైల్ను పుల్ చేసేలా కాన్ఫిగర్ చేయబడింది). అటువంటి పరిస్థితిలో, విషప్రయోగం చేయడానికి బదులుగా pipeline దాడి చేసేవాడు, సూచించబడిన ఫైళ్ళలోకి హానికరమైన కోడ్ను చొప్పిస్తాడు. pipeline (ఉదాహరణకు: లోపల నుండి సూచించబడిన స్క్రిప్ట్లు) pipeline కాన్ఫిగరేషన్ ఫైల్
రెండు సందర్భాల్లోనూ, GitHub సవరించిన దానిని అమలు చేస్తుంది pipeline మునుపటి సమీక్ష లేదా ఆమోదం అవసరం లేకుండా.
ఫోర్క్ల నుండి PRలు ప్రజా మిగిలిన
గిట్హబ్ ప్రాసెసింగ్ సమయంలో ప్రవర్తనను కాన్ఫిగర్ చేయడానికి అనుమతిస్తుంది పబ్లిక్ రిపోలలోని ఫోర్క్ల నుండి వచ్చే PRలు.
ఫోర్క్ నుండి PR వచ్చినప్పుడు, దానిని అమలు చేయడానికి ముందు GitHub ఎల్లప్పుడూ కొంత స్థాయి “ఆమోదాన్ని” తప్పనిసరి చేస్తుంది. pipeline PRతో అనుబంధించబడిందిఈ స్థాయి ఆమోదం బలహీనమైన ఆమోదం నుండి కఠినమైన ఆమోదం వరకు మారుతూ ఉంటుంది.
At సంస్థ స్థాయి (Org>>Settings>>Actions>>General), మీరు అనేక “ఆమోదం” ఎంపికల నుండి ఎంచుకోవచ్చు:
అత్యంత కఠినమైనది చివరిది (“బయటి సహకారులందరి ఆమోదం అవసరంఎందుకంటే బయటి సహకారుల ఫోర్క్ల నుండి PR వచ్చినప్పుడు GitHub ఎల్లప్పుడూ ఆమోదం కోరుతుంది.
కానీ ఈ కఠినమైన సందర్భంలో కూడా, ఉన్నాయి చదవడానికి మరియు వ్రాయడానికి అనుమతులు ఉన్న సహకారుల మధ్య తేడాలు.
- PR ఒక వ్యక్తి నుండి వచ్చినప్పుడు చదవండి వినియోగదారుడు, అమలు pipeline ఆపబడింది మార్పులకు ఆమోదం లభించే వరకు. ఆమోదం లభిస్తే, అప్పుడు సవరించినవి pipeline అమలు చేయబడుతుంది.
- PR ఒక వ్యక్తి నుండి వచ్చినప్పుడు వ్రాయడానికి వినియోగదారుడు, ఆమోదం అవసరం లేదు మరియు సవరించబడిన pipeline ఎల్లప్పుడూ అమలు చేయబడుతుంది !!
ముగింపుగా, పబ్లిక్ రిపోజిటరీలలోని ఫోర్క్ల నుండి వచ్చే PRలకు PPE నుండి తేలికపాటి రక్షణ ఉంటుంది. బాహ్య (రీడ్) వినియోగదారుల నుండి కొంత రక్షణ ఉంది, కానీ అంతర్గత (రైట్) వినియోగదారులకు సంబంధించి ఏమీ లేదు.
గురించి ప్రైవేట్ రిపోల నుండి ఫోర్క్ల ద్వారా వస్తున్న PRలు?
ఫోర్క్ల నుండి PRలు ప్రైవేట్ మిగిలిన
ఈ సందర్భంలో, గిట్హబ్ కొన్ని ఉపయోగకరమైన కాన్ఫిగరేషన్ సెట్టింగ్లను అందిస్తుంది.
పై సెట్టింగ్లను ఈ క్రింది వాటిలో కాన్ఫిగర్ చేయవచ్చు అవయవ లేదా వద్ద రెపో స్థాయి.
ఎప్పుడు ఏ ఎంపికనూ ఎంచుకోలేదు, గిట్హబ్ ఆమోదం కోరండి మరియు ఇది సవరించిన దానిని అమలు చేయదు pipelineఇది అత్యంత సురక్షితమైన అమరిక!!
మా అత్యంత అసురక్షితమైన కాన్ఫిగరేషన్ ఎప్పుడు "ఫోర్క్ నుండి వర్క్ఫ్లోలను అమలు చేయండి pull request” తనిఖీ చేయబడిందిఈ సందర్భంలో, రీడ్ మరియు రైట్ యూజర్లు ఇద్దరికీ ఒకే విధంగా, గిట్హబ్ సవరించిన దానిని ఆటోమేటిక్గా అమలు చేస్తుంది. pipelineమరియు ఈ పరిస్థితి మరింత తీవ్రంగా ఉండవచ్చు అధ్వాన్నంగా ఒకవేళఫోర్క్ నుండి వర్క్ఫ్లోలకు రైట్ టోకెన్లను పంపండి pull requests"మరియు"ఫోర్క్ నుండి వర్క్ఫ్లోలకు రహస్యాలు మరియు వేరియబుల్స్ పంపండి pull requestsతనిఖీ చేయబడతాయి. స్పష్టంగా సమర్థనీయత ఉంటే తప్ప దీన్ని చేయవద్దు!!
ఉంటే “ఫోర్క్ కోసం ఆమోదం అవసరం pull request పనులకూ"చెక్ చేయబడింది" అని తనిఖీ చేస్తే, పై పరిస్థితి కొంత మెరుగుపడుతుంది: GitHub ఆమోదం కోసం అడుగుతుంది మరియు సవరించిన దానిని అమలు చేయదు. pipeline ఇది రీడ్ యూజర్ కోసం కాదు, కానీ రైట్ యూజర్ కోసం కూడా ఇది ఎగ్జిక్యూట్ అవుతుంది.
ఫోర్కులు కనిపించాయి, మరి వాటి సంగతేంటి? బ్రాంచ్ల నుండి వస్తున్న PRలు?
PRలు నుండి శాఖలు
ఈ పరిస్థితిని కాపాడటానికి మీరు ఆధారపడాలి శాఖ రక్షణ నియమాలు.
రిపో స్థాయిలో, మీరు ఏ బ్రాంచ్ కోసమైనా బ్రాంచ్ ప్రొటెక్షన్ రూల్స్ను సృష్టించవచ్చు. ఈ రూల్స్ కొన్నింటిని జోడిస్తాయి. రక్షిత శాఖల సవరణకు పరిమితులు.
మీరు ఒక నియమాన్ని కాన్ఫిగర్ చేసినప్పటికీ “అవసరం a pull request విలీనం చేయడానికి ముందు"మరియు"ఆమోదాలు అవసరం" సవరించిన pipeline PR సృష్టించిన వెంటనే స్వయంచాలకంగా అమలు చేయబడుతుందిఈ “ఆమోదం” విలీన చర్యకు మాత్రమే వర్తిస్తుంది.
పరోక్ష విషప్రయోగం గురించి ఏమిటి? Pipeline అమలు
మనం పైన చూసినట్లుగా, D-PPEని ఉపయోగించడం ద్వారా తగ్గించవచ్చు పుల్_రిక్వెస్ట్_టార్గెట్, కానీ అది I-PPEకి వర్తించదు.
మీరు pull_request_targetను ఉపయోగిస్తే, డిఫాల్ట్ చెకౌట్ బేస్ కోడ్ అవుతుంది. కానీ మీరు కంట్రిబ్యూట్ చేయబడిన కోడ్ (PR కోడ్)పై కొన్ని చెక్లను ధృవీకరించాలనుకుంటే, మీరు PR కోడ్ను స్పష్టంగా చెకౌట్ చేయాలి. అందువల్ల, PR కోడ్ ద్వారా పిలవబడే ఏదైనా షెల్ స్క్రిప్ట్ను సవరించినట్లయితే... pipeline, “ఆధారం” (సురక్షితమైన) pipeline “సవరించిన” షెల్ స్క్రిప్ట్ను అమలు చేస్తుంది → పరోక్ష PPE!!
దీనికి పరిష్కారం కొంచెం క్లిష్టమైనది (pull_request_target లాంటి తక్షణ పరిష్కారం ఏదీ లేదు).
మా pipeline మనం pull_request_targetను ఉపయోగిస్తున్నందున ఇప్పుడు D-PPEకి సురక్షితంగా ఉంది. కానీ ఇది ఇప్పటికీ I-PPEకి గురయ్యే అవకాశం ఉంది.
మన టెస్ట్ ఉదాహరణలో, బిల్డ్ చేయడానికి మనం ప్రాథమికంగా PR కోడ్ను చెక్అవుట్ చేయాలి, కానీ టెస్ట్లు బిల్డ్ ద్వారా జనరేట్ చేయబడిన ఆర్టిఫ్యాక్ట్పై ఎగ్జిక్యూట్ చేయబడతాయి.
సో .. రెండు కోడ్బేస్లను ఎందుకు పరిశీలించకూడదు?
- PR కోడ్ను పరిశీలించండి, ఎందుకంటే మనం నిర్మించి, పరీక్షించాలనుకుంటున్నది అందించబడిన కోడ్ అదే.
- అసలు వెర్షన్ను అమలు చేయడానికి బేస్ కోడ్ను తనిఖీ చేయండి pipeline మరియు బిల్డ్/టెస్ట్ స్క్రిప్ట్లు
ఇది ఈ విధంగా చేయబడవచ్చు ఆ కోడ్బేస్లను వేర్వేరు ఫోల్డర్లకు పంపడంబేస్ కోడ్ను రూట్ ఫోల్డర్కు, మరియు PRను వేరొక ఫోల్డర్కు చెక్ అవుట్ చేయవచ్చు. ఈ సందర్భంలో, కొత్త ఫోల్డర్లో ఉంచిన కోడ్పై మనం రూట్ ఫోల్డర్ నుండి బిల్డ్ మరియు టెస్ట్ స్క్రిప్ట్ను అమలు చేస్తాము.
ఇది సులభమైన పరిష్కారమే, నిజమే!! కానీ, నేర్చుకోవడం కోసం నేను ఒక ఆసక్తికరమైన రూపాంతరాన్ని పరిచయం చేయాలనుకుంటున్నాను (...)
గ్యాలరీలు వర్క్ఫ్లో_రన్ ట్రిగ్గర్ ఈవెంట్
ఇదికాకుండా పుల్_రిక్వెస్ట్_టార్గెట్, గిట్హబ్ మరొక ట్రిగ్గర్ ఈవెంట్ను అందిస్తుంది: వర్క్ఫ్లో_రన్ఈ ఈవెంట్ అనుమతిస్తుంది ఒక అమలు pipeline మరొకదానికి అలవాటుపడింది pipelineఅతని ఉరిశిక్ష.
వర్క్ఫ్లో_రన్ మరియు పుల్_రిక్వెస్ట్_టార్గెట్ ట్రిగ్గర్లు ఒక విషయంలో ఒకేలా ఉంటాయి: రెండూ ప్రివిలేజ్డ్ మోడ్లో అమలు చేయబడతాయి మరియు, PR మార్పులు ఉన్నప్పటికీ, బేస్ pipeline అమలు చేయబడుతుంది !!
మన ప్రస్తుతాన్ని చూద్దాం pipeline:
నిర్మాణ విభాగం D-PPEకి సురక్షితంగా ఉంది, కానీ పరీక్షా విభాగం ఇప్పటికీ I-PPEకి గురయ్యే అవకాశం ఉంది.
మా pipeline దీని కారణంగా D-PPE స్వయంగా సురక్షితం పుల్_రిక్వెస్ట్_టార్గెట్ ట్రిగ్గర్. కానీ బాహ్య షెల్ స్క్రిప్ట్ను పిలవడం వల్ల టెస్ట్ స్టెప్ ఇప్పటికీ I-PPEకి గురయ్యే అవకాశం ఉంది.
I-PPEని నివారించడం
పైన పేర్కొన్న వాటి ఉద్దేశ్యం pipeline అందించిన కోడ్ను రూపొందించి, PPEకి సురక్షితంగా ఉండేలా పరీక్షించడం.
సో .. ఎందుకు విభజించకూడదు pipeline రెండుగానా? ఒకటి నిర్మించడానికి, మరొకటి పరీక్షించడానికి..
- దిమ్మెం pipeline (CIని నిర్మించండి) అవుతుంది PR కోడ్ను తనిఖీ చేయండి (దాన్ని నిర్మించడానికి), బిల్డ్ చేసి, ఒక ఆర్టిఫ్యాక్ట్ను జనరేట్ చేయండి.
- 2వ pipeline (టెస్ట్ CI) అవుతుంది బేస్ కోడ్ను చెక్అవుట్ చేయండి (షెల్ స్క్రిప్ట్ సవరణను నివారించడానికి) మరియు ఆర్టిఫ్యాక్ట్పై అసలు స్క్రిప్ట్లను అమలు చేయండి.
- టెస్ట్ CIని సమకాలీకరించడానికి pipeline బిల్డ్ CI తర్వాత అమలు చేయడానికి pipeline, మేము ఉపయోగిస్తాము వర్క్ఫ్లో_రన్ ట్రిగ్గర్.
ఈ విధంగా:
- pipeline CIని నిర్మించండి is సురక్షితంగా రెండింటికి డి-పిపిఇ (వలన పుల్_రిక్వెస్ట్_టార్గెట్) మరియు ఐ-పిపిఇ (ఎందుకంటే అది ఇకపై షెల్ స్క్రిప్ట్ను అమలు చేయదు).
- pipeline టెస్ట్ CI కూడా ఉంది సురక్షితంగా రెండింటికి డి-పిపిఇ (వలన వర్క్ఫ్లో_రన్) మరియు ఐ-పిపిఇ (ఎందుకంటే ఇది అసలైన షెల్ స్క్రిప్ట్ను పొందడానికి బేస్ కోడ్ను చెక్అవుట్ చేస్తుంది)
రెండింటి కోడ్ను చూద్దాం pipelineఈ సవరణల ప్రకారం…
1st pipeline (CIని నిర్మించండి):
2nd pipeline (CIని పరీక్షించండి):
వావ్... మంచి పరిష్కారం!! కానీ... మనం సురక్షితమేనా? నాకు భయంగా ఉంది, లేదనుకుంటా 😭
నిజానికి, మేము ఒక కొత్త లోపాన్ని కనుగొన్నాము!! అదేమిటి? ఇదే మా తదుపరి పోస్ట్ యొక్క అంశం 🙂 … వేచి ఉండండి!!
PS: క్షమించండి, నేను మౌనంగా ఉండలేను 🤐 ..మీరు విన్నారా? కళాఖండ విషప్రయోగం ? 😂
