- गिटहब अॅक्शन्स सीक्रेट हे एन्क्रिप्टेड, स्कोप्ड एन्व्हायर्नमेंट व्हेरिअबल्स आहेत जे रिपॉझिटरी, एन्व्हायर्नमेंट आणि ऑर्गनायझेशन लेव्हलवर काळजीपूर्वक स्कोप केले पाहिजेत.
- सुरक्षा ही कमीत कमी विशेषाधिकारांवर अवलंबून असते, लॉग एक्सपोजर टाळणे, गुपिते फिरवणे आणि ऑडिट करणे आणि संवेदनशील उत्पादन वातावरण वेगळे करणे.
- स्क्रिप्ट इंजेक्शन, थर्ड-पार्टी अॅक्शन आणि सेल्फ-होस्टेड रनर्स यांच्या जोखमींसाठी पिनिंग, कोड रिव्ह्यू आणि कठोर रनर आणि परवानगी धोरणे आवश्यक आहेत.
- ओपनआयडी कनेक्ट आणि बाह्य गुप्त व्यवस्थापक दीर्घकालीन क्रेडेन्शियल्सना अल्पकालीन टोकन आणि केंद्रीकृत, ऑडिट करण्यायोग्य गुप्त कार्यप्रवाहांनी बदलण्यास मदत करतात.
गिटहब अॅक्शन्समध्ये गुपिते व्यवस्थापित करणे हा अशा विषयांपैकी एक आहे जो पहिल्या दृष्टीक्षेपात सोपा वाटतो, परंतु जेव्हा तुमच्या पाइपलाइन उत्पादन, क्लाउड प्रदाते आणि तृतीय-पक्ष सेवांना स्पर्श करू लागतात तेव्हा तो लवकरच एक गंभीर सुरक्षा चिंतेमध्ये बदलतो. तुमचे CI/CD वर्कफ्लो नियमितपणे API की, डेटाबेस पासवर्ड, SSH की, टोकन आणि बरेच काही हाताळतात आणि जर निष्काळजीपणे हाताळले गेले तर त्या प्रत्येक मूल्यामुळे आक्रमणकर्त्यासाठी संभाव्य प्रवेश बिंदू बनतो.
या मार्गदर्शकामध्ये आपण GitHub Actions मध्ये गुप्त गोष्टी कशा काम करतात, त्यांना रिपॉझिटरी, पर्यावरण आणि संघटना पातळीवर कसे कॉन्फिगर करायचे, गळती आणि पुरवठा साखळी हल्ल्यांपासून वर्कफ्लो कसे कडक करायचे आणि बाह्य गुप्त व्यवस्थापकांना कधी आणणे अर्थपूर्ण आहे याबद्दल सखोल माहिती घेऊ. तुमच्या पाइपलाइन जलद ठेवण्यासाठी तुम्हाला एक व्यावहारिक, सुरक्षिततेवर केंद्रित आढावा देणे हा यामागील हेतू आहे. आणि दैनंदिन काम डोकेदुखीमध्ये न बदलता सुरक्षित.
गिटहब अॅक्शन्सची गुपिते नेमकी काय आहेत?
गिटहब अॅक्शन्समध्ये, "गुप्त" हा एक एन्क्रिप्टेड एन्व्हायर्नमेंट व्हेरिएबल आहे ज्याचे मूल्य UI, लॉग आणि रिपॉझिटरी कंटेंटपासून लपलेले असते. तुम्ही ते एकदा परिभाषित करा (रेपो, ऑर्ग किंवा पर्यावरण पातळीवर), आणि नंतर तुमच्या वर्कफ्लो YAML मध्ये ते वापरून संदर्भित करा secrets. संदर्भ, जेणेकरून तुमच्या पाइपलाइन कोडबेसमध्ये कधीही न टाकता संवेदनशील मूल्ये वापरू शकतील.
गुपित माहितीमध्ये, GitHub मजबूत क्रिप्टोग्राफी (लिब्सोडियम सीलबंद बॉक्स) वापरून गुप्त माहिती GitHub च्या सर्व्हरवर येण्यापूर्वीच एन्क्रिप्ट करते आणि व्हॅल्यूज फक्त वर्कफ्लो रनरवर रनटाइमवर डिक्रिप्ट केल्या जातात. एकदा तयार झाल्यानंतर, गुपिते UI मधून अपरिवर्तनीय असतात: तुम्ही ती ओव्हरराईट करू शकता पण परत वाचू शकत नाही, आणि जेव्हा ती लॉगमध्ये दिसतात तेव्हा ती आपोआप मास्क केली जातात. *** जेथे जेथे शक्य असेल.
या मॉडेलमध्ये काही महत्त्वाच्या डिझाइन अडचणी आहेत ज्यांची तुम्हाला जाणीव असणे आवश्यक आहे: गुपिते UI किंवा API द्वारे मिळवता येत नाहीत, ती लॉगमधून लपवली जातात आणि ती एका विशिष्ट व्याप्तीमध्ये राहतात: भांडार, भांडारातील वातावरण किंवा संघटना. योग्य व्याप्ती निवडणे हा एका सुज्ञ गुप्त रणनीतीसाठी पहिला मोठा निर्णय आहे.
भांडार, पर्यावरण आणि संस्थेची गुपिते
गिटहब गुपित्यांसाठी तीन मुख्य स्तर ऑफर करते: रिपॉझिटरी गुपिते, पर्यावरण गुपिते आणि संघटना गुपिते, प्रत्येकाचे स्वतःचे वापर प्रकरणे आणि प्राधान्य नियम आहेत. ते कसे संवाद साधतात हे समजून घेतल्याने तुम्हाला संघर्ष टाळण्यास आणि संवेदनशील मूल्ये जिथे आहेत तिथे ठेवण्यास मदत होते.
रिपॉझिटरी-स्तरीय गुपिते
रिपॉझिटरी सीक्रेट एकाच रिपोशी जोडलेले असतात आणि त्या रिपॉझिटरीमधील सर्व वर्कफ्लोसाठी उपलब्ध असतात. ते प्रोजेक्ट-विशिष्ट मूल्यांसाठी परिपूर्ण आहेत जसे की सेवेची API की, डिप्लॉयमेंट पासवर्ड किंवा फक्त त्या रेपोद्वारे वापरले जाणारे वेबहूक टोकन.
UI मधून रिपॉझिटरी सीक्रेट तयार करण्यासाठी, तुम्ही टार्गेट रेपोवर जा, “सेटिंग्ज” → “सिक्रेट अँड व्हेरिएबल्स” → “अॅक्शन्स” उघडा आणि नंतर “नवीन रिपॉझिटरी सीक्रेट” वर क्लिक करा. तुम्ही त्याला अंडरस्कोअरसह एक मोठे नाव द्या (उदाहरणार्थ PAYMENTS_API_KEY), गुप्त मूल्य पेस्ट करा आणि जतन करा; त्या क्षणापासून, वर्कफ्लो त्यात प्रवेश करू शकतात ${{ secrets.PAYMENTS_API_KEY }}.
रेपोमध्ये लिहिण्याचा अधिकार असलेले प्रत्येकजण वर्कफ्लोमध्ये या गुपितेचा संदर्भ घेऊ शकतो, त्यामुळे रिपॉझिटरीवरील परवानग्या तुमच्या सुरक्षा कथेचा भाग बनतात. जर तुम्ही अनेक वापरकर्त्यांना सहजतेने लेखन प्रवेश दिला तर तुम्ही त्यांना ऑटोमेशनमध्ये प्रत्येक रिपॉझिटरी सीक्रेट वापरण्याची अप्रत्यक्ष परवानगी देत आहात.
पर्यावरण-विशिष्ट रहस्ये
पर्यावरण रहस्ये रिपॉझिटरी रहस्यांपेक्षा एक पातळी खाली असतात आणि तुम्हाला प्रत्येक पर्यावरणासाठी वेगवेगळी मूल्ये परिभाषित करण्याची परवानगी देतात जसे की dev, stagingकिंवा production. ते एका नामांकित वातावरणाशी जोडलेले असतात आणि आवश्यक पुनरावलोकनकर्त्यांसारख्या नियमांसह किंवा त्यांच्या विरुद्ध काम सुरू होण्यापूर्वी वेटिंग टाइमरसह त्यांचे संरक्षण केले जाऊ शकते.
तुम्ही "सेटिंग्ज" → "पर्यावरण" वर जाऊन, वातावरण तयार करून किंवा निवडून आणि नंतर त्या वातावरण कॉन्फिगरेशनमध्ये गुपिते जोडून हे कॉन्फिगर करता. गुप्त नावे अजूनही वापरतात secrets. संदर्भ (उदाहरणार्थ secrets.PROD_DB_PASSWORD), परंतु मूल्ये फक्त त्या वातावरणात स्पष्टपणे चालणाऱ्या नोकऱ्यांसाठी उपलब्ध होतात.
एक महत्त्वाचा तपशील असा आहे की जेव्हा पर्यावरणीय रहस्ये समान नावाची असतात तेव्हा ते रिपॉझिटरी रहस्यांना ओव्हरराइड करतात. म्हणजे तुम्ही परिभाषित करू शकता DB_PASSWORD स्थानिक/चाचणी वापरासाठी रेपो स्तरावर आणि नंतर वेगळे DB_PASSWORD उत्पादनासाठी पर्यावरणीय गुपित म्हणून जे उत्पादन कार्यांमध्ये प्राधान्य घेते, वर्कफ्लो सिंटॅक्स न बदलता.
वातावरण "आवश्यक पुनरावलोकनकर्ते" किंवा "केवळ विशिष्ट शाखांमधून" सारखे संरक्षण नियम देखील सक्षम करते, जे तुमच्या सर्वात संवेदनशील गुपिते मिळविण्यासाठी रेलिंग लावण्यासाठी अविश्वसनीयपणे उपयुक्त आहे. उदाहरणार्थ, उत्पादन वातावरणात त्याच्या गुपिते वापरून कोणतेही काम सुरू करण्यापूर्वी DevOps कडून मंजुरी आवश्यक असू शकते.
संघटनेची गुपिते
संस्थेतील गुपिते एका संस्थेतील अनेक रिपॉझिटरीजमध्ये शेअर केली जातात आणि शेअर्ड स्लॅक वेबहूक किंवा सेंट्रल मेट्रिक्स एपीआय टोकन सारख्या व्यापकपणे पुन्हा वापरल्या जाणाऱ्या क्रेडेन्शियल्ससाठी आदर्श असतात. ते डुप्लिकेशन कमी करतात आणि रोटेशन सोपे करतात कारण तुम्ही एकदा सिक्रेट अपडेट करता आणि सर्व वापरणारे रेपो नवीन मूल्य घेतात.
अॅडमिन ते संस्थेच्या “सेटिंग्ज” → “गुप्ते आणि चल” → “कृती” विभागात तयार करतात, “नवीन संघटना गुप्त” वर क्लिक करतात आणि नंतर कोणते रिपॉझिटरीज त्या गुप्ततेत प्रवेश करू शकतात ते निवडतात. तुम्ही सर्व वर्तमान आणि भविष्यातील रिपोजना परवानगी देऊ शकता किंवा ते एका विशिष्ट उपसमूहापुरते मर्यादित करू शकता.
एक प्राधान्य साखळी आहे जी तुम्ही लक्षात ठेवली पाहिजे: organization secret repository secret < environment secret when names collection. दुसऱ्या शब्दांत सांगायचे तर, पर्यावरण गुपित रिपॉझिटरी गुपितावर विजय मिळवते, जे सर्व समान की सामायिक केल्यास संस्थेच्या गुपितावर विजय मिळवते.
रनटाइममध्ये सीक्रेट कसे वागतात
एकदा परिभाषित झाल्यानंतर, रनटाइम दरम्यान नोकऱ्यांसाठी गुपिते उपलब्ध होतात secrets संदर्भित केल्यावर ते पर्यावरण चल म्हणून इंजेक्ट केले जातात. ते डीफॉल्टनुसार प्रत्येक टप्प्यावर मोठ्या प्रमाणात निर्यात केले जात नाहीत; तुम्ही त्यांना तुमच्या env: गुपिते इनपुट म्हणून समर्थन देणाऱ्या कृतींमध्ये त्यांना ब्लॉक करते किंवा पाठवते.
GitHub देखील एक विशेष प्रदान करते GITHUB_TOKEN प्रति वर्कफ्लो रन, जे मॅन्युअली परिभाषित केलेले गुपित नाही परंतु ते त्यासारखे वागते आणि बहुतेकदा API कॉल किंवा रिपॉझिटरी ऑपरेशन्ससाठी वापरले जाते. तुम्ही या टोकनच्या सूक्ष्म परवानग्या वापरून ट्यून करू शकता (आणि करायला हव्यात) permissions: ब्लॉक करा जेणेकरून प्रत्येक कामासाठी आवश्यक असलेली किमान व्याप्ती असेल.
अपघाती एक्सपोजर कमी करण्यासाठी, GitHub वर्कफ्लो लॉगमध्ये नोंदणीकृत गुप्ततेशी जुळणारे कोणतेही मूल्य लपवते, ते बदलते ***. हे मास्किंग रनर साईडवर केले जाते आणि ते सामान्यतः रॉ स्ट्रिंगसाठी चांगले काम करते, परंतु ते गृहीत धरते की आउटपुटमध्ये अचूक गुप्त मूल्य दिसते. जर तुम्ही गुप्त रूपांतरित केले (उदाहरणार्थ base64-एनकोड केले किंवा स्ट्रक्चर्ड JSON मध्ये एम्बेड केले), तर मास्क ते पकडण्यात अयशस्वी होऊ शकतो.
मास्किंग हा सर्वोत्तम प्रयत्न आहे आणि गणितीयदृष्ट्या हमी दिलेली नाही, म्हणून तुम्ही लॉगवर गुपिते किंवा त्यांचे डेरिव्हेटिव्ह्ज छापणे अजिबात टाळण्यासाठी वर्कफ्लो डिझाइन केले पाहिजेत आणि रनटाइमवर तुम्ही निर्माण केलेल्या अतिरिक्त मूल्यांसाठी मास्किंग कमांड वापरा. तुमच्या अपेक्षेपेक्षा जास्त लोकांना दिसणारे लॉग समजा आणि छापलेले काहीही लीक होऊ शकते असे गृहीत धरा.
व्यावहारिक उपयोग: वर्कफ्लोमध्ये गुपिते संदर्भित करणे
बहुतेक वेळा तुम्ही विशिष्ट पायरी किंवा कामात पर्यावरण चलांमध्ये त्यांचे मॅपिंग करून आणि नंतर तुमच्या स्क्रिप्ट्स किंवा टूल्सना वातावरणातून वाचू देऊन रहस्ये वापरता. क्लासिक नमुना असा दिसतो:
- नाव: API वर तैनात करा
env:
API_KEY: ${{ secrets.PROD_API_KEY }}
धावणे: |
कर्ल -H “अधिकृतता: वाहक $API_KEY” https://api.example.com/deploy
तुम्ही रनरवरील फाइलवर एक गुपित देखील लिहू शकता, जोपर्यंत फाइल कामाच्या तात्पुरत्या कार्यक्षेत्रात राहते आणि ती वचनबद्ध किंवा आर्टिफॅक्ट म्हणून अपलोड केलेली नाही तोपर्यंत ती सुरक्षित असते. उदाहरणार्थ, SSH की साठवणे:
- नाव: फाईलमध्ये SSH की लिहा.
शेल: बॅश
env:
SSH_KEY: ${{ गुपिते.SSH_KEY }}
धावणे: |
"$SSH_KEY" > की एको करा
chmod 600 की
लॉगमधून तुम्हाला फक्त प्रत्यक्ष शेल कमांड दिसेल (यासह $SSH_KEY), परंतु गुप्त मूल्य नाही, जे संपादित केले जाईल किंवा लपवले जाईल. काम पूर्ण झाल्यानंतर GitHub-होस्टेड रनर्स नष्ट होतात, त्यामुळे ती तात्पुरती फाइल VM सह गायब होते; सेल्फ-होस्टेड रनर्सवर तुम्हाला साफसफाईबाबत अधिक कठोर असले पाहिजे.
GitHub अॅक्शन्समधील गुपिते सुरक्षित ठेवण्यासाठी सर्वोत्तम पद्धती
फक्त सिक्रेट्स UI वापरणे पुरेसे नाही; जर काही चूक झाली तर ब्लास्ट रेडियस कमी करण्यासाठी तुम्हाला सवयी आणि सुरक्षा उपायांचा एक संच आवश्यक आहे. गिटहब अनेक नॉब्स प्रदान करते, परंतु त्यांना योग्यरित्या चालू करणे तुमच्यावर अवलंबून आहे.
किमान विशेषाधिकाराचे तत्व लागू करा
प्रत्येक गुपित आणि प्रत्येक टोकनने फक्त त्या परवानग्या दिल्या पाहिजेत ज्या दिलेल्या कामासाठी पूर्णपणे आवश्यक आहेत. बाह्य सेवांसाठी, पूर्ण-प्रशासक की पुन्हा वापरण्याऐवजी, व्याप्ती परवानग्यांसह समर्पित क्रेडेन्शियल्स तयार करा (उदाहरणार्थ "केवळ तैनात करा" किंवा "केवळ वाचनीय मेट्रिक्स").
हेच तत्व बिल्ट-इनला लागू होते GITHUB_TOKEN; डीफॉल्ट परवानग्या किमान सेट करा (बहुतेकदा contents: read) आणि नंतर ज्या विशिष्ट कामांची जास्त गरज आहे अशा कामांसाठीच परवानग्या वाढवा. तुम्ही हे एका सह कॉन्फिगर करता permissions: कामाच्या पातळीवर किंवा कामाच्या पातळीवर विभाग जेणेकरून धोक्यात आलेले काम शांतपणे मनमानी लेखन करू शकणार नाही.
लॉगमध्ये गुपिते प्रिंट करणे किंवा एन्कोड करणे टाळा.
डीबगिंगच्या सोयीसाठी गुपिते कधीही वर्कफ्लो फाइल्समध्ये हार्डकोड करू नयेत किंवा साध्या मजकुरात छापू नयेत. जर तुमच्याकडे इतर संवेदनशील मूल्ये असतील जी GitHub secrets म्हणून नोंदणीकृत नसतील (उदाहरणार्थ, रनटाइमवर जनरेट केलेले टोकन), तरीही तुम्ही रनरला कमांड सिंटॅक्स वापरून त्यांना secrets म्हणून हाताळण्यास सांगू शकता:
"::add-mask::$GENERATED_TOKEN" प्रतिध्वनी करा
JSON, XML किंवा मोठे YAML दस्तऐवज यांसारखे संरचित ब्लॉब विशेषतः गुप्ततेसाठी धोकादायक असतात कारण GitHub चा मास्कर अचूक स्ट्रिंग जुळणीवर अवलंबून असतो. जर तुम्ही एका मोठ्या JSON स्ट्रिंगमध्ये अनेक संवेदनशील मूल्ये ठेवली आणि ती एकाच गुपित म्हणून वापरली, तर थोडेसे स्वरूपन बदल मास्किंग अयशस्वी होऊ शकतात; त्याऐवजी, प्रत्येक नाजूक फील्डसाठी वैयक्तिक गुपित परिभाषित करा.
वर्कफ्लोची चाचणी करताना नेहमी लॉगचे पुनरावलोकन करा, त्रुटी संदेश आणि स्टॅक ट्रेसकडे विशेष लक्ष द्या. काही टूल्स stderr ला कमांड आणि फ्लॅग्ज आनंदाने प्रतिध्वनी करतात, ज्यामध्ये चुकून गुप्त मूल्ये समाविष्ट होऊ शकतात जर तुम्ही तो पॅटर्न स्पष्टपणे टाळला नाही तर.
गुपिते नियमितपणे फिरवा आणि ऑडिट करा
गुप्त रोटेशन करणे कंटाळवाणे आहे परंतु जर तुम्हाला सुरक्षेची काळजी असेल तर त्यावर चर्चा करता येणार नाही; वर्षानुवर्षे क्रेडेन्शियल्स अपरिवर्तित ठेवल्याने हल्लेखोरांसाठी संधीची संधी वाढते. एक वाजवी आधाररेखा म्हणजे तुमचे सर्वात महत्त्वाचे उत्पादन गुपिते दर महिन्याला, उच्च-जोखीम असलेले गुपिते दर दोन महिन्यांनी आणि इतर सर्व काही किमान तिमाहीत बदलणे.
तुम्ही याचा काही भाग सिक्रेट्ससाठी GitHub REST API वापरून स्वयंचलित करू शकता, जे तुम्हाला रिपॉझिटरी किंवा संस्थेची सार्वजनिक की मिळवू देते आणि नवीन एन्क्रिप्टेड मूल्ये अपलोड करू देते. हे विशेषतः मोठ्या संस्थांसाठी उपयुक्त आहे ज्यांच्याकडे सेवा खाती सामायिक करणारे अनेक रिपो आहेत आणि घटनांच्या प्रतिसादात त्यांना जलद गतीने बदलण्याची आवश्यकता आहे.
ऑडिटिंग देखील तितकेच महत्त्वाचे आहे: कॉन्फिगर केलेल्या गुपितांच्या यादीचे वेळोवेळी पुनरावलोकन करा आणि जे आता वापरले जात नाहीत ते हटवा आणि गिटहबच्या सुरक्षा/ऑडिट लॉगचा वापर करून अशा घटनांचा मागोवा घ्या. org.update_actions_secret. अशा प्रकारे तुम्हाला कळेल की कोणी काय आणि केव्हा बदलले आणि तुम्ही संशयास्पद बदलांना इतर क्रियाकलापांशी जोडू शकता.
पर्यावरण-आधारित पृथक्करण वापरा
पर्यावरणीय रहस्ये तुमच्या पाइपलाइन मजबूत करण्याचा सर्वात सोपा मार्ग आहेत, कारण ते तुम्हाला स्पष्ट मंजुरींमागे अत्यंत संवेदनशील मूल्ये (जसे की उत्पादन डेटाबेस क्रेडेन्शियल्स) वेगळे करण्याची परवानगी देतात. तुम्ही मानवी पुनरावलोकनकर्त्यांची आवश्यकता घेऊ शकता, कोणत्या शाखा तैनात करायच्या हे मर्यादित करू शकता आणि तैनाती सुरू होण्यापूर्वी कूलिंग-ऑफ टायमर देखील जोडू शकता.
एक सामान्य नमुना म्हणजे staging सौम्य संरक्षणासह वातावरण आणि production कडक नियम आणि वेगळी गुपिते असलेले वातावरण. त्यानंतर वर्कफ्लो प्रत्येक वातावरणाला लक्ष्य करणाऱ्या नोकऱ्या परिभाषित करतात, हे सुनिश्चित करतात की चाचणी जॉबमध्ये प्रोड सीक्रेट कधीही चुकून वापरले जाणार नाहीत.
स्पष्ट नामकरण पद्धती निवडा
गुपित्यांसाठी चांगली नावे ठेवल्याने तुम्हाला निराशाजनक अंदाज आणि धोकादायक गोंधळांपासून वाचवता येते. सामान्य नावांऐवजी जसे की API_KEY, उदाहरणार्थ, नावात सेवा आणि वातावरण एन्कोड करा STRIPE_PROD_API_KEY or AWS_STAGING_DEPLOY_ROLE_ARN.
अनेक सेवा हाताळणारे संघ अनेकदा असा नमुना स्वीकारतात जसे की <SERVICE>_<ENV>_<PURPOSE>. तर तुमच्याकडे कदाचित SLACK_PROD_ALERTS_WEBHOOK, GCP_DEV_BUILD_SERVICE_ACCOUNTआणि DB_STAGING_PASSWORD. यामुळे कोणत्या कामात कोणते गुपित वापरावे हे अधिक स्पष्ट होते.
स्क्रिप्ट इंजेक्शन आणि तृतीय-पक्षाच्या जोखमींपासून संरक्षण करणे
चुकीच्या कॉन्फिगरेशनमुळे गुपिते केवळ धोक्यात येत नाहीत; तर ते वर्कफ्लोमध्ये स्क्रिप्ट इंजेक्शन आणि दुर्भावनापूर्ण किंवा तडजोड केलेल्या तृतीय-पक्ष कृतींसाठी देखील आकर्षक लक्ष्य आहेत. जर तुम्ही काळजी घेतली नाही तर एक असुरक्षित पाऊल कामात उपलब्ध असलेले प्रत्येक गुपित उघड करू शकते.
इनलाइन चरणांमध्ये स्क्रिप्ट इंजेक्शन कमी करणे
जेव्हा तुम्ही अविश्वसनीय डेटा (जसे की पुल रिक्वेस्ट टायटल, ब्रँचची नावे किंवा इश्यू टिप्पण्या) थेट शेल स्क्रिप्टमध्ये इंटरपोलेट करता, तेव्हा तुम्ही इंजेक्शनचा दरवाजा उघडता. उदाहरणार्थ, तुमच्या रनरमध्ये कमांडमधून बाहेर पडून अनियंत्रित शेल कोड चालविण्यासाठी पीआर शीर्षक तयार केले जाऊ शकते.
सर्वात सुरक्षित दृष्टिकोन म्हणजे फर्स्ट-पार्टी किंवा चांगल्या प्रकारे ऑडिट केलेल्या जावास्क्रिप्ट/टाइपस्क्रिप्ट कृतींमध्ये जटिल तर्कशास्त्र हाताळणे आणि अविश्वसनीय मूल्ये शेलमध्ये इनलाइन करण्याऐवजी इनपुट म्हणून पास करणे. त्या मॉडेलमध्ये, कृती स्ट्रिंग्सना आर्ग्युमेंट्स म्हणून प्राप्त करते आणि हायजॅक करता येणाऱ्या शेल स्क्रिप्ट्स निर्माण न करता त्यांच्यावर प्रक्रिया करते.
जर तुम्हाला इनलाइन शेल वापरायचे असेल, तर प्रथम अविश्वसनीय मूल्ये पर्यावरण व्हेरिएबल्समध्ये साठवा आणि नंतर त्या व्हेरिएबल्सचा संदर्भ द्या, शक्यतो डबल कोट्समध्ये. अशाप्रकारे मूल्य स्क्रिप्ट स्ट्रक्चरचा भाग म्हणून न मानता डेटा म्हणून मानले जाते, ज्यामुळे इंजेक्शन प्रयत्न यशस्वी होण्याची शक्यता खूपच कमी होते.
तृतीय-पक्ष कृती पिन करा आणि त्यांचे पुनरावलोकन करा
तुमच्या वर्कफ्लोमध्ये तुम्ही आणलेली प्रत्येक तृतीय-पक्षाची कृती नोकरीच्या वातावरणात आणि गुपितेमध्ये प्रवेशासह चालते, म्हणून तुम्ही त्यांना कोड अवलंबित्वे म्हणून मानले पाहिजे ज्यांची तपासणी आवश्यक आहे. एखादी दुर्भावनापूर्ण किंवा धोक्यात आलेली कृती गुपिते वाचू शकते आणि ती एकाच HTTP कॉलद्वारे आक्रमणकर्त्याला पाठवू शकते.
टॅग्ज किंवा ब्रँचऐवजी पूर्ण कमिट SHA द्वारे कृती पिन करणे हा सर्वोत्तम मार्ग आहे, कारण टॅग्ज हलवले किंवा ओव्हरराईट केले जाऊ शकतात. SHA म्हणजे कोडची अचूक आवृत्ती, ज्यामुळे हल्लेखोराला वर्कफ्लो अपडेट न करता नवीन वर्तन शांतपणे इंजेक्ट करणे खूप कठीण होते.
एखादी कृती वापरण्यापूर्वी, तिचा सोर्स कोड (किंवा किमान सुरक्षा पुनरावलोकन) स्किम करा जेणेकरून ते गुपिते जबाबदारीने हाताळते आणि ती लॉग करत नाही किंवा अज्ञात एंडपॉइंट्सवर पाठवत नाही याची खात्री करा. जर तुम्ही मार्केटप्लेस अॅक्शन्स वापरत असाल, तर शक्य असेल तिथे प्रकाशकाची पडताळणी करा आणि भेद्यता आणि अपडेट्सबद्दल तुम्हाला सतर्क करण्यासाठी Dependabot वर अवलंबून रहा.
होस्टेड विरुद्ध सेल्फ-होस्टेड धावपटू आणि गुप्त प्रदर्शन
तुमचे वर्कफ्लो कुठे चालतात याचा गुपिते किती सुरक्षितपणे हाताळली जातात यावर मोठा परिणाम होतो. गिटहब-होस्टेड रनर्स आणि सेल्फ-होस्टेड रनर्स वेगळेपणा आणि टिकाव या बाबतीत खूप वेगळ्या पद्धतीने वागतात.
गिटहब-होस्ट केलेले रनर्स प्रत्येक कामासाठी नवीन व्हर्च्युअल मशीन्स तयार करतात, तुमचा वर्कफ्लो चालवतात आणि नंतर त्या नष्ट करतात. हे तुम्हाला प्रत्येक वेळी स्वच्छ वातावरण देते आणि काम पूर्ण झाल्यानंतर कोणत्याही फायली किंवा पर्यावरण चल (डिस्कवर लिहिलेल्या गुपित्यांसह) नष्ट होतात याची खात्री करते.
याउलट, सेल्फ-होस्टेड रनर्स ही तुम्ही व्यवस्थापित करत असलेल्या दीर्घकाळ टिकणाऱ्या मशीन असतात, याचा अर्थ असा की गुप्त गोष्टींमध्ये प्रवेश असलेला कोणताही कोड एकाच कामाच्या आयुष्यापलीकडे त्यांना टिकवून ठेवू शकतो किंवा बाहेर काढू शकतो. सार्वजनिक भांडारांवर, स्वयं-होस्ट केलेले धावणारे विशेषतः धोकादायक असतात कारण अविश्वसनीय योगदानकर्ते पुल रिक्वेस्ट उघडू शकतात ज्यामुळे वर्कफ्लो सुरू होतात.
जर तुम्ही सेल्फ-होस्टेड रनर्स वापरत असाल, तर त्यांना संवेदनशीलता पातळीनुसार वेगळे करा, कोणते रेपो कोणते रनर्स वापरू शकतात ते मर्यादित करा आणि त्या मशीनवर आणखी काय असते याबद्दल घाबरून जा (SSH की, क्लाउड क्रेडेन्शियल्स, अंतर्गत सेवांसाठी नेटवर्क अॅक्सेस इ.). काही संस्था "जस्ट-इन-टाइम" (JIT) सेल्फ-होस्टेड रनर्स वापरतात जे एकाच कामासाठी API द्वारे तयार केले जातात आणि नंतर नष्ट केले जातात, परंतु तरीही तुम्ही खात्री केली पाहिजे की नोकऱ्या त्याच रनरला अनपेक्षितपणे शेअर करणार नाहीत.
दीर्घकालीन क्लाउड सिक्रेट्सऐवजी ओपनआयडी कनेक्ट (ओआयडीसी) वापरणे
गिटहब अॅक्शन्समधील गुप्त स्वच्छतेसाठी मिळालेल्या सर्वात मोठ्या विजयांपैकी एक म्हणजे ओपनआयडी कनेक्टद्वारे दीर्घकालीन क्लाउड अॅक्सेस कीजना अल्पकालीन क्रेडेन्शियल्सने बदलणे. AWS, Azure किंवा GCP की गुप्त म्हणून साठवण्याऐवजी, तुमचे वर्कफ्लो GitHub ला ओळख प्रदाता म्हणून वापरून क्लाउड प्रदात्याकडून तात्पुरते टोकन मागतात.
हा प्रवाह साधारणपणे असा दिसतो: काम GitHub च्या OIDC एंडपॉइंटवरून स्वाक्षरी केलेल्या JWT ची विनंती करते, तुमचा क्लाउड प्रदाता त्या टोकनची पडताळणी करतो आणि अल्पकालीन क्रेडेन्शियल्ससाठी त्याची देवाणघेवाण करतो आणि वर्कफ्लो कामाच्या कालावधीसाठी त्या क्रेडेन्शियल्सचा वापर करतो. गिटहबमध्ये कधीही कोणतेही स्थिर गुपित राहण्याची आवश्यकता नाही.
उदाहरणार्थ, AWS सह तुम्ही एक IAM भूमिका कॉन्फिगर करता जी GitHub OIDC प्रदात्यावर विश्वास ठेवते आणि कोणत्या रिपॉझिटरीज/शाखा ती भूमिका घेऊ शकतात हे मर्यादित करते. मग तुमच्या वर्कफ्लोमध्ये तुम्ही अशी कृती वापरता aws-actions/configure-aws-credentials OIDC परवानग्यांसह, तात्काळ क्रेडेन्शियल्स मिळविण्यासाठी सक्षम.
या दृष्टिकोनाचे अनेक फायदे आहेत: GitHub मध्ये फिरवण्यासाठी काहीही नाही, टोकन आपोआप अल्पकालीन असतात, प्रवेश मर्यादित प्रमाणात असतो आणि तुम्हाला क्लाउड बाजूला प्रत्येक भूमिका गृहीतकाचा मागोवा घेणारे पूर्ण ऑडिट लॉग मिळतात. उच्च-सुरक्षा वातावरणासाठी, समर्थित असल्यास OIDC डीफॉल्ट असावे.
मूळ टूलिंग आणि बाह्य गुप्त व्यवस्थापक
गिटहबचे बिल्ट-इन सीक्रेट्स अनेक परिस्थितींसाठी उत्तम आहेत, परंतु कधीकधी तुम्हाला अधिक मध्यवर्ती, वैशिष्ट्यपूर्ण सीक्रेट्स मॅनेजर हवा असेल जो अनेक प्लॅटफॉर्म आणि वातावरणांना व्यापतो. या उद्देशासाठी गिटहब अॅक्शन्ससोबत हॅशीकॉर्प व्हॉल्ट, इन्फिसिकल किंवा डॉप्लर सारखी साधने वारंवार वापरली जातात.
या सिस्टीम डायनॅमिक सिक्रेट्स (उदाहरणार्थ, अल्पकालीन डेटाबेस वापरकर्ते तयार करणे), प्रगत प्रवेश नियंत्रण धोरणे, तपशीलवार ऑडिट लॉग आणि रोटेशन वर्कफ्लो हाताळू शकतात जे केवळ GitHub ऑफर करत नाही त्यापलीकडे जातात. त्यानंतर GitHub Actions या व्यवस्थापकांना (बहुतेकदा OIDC किंवा इतर प्रमाणीकरण पद्धतीद्वारे) प्रमाणित करतात, रनटाइममध्ये त्यांना आवश्यक असलेली गुपिते मिळवतात आणि रेपोमध्ये दीर्घकालीन क्रेडेन्शियल्स कधीही साठवल्याशिवाय त्यांचा वापर करतात.
बाह्य व्यवस्थापकांकडून गुपिते थेट वर्कफ्लोमध्ये आणण्यासाठी डिझाइन केलेले समुदाय कृती आणि प्लगइन देखील आहेत. त्यांचा वापर करताना, हाच सल्ला लागू होतो: कृतीचा स्रोत तपासा, तो कमिट SHA ला पिन करा आणि बाह्य प्रणालीपर्यंत पोहोचण्यासाठी वापरल्या जाणाऱ्या टोकन किंवा भूमिकेला दिलेले विशेषाधिकार मर्यादित करा.
GitHub Actions मध्ये सुरक्षित गुप्त व्यवस्थापन म्हणजे प्रत्येक गुप्ततेसाठी योग्य व्याप्ती निवडणे, कमीत कमी विशेषाधिकार लागू करणे, योग्य ठिकाणी वातावरण आणि OIDC वापरणे, लॉग आणि तृतीय-पक्ष कृतींना संभाव्य हल्ल्याच्या पृष्ठभाग म्हणून हाताळणे आणि जेव्हा तुमच्या स्केल किंवा अनुपालन आवश्यकतांची आवश्यकता असते तेव्हा बाह्य गुप्त व्यवस्थापकांवर अवलंबून राहणे. त्या पद्धती लागू केल्याने, तुमच्या CI/CD पाइपलाइन लवचिक आणि जलद राहू शकतात आणि त्याच वेळी चुकीच्या ठिकाणी ठेवलेले टोकन किंवा खराब पुनरावलोकन केलेले वर्कफ्लो पूर्णपणे विकसित घटनेत बदलण्याची शक्यता नाटकीयरित्या कमी करते.
