- ગિટહબ એક્શન્સ સિક્રેટ્સ એન્ક્રિપ્ટેડ, સ્કોપ્ડ એન્વાયર્નમેન્ટ વેરીએબલ્સ છે જેને રિપોઝીટરી, એન્વાયર્નમેન્ટ અને ઓર્ગેનાઇઝેશન લેવલ પર કાળજીપૂર્વક સ્કોપ્ડ કરવા જોઈએ.
- સુરક્ષા ઓછામાં ઓછા વિશેષાધિકારો પર આધારિત છે, લોગ એક્સપોઝરને ટાળવું, રહસ્યોને ફેરવવું અને ઓડિટ કરવું, અને સંવેદનશીલ ઉત્પાદન વાતાવરણને અલગ રાખવું.
- સ્ક્રિપ્ટ ઇન્જેક્શન, તૃતીય-પક્ષ ક્રિયાઓ અને સ્વ-હોસ્ટેડ રનર્સથી થતા જોખમો માટે પિનિંગ, કોડ સમીક્ષા અને કડક રનર અને પરવાનગી નીતિઓની જરૂર પડે છે.
- ઓપનઆઈડી કનેક્ટ અને બાહ્ય ગુપ્ત વ્યવસ્થાપકો લાંબા ગાળાના ઓળખપત્રોને ટૂંકા ગાળાના ટોકન્સ અને કેન્દ્રિયકૃત, ઑડિટેબલ ગુપ્ત કાર્યપ્રવાહથી બદલવામાં મદદ કરે છે.
GitHub Actions માં રહસ્યોનું સંચાલન એ એક એવો વિષય છે જે પહેલી નજરે સરળ લાગે છે, પરંતુ જ્યારે તમારી પાઇપલાઇન્સ ઉત્પાદન, ક્લાઉડ પ્રદાતાઓ અને તૃતીય-પક્ષ સેવાઓને સ્પર્શવાનું શરૂ કરે છે ત્યારે તે ઝડપથી એક મહત્વપૂર્ણ સુરક્ષા ચિંતામાં ફેરવાઈ જાય છે. તમારા CI/CD વર્કફ્લો નિયમિતપણે API કી, ડેટાબેઝ પાસવર્ડ, SSH કી, ટોકન્સ અને વધુ સાથે વ્યવહાર કરે છે, અને જો બેદરકારીથી હેન્ડલ કરવામાં આવે તો તે દરેક મૂલ્ય હુમલાખોર માટે સંભવિત પ્રવેશ બિંદુ બની શકે છે.
આ માર્ગદર્શિકામાં આપણે GitHub Actions માં રહસ્યો કેવી રીતે કાર્ય કરે છે, ભંડાર, પર્યાવરણ અને સંગઠન સ્તરે તેમને કેવી રીતે ગોઠવવા, લીક અને સપ્લાય ચેઇન હુમલાઓ સામે વર્કફ્લોને કેવી રીતે સખત બનાવવું, અને બાહ્ય ગુપ્ત સંચાલકોને ક્યારે લાવવા તે અંગે ઊંડાણપૂર્વક ચર્ચા કરીશું. આ વિચાર તમને વ્યવહારુ, સુરક્ષા-કેન્દ્રિત ઝાંખી આપવાનો છે જેથી તમે તમારી પાઇપલાઇન્સને ઝડપી રાખી શકો. અને રોજિંદા કામને માથાનો દુખાવો બનાવ્યા વિના સલામત.
ગિટહબ એક્શનના રહસ્યો ખરેખર શું છે?
GitHub Actions માં, "secret" એ એક એન્ક્રિપ્ટેડ એન્વાયર્નમેન્ટ ચલ છે જેનું મૂલ્ય 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 ની મંજૂરીની જરૂર પડી શકે છે.
સંગઠન-વ્યાપી રહસ્યો
સંગઠનના રહસ્યો એક સંસ્થામાં બહુવિધ ભંડારોમાં શેર કરવામાં આવે છે અને શેર કરેલ સ્લેક વેબહૂક અથવા સેન્ટ્રલ મેટ્રિક્સ API ટોકન જેવા વ્યાપકપણે ફરીથી ઉપયોગમાં લેવાતા ઓળખપત્રો માટે આદર્શ છે. તેઓ ડુપ્લિકેશન ઘટાડે છે અને પરિભ્રમણને સરળ બનાવે છે કારણ કે તમે એકવાર ગુપ્ત અપડેટ કરો છો અને બધા વપરાશકાર રેપો નવી કિંમત મેળવે છે.
એડમિન તેમને સંસ્થાના “સેટિંગ્સ” → “રહસ્યો અને ચલો” → “ક્રિયાઓ” વિભાગમાં બનાવે છે, “નવું સંગઠન રહસ્ય” પર ક્લિક કરે છે અને પછી કયા ભંડારો તે રહસ્યને ઍક્સેસ કરી શકે છે તે પસંદ કરે છે. તમે બધા વર્તમાન અને ભવિષ્યના રિપોઝને મંજૂરી આપી શકો છો અથવા તેને ચોક્કસ સબસેટ સુધી મર્યાદિત કરી શકો છો.
એક પ્રાથમિકતા સાંકળ છે જે તમારે ધ્યાનમાં રાખવી જોઈએ: organization secret repository secret < environment secret when names attack. બીજા શબ્દોમાં કહીએ તો, પર્યાવરણ રહસ્ય ભંડાર રહસ્ય પર વિજય મેળવે છે, જે સંગઠન રહસ્ય પર વિજય મેળવે છે જો તે બધા એક જ ચાવી શેર કરે છે.
રનટાઇમ પર રહસ્યો કેવી રીતે વર્તે છે
એકવાર વ્યાખ્યાયિત થઈ ગયા પછી, રનટાઇમ દરમિયાન નોકરીઓ માટે રહસ્યો ઉપલબ્ધ બને છે secrets સંદર્ભ અને સંદર્ભિત થાય ત્યારે પર્યાવરણ ચલો તરીકે ઇન્જેક્ટ કરવામાં આવે છે. ડિફૉલ્ટ રૂપે, તેઓ દરેક પગલા પર વ્યાપકપણે નિકાસ થતા નથી; તમે તેમને સ્પષ્ટ રીતે તમારામાં વાયર કરો છો env: રહસ્યોને ઇનપુટ તરીકે સમર્થન આપતી ક્રિયાઓમાં અવરોધિત કરો અથવા તેમને પસાર કરો.
GitHub પણ એક ખાસ પ્રદાન કરે છે GITHUB_TOKEN પ્રતિ વર્કફ્લો રન, જે મેન્યુઅલી વ્યાખ્યાયિત ગુપ્ત નથી પરંતુ તે એક જેવું વર્તે છે અને ઘણીવાર API કોલ્સ અથવા રિપોઝીટરી કામગીરી માટે વપરાય છે. તમે આ ટોકનની સૂક્ષ્મ પરવાનગીઓને આનો ઉપયોગ કરીને ટ્યુન કરી શકો છો (અને કરવી જોઈએ) permissions: બ્લોક કરો જેથી તેમાં દરેક કાર્ય માટે જરૂરી ન્યૂનતમ અવકાશ હોય.
આકસ્મિક એક્સપોઝર ઘટાડવા માટે, GitHub વર્કફ્લો લોગમાં રજિસ્ટર્ડ સિક્રેટ સાથે મેળ ખાતી કોઈપણ કિંમતને માસ્ક કરે છે, તેને બદલીને ***. આ માસ્કિંગ રનર સાઇડ પર કરવામાં આવે છે, અને તે સામાન્ય રીતે કાચા સ્ટ્રિંગ્સ માટે સારી રીતે કામ કરે છે, પરંતુ તે ધારે છે કે આઉટપુટમાં ચોક્કસ ગુપ્ત મૂલ્ય દેખાય છે. જો તમે ગુપ્તને રૂપાંતરિત કરો છો (ઉદાહરણ તરીકે base64-એન્કોડ કરો છો અથવા તેને સ્ટ્રક્ચર્ડ JSON માં એમ્બેડ કરો છો), તો માસ્ક તેને પકડવામાં નિષ્ફળ જઈ શકે છે.
માસ્કિંગ એ શ્રેષ્ઠ પ્રયાસ છે અને ગાણિતિક રીતે ગેરંટી આપવામાં આવતી નથી, તેથી તમારે લોગમાં રહસ્યો અથવા તેમના ડેરિવેટિવ્ઝ છાપવાનું ટાળવા માટે વર્કફ્લો ડિઝાઇન કરવા જોઈએ, અને રનટાઇમ પર તમે જનરેટ કરો છો તે વધારાના મૂલ્યો માટે માસ્કિંગ આદેશોનો ઉપયોગ કરવો જોઈએ. લોગને એવી રીતે ગણો કે તમારી અપેક્ષા કરતાં વધુ લોકો તેને જોઈ શકે અને ધારો કે છાપેલું કંઈપણ લીક થઈ શકે છે.
વ્યવહારુ ઉપયોગ: વર્કફ્લોમાં રહસ્યોનો સંદર્ભ આપવો
મોટાભાગે તમે ચોક્કસ પગલા અથવા કાર્યમાં પર્યાવરણ ચલોમાં રહસ્યોનો મેપિંગ કરીને અને પછી તમારા સ્ક્રિપ્ટો અથવા ટૂલ્સને પર્યાવરણમાંથી વાંચવા દઈને રહસ્યોનો ઉપયોગ કરશો. ક્લાસિક પેટર્ન આના જેવો દેખાય છે:
- નામ: API માં જમાવો
env:
API_KEY: ${{ રહસ્યો.PROD_API_KEY }}
દોડો: |
curl -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) અને પછી ફક્ત એવા ચોક્કસ કામોમાં પરવાનગીઓ વધારવી જેને વધુ જરૂર હોય. તમે આને a સાથે ગોઠવો છો permissions: વર્કફ્લો અથવા જોબ લેવલ પર વિભાગ જેથી સમાધાન થયેલ જોબ શાંતિથી મનસ્વી રીતે લખાણ ન કરી શકે.
લોગમાં રહસ્યો છાપવાનું કે એન્કોડ કરવાનું ટાળો
ડીબગીંગની સુવિધા માટે રહસ્યોને ક્યારેય વર્કફ્લો ફાઇલોમાં હાર્ડકોડ કરવા જોઈએ નહીં અથવા સાદા ટેક્સ્ટમાં છાપવા જોઈએ નહીં. જો તમારી પાસે અન્ય સંવેદનશીલ મૂલ્યો છે જે GitHub સિક્રેટ્સ તરીકે નોંધાયેલા નથી (ઉદાહરણ તરીકે, રનટાઇમ પર જનરેટ થયેલ ટોકન), તો પણ તમે રનરને આદેશ વાક્યરચનાનો ઉપયોગ કરીને તેમને સિક્રેટ્સ તરીકે ગણવા માટે કહી શકો છો:
"::add-mask::$GENERATED_TOKEN" ઇકો કરો
JSON, XML અથવા મોટા YAML દસ્તાવેજો જેવા સ્ટ્રક્ચર્ડ બ્લોબ્સ ખાસ કરીને રહસ્યો તરીકે ખતરનાક છે કારણ કે GitHub નું માસ્કર ચોક્કસ સ્ટ્રિંગ મેચિંગ પર આધાર રાખે છે. જો તમે એક મોટી JSON સ્ટ્રિંગમાં બહુવિધ સંવેદનશીલ મૂલ્યો મૂકો છો અને તેનો ઉપયોગ એક જ ગુપ્ત તરીકે કરો છો, તો ફોર્મેટિંગમાં થોડો ફેરફાર માસ્કિંગ નિષ્ફળ બનાવી શકે છે; તેના બદલે, દરેક નાજુક ક્ષેત્ર માટે વ્યક્તિગત રહસ્યો વ્યાખ્યાયિત કરો.
વર્કફ્લોનું પરીક્ષણ કરતી વખતે હંમેશા લોગની સમીક્ષા કરો, ભૂલ સંદેશાઓ અને સ્ટેક ટ્રેસ પર ખાસ ધ્યાન આપો. કેટલાક ટૂલ્સ ખુશીથી stderr માં આદેશો અને ફ્લેગ્સનો ઇકો કરે છે, જેમાં આકસ્મિક રીતે ગુપ્ત મૂલ્યો શામેલ થઈ શકે છે સિવાય કે તમે તે પેટર્નને સ્પષ્ટપણે ટાળો.
ગુપ્ત માહિતી નિયમિતપણે ફેરવો અને તેનું ઑડિટ કરો
ગુપ્ત પરિભ્રમણ કંટાળાજનક છે પરંતુ જો તમે સુરક્ષાની કાળજી રાખો છો તો તે વાટાઘાટો કરી શકાતું નથી; વર્ષો સુધી ઓળખપત્રોને યથાવત રાખવાથી હુમલાખોરો માટે તકની બારી વધે છે. એક વાજબી આધારરેખા એ છે કે તમારા સૌથી મહત્વપૂર્ણ ઉત્પાદન રહસ્યોને માસિક, ઉચ્ચ જોખમવાળા રહસ્યોને દર બે મહિને અને બાકીનું બધું ઓછામાં ઓછું ત્રિમાસિક ગાળામાં ફેરવો.
તમે ગુપ્તતા માટે GitHub REST API નો ઉપયોગ કરીને આનો એક ભાગ સ્વચાલિત કરી શકો છો, જે તમને ભંડાર અથવા સંસ્થાની જાહેર કી મેળવવા અને નવા એન્ક્રિપ્ટેડ મૂલ્યો અપલોડ કરવા દે છે. આ ખાસ કરીને મોટી સંસ્થાઓ માટે ઉપયોગી છે જેમની પાસે ઘણા બધા રિપો છે જે સેવા ખાતાઓ શેર કરે છે અને ઘટનાઓના પ્રતિભાવમાં તેમને ઝડપથી ફેરવવાની જરૂર છે.
ઓડિટિંગ પણ એટલું જ મહત્વપૂર્ણ છે: સમયાંતરે ગોઠવેલા રહસ્યોની સૂચિની સમીક્ષા કરો અને જે હવે ઉપયોગમાં નથી તે કાઢી નાખો, અને GitHub ના સુરક્ષા/ઓડિટ લોગનો ઉપયોગ કરીને ઇવેન્ટ્સને ટ્રેક કરો જેમ કે 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. આનાથી એ સ્પષ્ટ થાય છે કે કયા કામમાં કયા રહસ્યનો ઉપયોગ કરવો જોઈએ.
સ્ક્રિપ્ટ ઇન્જેક્શન અને તૃતીય-પક્ષ જોખમો સામે રક્ષણ
ગુપ્ત માહિતી ફક્ત ખોટી ગોઠવણીથી જ જોખમમાં નથી; તેઓ વર્કફ્લોમાં સ્ક્રિપ્ટ ઇન્જેક્શન અને દૂષિત અથવા ચેડા કરાયેલ તૃતીય-પક્ષ ક્રિયાઓ માટે લલચાવનારા લક્ષ્યો પણ છે. જો તમે સાવચેત ન રહો તો એક સંવેદનશીલ પગલું કામમાં ઉપલબ્ધ દરેક રહસ્યને છીનવી શકે છે.
ઇનલાઇન પગલાંઓમાં સ્ક્રિપ્ટ ઇન્જેક્શન ઘટાડવું
જ્યારે તમે અવિશ્વસનીય ડેટા (જેમ કે પુલ રિક્વેસ્ટ ટાઇટલ, બ્રાન્ચ નામ અથવા ઇશ્યૂ કોમેન્ટ્સ) સીધા શેલ સ્ક્રિપ્ટ્સમાં ઇન્ટરપોલેટ કરો છો, ત્યારે તમે ઇન્જેક્શનનો દરવાજો ખોલો છો. ઉદાહરણ તરીકે, તમારા રનરમાં આદેશ તોડીને મનસ્વી શેલ કોડ ચલાવવા માટે PR શીર્ષક બનાવી શકાય છે.
સૌથી સલામત અભિગમ એ છે કે ફર્સ્ટ-પાર્ટી અથવા સારી રીતે ઓડિટેડ જાવાસ્ક્રિપ્ટ/ટાઇપસ્ક્રિપ્ટ ક્રિયાઓમાં જટિલ તર્કને હેન્ડલ કરવો અને અવિશ્વસનીય મૂલ્યોને શેલમાં ઇનલાઇન કરવાને બદલે ઇનપુટ તરીકે પાસ કરવું. તે મોડેલમાં, ક્રિયા દલીલો તરીકે સ્ટ્રિંગ્સ મેળવે છે અને હાઇજેક કરી શકાય તેવી શેલ સ્ક્રિપ્ટો જનરેટ કર્યા વિના તેમને પ્રક્રિયા કરે છે.
જો તમારે ઇનલાઇન શેલનો ઉપયોગ કરવો જ પડે, તો પહેલા પર્યાવરણ ચલોમાં અવિશ્વસનીય મૂલ્યો સંગ્રહિત કરો અને પછી તે ચલોનો સંદર્ભ આપો, પ્રાધાન્ય ડબલ અવતરણ ચિહ્નોમાં. આ રીતે મૂલ્યને સ્ક્રિપ્ટ સ્ટ્રક્ચરના ભાગ તરીકે ગણવાને બદલે ડેટા તરીકે ગણવામાં આવે છે, જેના કારણે ઇન્જેક્શન પ્રયાસો સફળ થવાની શક્યતા ઘણી ઓછી થઈ જાય છે.
તૃતીય-પક્ષ ક્રિયાઓને પિન કરો અને સમીક્ષા કરો
તમારા વર્કફ્લોમાં તમે જે પણ તૃતીય-પક્ષ ક્રિયા કરો છો તે નોકરીના વાતાવરણ અને રહસ્યોની ઍક્સેસ સાથે ચાલે છે, તેથી તમારે તેમને કોડ ડિપેન્ડન્સી તરીકે ગણવા જોઈએ જેને ચકાસણીની જરૂર હોય છે. દૂષિત અથવા ચેડા કરાયેલી ક્રિયા રહસ્યો વાંચી શકે છે અને એક જ HTTP કોલ દ્વારા હુમલાખોરને મોકલી શકે છે.
શ્રેષ્ઠ પ્રથા એ છે કે ફક્ત ટૅગ્સ અથવા શાખાઓને બદલે સંપૂર્ણ કમિટ SHA દ્વારા ક્રિયાઓ પિન કરવી, કારણ કે ટૅગ્સ ખસેડી અથવા ઓવરરાઇટ કરી શકાય છે. SHA એ કોડના ચોક્કસ સંસ્કરણનો ઉલ્લેખ કરે છે, જેના કારણે હુમલાખોર માટે વર્કફ્લો અપડેટ કર્યા વિના શાંતિથી નવું વર્તન દાખલ કરવાનું ખૂબ મુશ્કેલ બને છે.
કોઈ ક્રિયાનો ઉપયોગ કરતા પહેલા, તેના સ્રોત કોડ (અથવા ઓછામાં ઓછું સુરક્ષા સમીક્ષા) ને સ્કિમ કરો જેથી ખાતરી થાય કે તે રહસ્યોને જવાબદારીપૂર્વક હેન્ડલ કરે છે અને તેમને લોગ કરતું નથી અથવા અજાણ્યા અંતિમ બિંદુઓ પર મોકલતું નથી. જો તમે માર્કેટપ્લેસ ક્રિયાઓનો ઉપયોગ કરો છો, તો શક્ય હોય ત્યાં પ્રકાશકની ચકાસણી કરો અને નબળાઈઓ અને અપડેટ્સ વિશે તમને ચેતવણી આપવા માટે Dependabot પર આધાર રાખો.
હોસ્ટેડ વિરુદ્ધ સ્વ-હોસ્ટેડ દોડવીરો અને ગુપ્ત એક્સપોઝર
તમારા કાર્યપ્રવાહ ક્યાં ચાલે છે તેની ગુપ્ત માહિતી કેટલી સુરક્ષિત રીતે હેન્ડલ કરવામાં આવે છે તેના પર મોટી અસર પડે છે. ગિટહબ-હોસ્ટેડ રનર્સ અને સ્વ-હોસ્ટેડ રનર્સ અલગતા અને દ્રઢતાના સંદર્ભમાં ખૂબ જ અલગ રીતે વર્તે છે.
ગિટહબ-હોસ્ટેડ રનર્સ દરેક કામ માટે નવા વર્ચ્યુઅલ મશીનો બનાવે છે, તમારા વર્કફ્લો ચલાવે છે, અને પછી તેને તોડી નાખે છે. તે તમને દર વખતે સ્વચ્છ વાતાવરણ આપે છે અને ખાતરી કરે છે કે કોઈપણ ફાઇલો અથવા પર્યાવરણ ચલો (ડિસ્ક પર લખેલા રહસ્યો સહિત) કાર્ય પૂર્ણ થયા પછી નાશ પામે છે.
તેનાથી વિપરીત, સ્વ-હોસ્ટેડ દોડવીરો લાંબા સમય સુધી ચાલનારા મશીનો છે જે તમે મેનેજ કરો છો, જેનો અર્થ એ છે કે રહસ્યોની ઍક્સેસ ધરાવતો કોઈપણ કોડ સંભવિત રીતે એક જ નોકરીના જીવનકાળ પછી પણ તેમને ચાલુ રાખી શકે છે અથવા બહાર કાઢી શકે છે. જાહેર ભંડારો પર, સ્વ-હોસ્ટેડ રનર્સ ખાસ કરીને જોખમી હોય છે કારણ કે અવિશ્વસનીય યોગદાનકર્તાઓ પુલ વિનંતીઓ ખોલી શકે છે જે વર્કફ્લોને ટ્રિગર કરે છે.
જો તમે સ્વ-હોસ્ટેડ રનર્સનો ઉપયોગ કરો છો, તો તેમને સંવેદનશીલતા સ્તર અનુસાર અલગ કરો, કયા રેપો કયા રનર્સનો ઉપયોગ કરી શકે છે તે પ્રતિબંધિત કરો, અને તે મશીનો પર બીજું શું રહે છે તે વિશે ગભરાઓ (SSH કી, ક્લાઉડ ઓળખપત્રો, આંતરિક સેવાઓ માટે નેટવર્ક ઍક્સેસ, વગેરે). કેટલીક સંસ્થાઓ "જસ્ટ-ઇન-ટાઇમ" (JIT) સ્વ-હોસ્ટેડ રનર્સનો ઉપયોગ કરે છે જે એક જ કામ માટે API દ્વારા બનાવવામાં આવે છે અને પછી નાશ પામે છે, પરંતુ તેમ છતાં તમારે ખાતરી કરવી જોઈએ કે નોકરીઓ અણધારી રીતે એક જ રનરને શેર ન કરે.
લાંબા ગાળાના ક્લાઉડ સિક્રેટ્સને બદલે OpenID કનેક્ટ (OIDC) નો ઉપયોગ કરવો
GitHub Actions માં ગુપ્ત સ્વચ્છતા માટેની સૌથી મોટી જીતમાંની એક છે OpenID Connect દ્વારા લાંબા ગાળાની ક્લાઉડ એક્સેસ કીને ટૂંકા ગાળાના ઓળખપત્રો સાથે બદલવાની. AWS, Azure અથવા GCP કીને ગુપ્ત તરીકે સંગ્રહિત કરવાને બદલે, તમારા વર્કફ્લો GitHub ને ઓળખ પ્રદાતા તરીકે ઉપયોગ કરીને ક્લાઉડ પ્રદાતા પાસેથી કામચલાઉ ટોકન્સની વિનંતી કરે છે.
આ પ્રવાહ લગભગ આના જેવો દેખાય છે: જોબ GitHub ના OIDC એન્ડપોઇન્ટથી સહી કરેલ JWT ની વિનંતી કરે છે, તમારા ક્લાઉડ પ્રદાતા તે ટોકનને માન્ય કરે છે અને તેને ટૂંકા ગાળાના ઓળખપત્રો માટે બદલી નાખે છે, અને વર્કફ્લો જોબના સમયગાળા માટે તે ઓળખપત્રોનો ઉપયોગ કરે છે. GitHub માં ક્યારેય કોઈ સ્થિર રહસ્ય રહેવાની જરૂર નથી.
ઉદાહરણ તરીકે, AWS સાથે તમે એક IAM ભૂમિકા ગોઠવો છો જે GitHub OIDC પ્રદાતા પર વિશ્વાસ કરે છે અને કયા ભંડારો/શાખાઓ તે ભૂમિકા નિભાવી શકે છે તે પ્રતિબંધિત કરે છે. પછી તમારા વર્કફ્લોમાં તમે આવી ક્રિયાનો ઉપયોગ કરો છો aws-actions/configure-aws-credentials OIDC પરવાનગીઓ સાથે, તરત જ ઓળખપત્રો મેળવવા માટે સક્ષમ.
આ અભિગમના બહુવિધ ફાયદા છે: GitHub ની અંદર ફેરવવા માટે કંઈ નથી, ટોકન્સ આપમેળે અલ્પજીવી હોય છે, ઍક્સેસ મર્યાદિત રીતે મર્યાદિત હોય છે, અને તમને દરેક ભૂમિકા ધારણાને ટ્રેક કરતા ક્લાઉડ બાજુ પર સંપૂર્ણ ઓડિટ લોગ મળે છે. ઉચ્ચ-સુરક્ષા વાતાવરણ માટે, જ્યાં સપોર્ટેડ હોય ત્યાં OIDC ડિફોલ્ટ હોવું જોઈએ.
મૂળ ટૂલિંગ અને બાહ્ય ગુપ્ત સંચાલકો
GitHub ના બિલ્ટ-ઇન સિક્રેટ્સ ઘણા દૃશ્યો માટે ઉત્તમ છે, પરંતુ કોઈક સમયે તમને વધુ કેન્દ્રીય, સુવિધાયુક્ત સિક્રેટ મેનેજરની જરૂર પડી શકે છે જે બહુવિધ પ્લેટફોર્મ અને વાતાવરણને આવરી લે. આ હેતુ માટે GitHub Actions ની સાથે HashiCorp Vault, Infisical અથવા Doppler જેવા ટૂલ્સનો વારંવાર ઉપયોગ થાય છે.
આ સિસ્ટમો ગતિશીલ રહસ્યો (ઉદાહરણ તરીકે, ટૂંકા ગાળાના ડેટાબેઝ વપરાશકર્તાઓનું નિર્માણ), અદ્યતન ઍક્સેસ નિયંત્રણ નીતિઓ, વિગતવાર ઓડિટ લોગ અને રોટેશન વર્કફ્લોને સંભાળી શકે છે જે એકલા GitHub જે ઓફર કરે છે તેનાથી આગળ વધે છે. પછી GitHub Actions આ મેનેજરોને પ્રમાણિત કરે છે (ઘણીવાર OIDC અથવા અન્ય પ્રમાણીકરણ પદ્ધતિ દ્વારા), રનટાઇમ પર તેમને જરૂરી રહસ્યો મેળવે છે, અને રેપોમાં લાંબા ગાળાના ઓળખપત્રો સંગ્રહિત કર્યા વિના તેનો ઉપયોગ કરે છે.
બાહ્ય મેનેજરોના રહસ્યોને સીધા વર્કફ્લોમાં ખેંચવા માટે રચાયેલ સમુદાય ક્રિયાઓ અને પ્લગઇન્સ પણ છે. તેનો ઉપયોગ કરતી વખતે, આ જ સલાહ લાગુ પડે છે: ક્રિયાના સ્ત્રોતની સમીક્ષા કરો, તેને કમિટ SHA સાથે પિન કરો, અને બાહ્ય સિસ્ટમ સુધી પહોંચવા માટે તે જે ટોકન અથવા ભૂમિકાનો ઉપયોગ કરે છે તેને આપવામાં આવેલા વિશેષાધિકારોને મર્યાદિત કરો.
GitHub Actions માં સલામત ગુપ્ત વ્યવસ્થાપનનો અર્થ એ છે કે દરેક ગુપ્ત માટે યોગ્ય અવકાશ પસંદ કરવો, ઓછામાં ઓછા વિશેષાધિકારનો અમલ કરવો, જ્યાં યોગ્ય હોય ત્યાં વાતાવરણ અને OIDC નો ઉપયોગ કરવો, લોગ અને તૃતીય-પક્ષ ક્રિયાઓને સંભવિત હુમલાની સપાટી તરીકે ગણવી, અને જ્યારે તમારા સ્કેલ અથવા પાલનની આવશ્યકતાઓ માંગ કરે ત્યારે બાહ્ય ગુપ્ત સંચાલકો પર આધાર રાખવો. આ પ્રથાઓ અમલમાં મુકવાથી, તમારી CI/CD પાઇપલાઇન્સ લવચીક અને ઝડપી રહી શકે છે, જ્યારે ખોવાયેલા ટોકન અથવા નબળી સમીક્ષા કરાયેલ વર્કફ્લો સંપૂર્ણ વિકસિત ઘટનામાં ફેરવાય તેવી શક્યતાઓને નાટકીય રીતે ઘટાડે છે.
