Git-ലെ രഹസ്യങ്ങൾ: ഫയൽ ഡിലീറ്റ് ചെയ്യുന്നത് എന്തുകൊണ്ട് പരിഹാരമാകുന്നില്ല

ഈ ആഴ്ച ഒരാൾ എന്നോട് വിരസമായ ഒരു ചോദ്യം ചോദിച്ചു: "ആ പ്രൊഡക്ഷൻ കോൺഫിഗ് ഫയൽ എവിടെയാണ്?" ഇരുപത് മിനിറ്റിനുശേഷം ഞാൻ കണ്ടത് ഒരു Git റെപ്പോസിറ്ററിയിലുള്ള ലൈവ് ആയ ഒരു ക്ലൗഡ് ആക്സസ് കീ ആണ്, ടീമിലെ എല്ലാവർക്കും ഇത് ക്ലോൺ ചെയ്തിട്ടുള്ള ഏതൊരാൾക്കും ഇത് വായിക്കാൻ കഴിയുമായിരുന്നു.

ഇന്ന് 2026 സെപ്റ്റംബർ 29 ആണ്, വളരെ കാലികമായ ഒരു കാരണം കൊണ്ട് ഇത് വീണ്ടും സംഭവിക്കുന്നു. നിലവിലുള്ള ഉൽപ്പന്നങ്ങളിൽ AI ഫീച്ചറുകൾ വേഗത്തിൽ ഉൾപ്പെടുത്താൻ ടീമുകൾ ശ്രമിക്കുന്നു, ഓരോ പുതിയ സംയോജനവും മറ്റൊരു കീ കൊണ്ടുവരുന്നു: ഒരു മോഡൽ API കീ, ഒരു ക്ലൗഡ് സർവീസ് അക്കൗണ്ട്, ഒരു സ്റ്റോറേജ് ക്രെഡൻഷ്യൽ. ഈ കീകൾ എവിടെയെങ്കിലും സൂക്ഷിക്കേണ്ടതുണ്ട്, എളുപ്പവഴി ആപ്ലിക്കേഷന്റെ കോൺഫിഗ് ഫയൽ ആണ്. ആ ഫയൽ ഇതിനകം Git ട്രാക്ക് ചെയ്യുന്നുണ്ടെങ്കിൽ, ആരെങ്കിലും കമ്മിറ്റ് ചെയ്യുന്ന നിമിഷം രഹസ്യം പരസ്യമാകും.

ഈ പോസ്റ്റിന്റെ ലക്ഷ്യം "രഹസ്യങ്ങൾ കമ്മിറ്റ് ചെയ്യരുത്" എന്ന് പറയലല്ല. എല്ലാവർക്കും അതറിയാം. ഒരെണ്ണം കണ്ടെത്തുമ്പോൾ എന്തുചെയ്യണം എന്നതാണ് ലക്ഷ്യം, കാരണം ഇതിനോട് ആദ്യം തോന്നുന്ന സ്വാഭാവിക പ്രതികരണം തെറ്റാണ്.

അതൊരു വിരസമായ ചോദ്യത്തിൽ നിന്നാണ് തുടങ്ങിയത്

ഞാൻ ഒരു .NET ആപ്ലിക്കേഷൻ നോക്കുകയായിരുന്നു. പ്രശ്നമായ കോൺഫിഗ് ഫയൽ ഇതായിരുന്നു appsettings.Production.json, ഒരു .NET ആപ്പ് അതിന്റെ പ്രൊഡക്ഷൻ സജ്ജീകരണങ്ങൾ സൂക്ഷിക്കുന്ന സാധാരണ സ്ഥലമാണിത്. ഏത് പകർപ്പാണ് ആധികാരികം എന്നതായിരുന്നു ചോദ്യം, കാരണം ഫയൽ ഒരേസമയം മൂന്ന് വ്യത്യസ്ത സ്ഥലങ്ങളിൽ നിലവിലുണ്ട്:

• റെപ്പോസിറ്ററിയിലെ സോഴ്സ് ട്രീയിൽ
• ഡിപ്ലോയ് ചെയ്ത പാത്തിൽ, റൺ ചെയ്യുന്ന കണ്ടെയ്നറിനുള്ളിൽ
• ഡാറ്റാബേസ് കണക്ഷൻ സ്ട്രിംഗ് ഇൻജക്റ്റ് ചെയ്യുന്ന ബിൽഡ് പൈപ്പ്‌ലൈൻ വഴി ഡിപ്ലോയ് ചെയ്യുന്ന സമയത്ത് തിരുത്തിയെഴുതപ്പെട്ടത്

അതിൽ മൂന്നാമത്തേത് പ്രധാനമാണ്. കാരണം പൈപ്പ്‌ലൈൻ തിരുത്തിയെഴുതുന്നു ചിലത് ഡിപ്ലോയ് ചെയ്യുമ്പോഴുള്ള മൂല്യങ്ങൾ, അത് എല്ലാം തിരുത്തിയെഴുതുന്നു എന്ന് കരുതുന്നത് എളുപ്പമാണ് എല്ലാം അവയെല്ലാം. എന്നാൽ അങ്ങനെയല്ല. പൈപ്പ്‌ലൈൻ ഇൻജക്റ്റ് ചെയ്യാത്തവയെല്ലാം കമ്മിറ്റ് ചെയ്തത് പോലെ തന്നെ ഉപയോഗിക്കുന്നു.

ഫയൽ ട്രാക്ക് ചെയ്യപ്പെടുന്നുണ്ടോ എന്നതാണ് ആദ്യം പരിശോധിക്കേണ്ടത്

ഇതൊരു വൺ-ലൈൻ പരിശോധനയാണ്, നിങ്ങൾക്ക് ഉറപ്പില്ലാത്ത ഏത് കോൺഫിഗ് ഫയലിലും ഇത് റൺ ചെയ്യാവുന്നതാണ്:

git ls-files --error-unmatch path/to/appsettings.Production.json

ആ കമാൻഡ് വിജയകരമായാൽ, ഫയൽ ട്രാക്ക് ചെയ്യപ്പെടുന്നു, അതായത് അത് റെപ്പോസിറ്ററിയിലും അതിന്റെ ചരിത്രത്തിലുമുണ്ട്. എന്റെ കാര്യത്തിൽ അത് വിജയകരമായി, കൂടാതെ .gitignore കോൺഫിഗ് ഫയലുകൾക്ക് ഒരു റൂളും ഉണ്ടായിരുന്നില്ല.

അതിനകത്ത് ഏകദേശം ഒരു ഡസനോളം രഹസ്യങ്ങൾ ഉണ്ടായിരുന്നു: ഒരു ഡാറ്റാബേസ് കണക്ഷൻ സ്ട്രിംഗ്, നിരവധി പാസ്‌വേഡുകൾ, വെബ് പുഷ് നോട്ടിഫിക്കേഷൻ കീകൾ, ഒരു AI മോഡൽ API കീ, ഒരു ക്ലൗഡ് ആക്സസ് കീ പെയർ എന്നിവ.

എന്തുകൊണ്ടാണ് "നമുക്കത് ഡിലീറ്റ് ചെയ്യാം" എന്നത് ഫലപ്രദമാകാത്തത്

ഇവിടെയാണ് ആളുകളെ അത്ഭുതപ്പെടുത്തുന്ന കാര്യം. ഒരു ഫയലിൽ നിന്ന് ഒരു രഹസ്യം നീക്കം ചെയ്യുന്നതും ആ മാറ്റം കമ്മിറ്റ് ചെയ്യുന്നതും രഹസ്യം നീക്കം ചെയ്യുന്നില്ല.

Git നിലവിലെ അവസ്ഥ മാത്രമല്ല, ഹിസ്റ്ററിയും സൂക്ഷിക്കുന്നു. പഴയ കമ്മിറ്റ് ഇപ്പോഴും നിലവിലുണ്ട്. ആർക്കും റൺ ചെയ്യാം:

git log --oneline -- path/to/appsettings.Production.json
git show <old-commit>:path/to/appsettings.Production.json

ഒറിജിനൽ മൂല്യങ്ങൾ വായിക്കാനും കഴിയും. റെപ്പോസിറ്ററിയുടെ ഓരോ ക്ലോണും ആ മുഴുവൻ ഹിസ്റ്ററിയും വഹിക്കുന്നു. അതിനാൽ കഴിഞ്ഞ വർഷം പ്രോജക്റ്റ് ക്ലോൺ ചെയ്ത ഒരു ഡെവലപ്പറുടെ ലാപ്ടോപ്പിൽ നിങ്ങൾ അത് "നീക്കം" ചെയ്തതിന് ശേഷവും ആ രഹസ്യം ഉണ്ടാകും.

അതിനായി നിർമ്മിച്ച ടൂളുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഹിസ്റ്ററി തിരുത്തിയെഴുതാം, എന്നാൽ ഇതിന് ഒരു ഫോഴ്സ് പുഷ് ആവശ്യമാണ്, ഇത് നിലവിലുള്ള ഓരോ ക്ലോണിനെയും തകർക്കുന്നു, മാത്രമല്ല ആളുകളുടെ കൈവശം ഇതിനകം ഉള്ള പകർപ്പുകളെ ഇത് ബാധിക്കില്ല എന്നതാണ് പ്രധാന കാര്യം. ഹിസ്റ്ററി തിരുത്തിയെഴുതൽ ഒരു ക്ലീനപ്പാണ്. അതൊരു പരിഹാരമല്ല.

ഈ വെളിപ്പെടുത്തൽ ഇല്ലാതാക്കാൻ യഥാർത്ഥത്തിൽ ചെയ്യാൻ കഴിയുന്ന ഒരേയൊരു കാര്യം രഹസ്യം തന്നെ മാറ്റുക എന്നതാണ്.

ആരുടെയൊക്കെ കൈവശം അതുണ്ടെന്ന് കണ്ടെത്തുക

ഇത് എത്രത്തോളം അടിയന്തിരമാണെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ്, അത് കൈവശമുള്ളവരെ കൃത്യമായി എണ്ണുക. ഒരു സാധാരണ ചെറിയ ടീമിൽ ഈ ലിസ്റ്റ് ഒറ്റനോട്ടത്തിൽ തോന്നുന്നതിനേക്കാൾ വലുതായിരിക്കും:

• റെപ്പോസിറ്ററി ആക്സസ് ഉള്ള നിലവിലെ എല്ലാ ഡെവലപ്പർമാരും
• മുമ്പ് ഇത് ക്ലോൺ ചെയ്തിട്ടുള്ള, ഇപ്പോൾ നിങ്ങളുടെ നിയന്ത്രണത്തിലല്ലാത്ത ലാപ്ടോപ്പുകളുള്ള ഓരോ മുൻ ഡെവലപ്പറും അല്ലെങ്കിൽ കോൺട്രാക്റ്ററും
• ബിൽഡ് ഏജന്റ് വർക്കിംഗ് ഡയറക്ടറികളും അവയുടെ കാഷെകളും
• സെർവർ, വെർച്വൽ മെഷീൻ ബാക്കപ്പുകൾ, സ്നാപ്പ്ഷോട്ടുകൾ എന്നിവ
• റെപ്പോസിറ്ററിയുടെ ഏതെങ്കിലും മിറർ

ആ അവസാനത്തെ ഗ്രൂപ്പിനെ മറക്കാൻ എളുപ്പമാണ്. ബാക്കപ്പുകൾ ദീർഘകാലം നിലനിൽക്കുന്ന തരത്തിലാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്, ചോർന്നുപോയ ഒരു ക്രെഡൻഷ്യലിനെ സംബന്ധിച്ചിടത്തോളം അത് തികച്ചും തെറ്റായ ഒരു സവിശേഷതയാണ്.

കീ ഉപയോഗിച്ച് യഥാർത്ഥത്തിൽ എന്തുചെയ്യാൻ കഴിയുമെന്ന് കണ്ടെത്തുക

തീവ്രത ചോർച്ച എന്ന വസ്തുതയെക്കുറിച്ചല്ല. അത് പ്രിവിലേജിനെക്കുറിച്ചാണ്. ഒരു സ്റ്റോറേജ് ബക്കറ്റിനുള്ള റീഡ്-ഓൺലി കീ എന്നത് അഡ്മിനിസ്ട്രേറ്റീവ് കീയിൽ നിന്ന് വളരെ വ്യത്യസ്തമായ ഒരു പ്രശ്നമാണ്.

ഇവിടെ യൂസർ അക്കൗണ്ടിന് ഒരു സ്റ്റോറേജ്-ഓൺലി അക്കൗണ്ട് എന്നപോലെയാണ് പേര് നൽകിയിരുന്നത്. എന്നാൽ അതങ്ങനെയല്ലായിരുന്നു. അതിന്റെ യഥാർത്ഥ പെർമിഷനുകൾ പരിശോധിച്ചപ്പോൾ മറ്റൊരു കഥയാണ് മനസ്സിലായത്:

aws iam list-attached-user-policies --user-name app-s3
aws iam list-user-policies        --user-name app-s3
aws iam list-groups-for-user      --user-name app-s3

അതിന് എല്ലാ ബക്കറ്റുകളിലും പൂർണ്ണ സ്റ്റോറേജ് ആക്സസ് ഉണ്ടായിരുന്നു, പ്രൊഡക്ഷൻ റൺ ചെയ്യുന്ന കമ്പ്യൂട്ട് സർവീസിന്റെ പൂർണ്ണ നിയന്ത്രണം നൽകുന്ന ഒരു ഗ്രൂപ്പിലെ അംഗത്വം, കമ്പനി ഡൊമെയ്ൻ ആയി ഇമെയിൽ അയയ്ക്കാനുള്ള പെർമിഷൻ എന്നിവയുമുണ്ടായിരുന്നു. കുറഞ്ഞ വ്യാപ്തിയെ സൂചിപ്പിക്കുന്ന പേര്, എന്നാൽ അതിന് പിന്നിൽ വിശാലമായ അധികാരം.

അടുത്തതായി, നിങ്ങളുടെ സമയപരിധി തീരുമാനിക്കുന്ന ചോദ്യം:

aws iam get-access-key-last-used --access-key-id AKIAEXAMPLEKEYID

അന്ന് രാവിലെയും അത് ഉപയോഗിച്ചിരുന്നു. അതിനാൽ ആ കീ മറന്നുവെച്ച ഒന്നല്ല. പ്രൊഡക്ഷനിലെ ചിലത് അതിനെ ആശ്രയിച്ചിരുന്നു, അതായത് അത് ഉടനടി ഡിലീറ്റ് ചെയ്യുന്നത് തടസ്സങ്ങൾക്ക് കാരണമാകുമായിരുന്നു.

റൊട്ടേറ്റ് ചെയ്യുക, അല്ലാതെ റദ്ദാക്കുക മാത്രമല്ല വേണ്ടത്

ആ അവസാനത്തെ കാര്യം പ്ലാൻ മാറ്റുന്നു. ഉപയോഗത്തിലുള്ള, ലൈവ് ആയ ഒരു ക്രെഡൻഷ്യലിന് പെട്ടെന്നുള്ള റദ്ദാക്കലല്ല, മറിച്ച് റോളോവർ ആണ് ആവശ്യം. പ്രൊഡക്ഷനെ തടസ്സപ്പെടുത്താതെ സുരക്ഷാ വീഴ്ച പരിഹരിക്കുന്ന ഘട്ടങ്ങൾ താഴെ പറയുന്നവയാണ്.

ഘട്ടം 1: കീ ലൈവ് ആണെന്ന് ഉറപ്പുവരുത്തുക, അതിന്റെ അപകട വ്യാപ്തി കണ്ടെത്തുക

മുകളിൽ പറഞ്ഞിരിക്കുന്ന പെർമിഷനും അവസാനം ഉപയോഗിച്ചതും പരിശോധിക്കുക. കീയ്ക്ക് എന്തുചെയ്യാൻ കഴിയും എന്നതിൽ നിന്ന് അടിയന്തിരാവസ്ഥ തീരുമാനിക്കുക, അതിന്റെ പേരിൽ നിന്നല്ല.

ഘട്ടം 2: ആദ്യത്തേതിനൊപ്പം രണ്ടാമതൊരു കീ സൃഷ്ടിക്കുക

മിക്ക ക്ലൗഡ് പ്രൊവൈഡർമാരും ഒരു യൂസർക്ക് രണ്ട് ആക്റ്റീവ് ആക്സസ് കീകൾ അനുവദിക്കുന്നത് കൃത്യമായി നിങ്ങൾക്ക് സുരക്ഷിതമായി റോളോവർ ചെയ്യാൻ വേണ്ടിയാണ്.

aws iam create-access-key --user-name app-s3

പഴയ കീ ഇതുവരെ മാറ്റരുത്.

ഘട്ടം 3: പുതിയ കീ റെപ്പോസിറ്ററി അല്ലാത്ത മറ്റൊരിടത്ത് സൂക്ഷിക്കുക

നിങ്ങളുടെ പൈപ്പ്‌ലൈൻ ഇതിനകം ഉപയോഗിക്കുന്ന ഏത് സീക്രട്ട് സ്റ്റോറിലേക്കും ഇത് മാറ്റുക. മിക്ക ടീമുകൾക്കും ഇതിനകം ഒന്നുണ്ടാകും, എന്നാൽ അവരത് സ്ഥിരമായി ഉപയോഗിക്കുന്നില്ല എന്നതാണ് സത്യം. ബിൽഡിൽ നിന്ന് അത് റഫറൻസ് ചെയ്യുക, അതിലൂടെ ഡിപ്ലോയ് ചെയ്യുന്ന സമയത്ത് വാല്യൂ ഇൻജക്റ്റ് ചെയ്യപ്പെടുകയും ഒരിക്കലും സോഴ്സിൽ എഴുതപ്പെടാതിരിക്കുകയും ചെയ്യും.

ഘട്ടം 4: ഡിപ്ലോയ് ചെയ്ത് പരിശോധിക്കുക

വീണ്ടും ഡിപ്ലോയ് ചെയ്യുക, തുടർന്ന് കീ ഉപയോഗിച്ചിരുന്ന ഫംഗ്ഷനുകൾ ഇപ്പോഴും പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്തുക. എന്റെ കാര്യത്തിൽ ഔട്ട്ബൗണ്ട് ഇമെയിലും ഫയൽ സ്റ്റോറേജും പരിശോധിക്കുക എന്നതായിരുന്നു അത്. റദ്ദാക്കുന്നതിന് മുമ്പ് പരിശോധിക്കുക, അതിനുശേഷം ഒരിക്കലുമരുത്.

ഘട്ടം 5: പഴയ കീ ഡിആക്ടിവേറ്റ് ചെയ്യുക

ആദ്യം ഡിലീറ്റ് ചെയ്യുന്നതിന് പകരം ഡിആക്ടിവേറ്റ് ചെയ്യുക, കാരണം നിങ്ങൾ ഏതെങ്കിലും കൺസ്യൂമറെ ശ്രദ്ധിക്കാൻ വിട്ടുപോയിട്ടുണ്ടെങ്കിൽ ഡിആക്ടിവേഷൻ ഉടനടി റിവേഴ്സ് ചെയ്യാവുന്നതാണ്.

aws iam update-access-key --user-name app-s3 --access-key-id AKIAEXAMPLEKEYID --status Inactive

ഏതാനും ദിവസത്തേക്ക് പിശകുകൾ വല്ലതുമുണ്ടോയെന്ന് നിരീക്ഷിക്കുക, തുടർന്ന് അത് ഡിലീറ്റ് ചെയ്യുക.

ഘട്ടം 6: ഇപ്പോൾ മാത്രം, റെപ്പോസിറ്ററി ക്ലീൻ ചെയ്യുക

git rm --cached path/to/appsettings.Production.json
echo "appsettings.Production.json" >> .gitignore

ഈ ഘട്ടം മനപ്പൂർവ്വം അവസാനമാണ് വെച്ചിരിക്കുന്നത്. ഇത് അടുത്ത ചോർച്ച തടയുന്നു. ഇത് നിലവിലെ ചോർച്ച പരിഹരിക്കുന്നില്ല.

ഘട്ടം 7: നിങ്ങൾ ഈ ഘട്ടത്തിലായിരിക്കുമ്പോൾ പെർമിഷനുകൾ കർശനമാക്കുക

സ്റ്റോറേജിന് പേരിട്ടിരിക്കുന്ന ഒരു അക്കൗണ്ടിന് നിങ്ങളുടെ പ്രൊഡക്ഷൻ കമ്പ്യൂട്ടിന്റെ നിയന്ത്രണമുണ്ടെങ്കിൽ, അതും പരിഹരിക്കുക. അമിത അധികാരങ്ങളുള്ള ഒരു കീ റൊട്ടേറ്റ് ചെയ്യുന്നത് അമിത അധികാരങ്ങളുള്ള മറ്റൊരു പുതിയ കീ നൽകുക മാത്രമാണ് ചെയ്യുന്നത്.

ഉപസംഹാരം

Git-ൽ ഒരു രഹസ്യം കണ്ടെത്തുമ്പോഴുള്ള സ്വാഭാവിക പ്രവണത അത് ഡിലീറ്റ് ചെയ്ത് സമാധാനിക്കുക എന്നതാണ്. ആ പ്രവണത വൃത്തിയുള്ളതായി തോന്നുന്ന ഒരു റെപ്പോസിറ്ററി നൽകുന്നു, എന്നാൽ അപകടസാധ്യത മാറുന്നില്ല. ഹിസ്റ്ററി ശാശ്വതമാണ്, ക്ലോണുകൾ എല്ലായിടത്തുമുണ്ട്, കാര്യങ്ങൾ എന്നെന്നേക്കുമായി സൂക്ഷിക്കാനാണ് ബാക്കപ്പുകൾ നിർമ്മിച്ചിരിക്കുന്നത്. ക്രെഡൻഷ്യൽ മാറ്റിസ്ഥാപിക്കുക എന്നത് മാത്രമാണ് യഥാർത്ഥത്തിൽ സഹായിക്കുന്ന കാര്യം, കൂടാതെ പ്രൊഡക്ഷൻ തടസ്സപ്പെടാത്ത രീതിയിൽ വേണം ഇത് ചെയ്യാൻ. അത് ലൈവ് ആണോ എന്ന് പരിശോധിക്കുക, അതിന് എന്തുചെയ്യാൻ കഴിയുമെന്ന് അളക്കുക, പുതിയൊരു കീ ഉൾപ്പെടുത്തുക, പരിശോധിക്കുക, തുടർന്ന് പഴയത് ഓഫ് ചെയ്യുക. റെപ്പോസിറ്ററി ക്ലീൻ ചെയ്യുക എന്നതാണ് അവസാന പടി, ആദ്യത്തേതല്ല.

ഗുണങ്ങൾ

• ഡിറ്റക്ഷൻ ചെക്ക് ഒരൊറ്റ കമാൻഡ് ആണ്, ഏത് റെപ്പോസിറ്ററിയിലും ഇത് പ്രവർത്തിക്കുന്നു
• ഫയൽ ഡിലീറ്റ് ചെയ്യുന്നതിൽ നിന്നോ ഹിസ്റ്ററി തിരുത്തിയെഴുതുന്നതിൽ നിന്നോ വ്യത്യസ്തമായി റൊട്ടേഷൻ ഒരു സ്ഥിരമായ പരിഹാരമാണ്
• രണ്ടാമത്തെ കീ ഉപയോഗിച്ചുള്ള റോളോവർ ലൈവ് സിസ്റ്റങ്ങൾക്ക് ഡൗൺടൈം ഉണ്ടാക്കില്ല എന്നാണ് അർത്ഥമാക്കുന്നത്
• റൊട്ടേഷൻ സമയത്ത് പെർമിഷനുകൾ ഓഡിറ്റ് ചെയ്യുന്നത് അമിത അധികാരങ്ങളുള്ള അക്കൗണ്ടുകളെ പലപ്പോഴും വെളിപ്പെടുത്തുന്നു
• രഹസ്യങ്ങൾ നിലവിലുള്ള ഒരു സീക്രട്ട് സ്റ്റോറിലേക്ക് മാറ്റുന്നതിന് സാധാരണയായി പുതിയ ടൂളുകളൊന്നും ആവശ്യമില്ല
• അവസാന ഡിലീറ്റ് ചെയ്യുന്നത് വരെ മുഴുവൻ പ്രക്രിയയും റിവേഴ്സ് ചെയ്യാവുന്നതാണ്

ദോഷങ്ങൾ

• റൊട്ടേഷൻ ചെയ്യുന്നതിന് കീയുടെ ഓരോ കൺസ്യൂമറെയും കണ്ടെത്തേണ്ടതുണ്ട്, ഇത് അപൂർവ്വമായി മാത്രമേ ഡോക്യുമെന്റ് ചെയ്യപ്പെടാറുള്ളൂ
• നിങ്ങൾക്ക് ഒറിജിനൽ വെളിപ്പെടുത്തൽ ഇല്ലാതാക്കാൻ കഴിയില്ല, അതിന്റെ മൂല്യം കുറയ്ക്കാൻ മാത്രമേ കഴിയൂ
• ഹിസ്റ്ററി തിരുത്തിയെഴുതുന്നത് നിലവിലുള്ള ക്ലോണുകളെ തകർക്കുകയും ടീമിന് തടസ്സങ്ങൾ ഉണ്ടാക്കുകയും ചെയ്യുന്നു
• ലാപ്ടോപ്പുകളിലേക്കും ബാക്കപ്പുകളിലേക്കും ഇതിനകം പകർത്തിയ രഹസ്യങ്ങൾ നിങ്ങളുടെ നിയന്ത്രണത്തിന് പുറത്താണ്
• ക്ലീനപ്പ് ഫീച്ചർ വർക്കുകളുടെ സമയവുമായി മത്സരിക്കുന്നു, ഇത് മാറ്റിവെക്കാൻ എളുപ്പമാണ്
• ചില പഴയ സിസ്റ്റങ്ങൾ ക്രെഡൻഷ്യൽ റൊട്ടേഷൻ ശരിക്കും ബുദ്ധിമുട്ടുള്ളതാക്കുന്നു

മുന്നറിയിപ്പ്

ഈ ലേഖനം വിജ്ഞാനപ്രദമാണ് കൂടാതെ നിങ്ങളുടെ സാഹചര്യത്തിന് അനുയോജ്യമായ ഒരു നിർദ്ദേശത്തേക്കാൾ പൊതുവായ ഒരു സമീപനമാണ് ഇത് വിവരിക്കുന്നത്. ഇതിലെ ഓരോ കമാൻഡ്, ഫയൽ പാത്ത്, അക്കൗണ്ട് നെയിം, കീ ഐഡന്റിഫയർ എന്നിവ ഒരു പ്ലേസ്ഹോൾഡർ ആണ്, നിങ്ങളുടെ സ്വന്തം സിസ്റ്റങ്ങളിൽ നിന്നുള്ള മൂല്യങ്ങൾ ഉപയോഗിച്ച് ഇത് മാറ്റിസ്ഥാപിക്കണം. ഏതെങ്കിലും കൺസ്യൂമറെ ശ്രദ്ധിക്കാൻ വിട്ടുപോയിട്ടുണ്ടെങ്കിൽ ക്രെഡൻഷ്യലുകൾ റൊട്ടേറ്റ് ചെയ്യുന്നത് ലൈവ് സർവീസുകളെ തടസ്സപ്പെടുത്തിയേക്കാം, അതിനാൽ ഓരോ ഘട്ടവും ആദ്യം നോൺ-പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിൽ പരിശോധിക്കുക, ഒരു കീ ഡിആക്ടിവേറ്റ് ചെയ്യുന്നതിന് മുമ്പ് അതിനെ ആശ്രയിക്കുന്നതെന്താണെന്ന് ഉറപ്പുവരുത്തുക, ഇവിടെ എഴുതിയിരിക്കുന്ന എന്തിനെയും ആശ്രയിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ ക്ലൗഡ് പ്രൊവൈഡർക്കും ടൂളുകൾക്കുമുള്ള നിലവിലെ ഡോക്യുമെന്റേഷൻ പരിശോധിക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ (FAQ)

• ഒരു Git റെപ്പോസിറ്ററിയിൽ നിന്ന് ഒരു രഹസ്യം ഡിലീറ്റ് ചെയ്യുന്നത് അത് പൂർണ്ണമായി നീക്കം ചെയ്യുമോ? — ഇല്ല. അതിന്റെ വാല്യൂ കമ്മിറ്റ് ഹിസ്റ്ററിയിലും നിലവിലുള്ള ഓരോ ക്ലോണിലും അവശേഷിക്കുന്നു, അതിനാൽ റെപ്പോസിറ്ററി ഉള്ള ആർക്കും അത് വായിക്കാൻ കഴിയും.
• ചോർന്നുപോയ ഒരു രഹസ്യം പരിഹരിക്കാൻ Git ഹിസ്റ്ററി തിരുത്തിയെഴുതുന്നത് മതിയോ? — ഇല്ല. ഇത് റെപ്പോസിറ്ററി ക്ലീൻ ചെയ്യുന്നു, എന്നാൽ ആളുകൾ ഇതിനകം ക്ലോൺ ചെയ്ത പകർപ്പുകളെക്കുറിച്ച് ഒന്നും ചെയ്യുന്നില്ല, അതിനാൽ ക്രെഡൻഷ്യൽ റൊട്ടേറ്റ് ചെയ്യേണ്ടതുണ്ട്.
• ഒരു കോൺഫിഗ് ഫയൽ Git ട്രാക്ക് ചെയ്യുന്നുണ്ടോ എന്ന് ഞാൻ എങ്ങനെ പരിശോധിക്കും? — റൺ ചെയ്യുക git ls-files --error-unmatch <path>. ഇത് വിജയകരമായാൽ, ഫയൽ ട്രാക്ക് ചെയ്യപ്പെടുന്നു കൂടാതെ അതിലെ ഉള്ളടക്കം ഹിസ്റ്ററിയിലുണ്ട്.
• ചോർന്ന ഒരു കീ ഞാൻ ഉടനടി ഡിലീറ്റ് ചെയ്യേണ്ടതുണ്ടോ? — ഇത് ഉപയോഗിക്കാത്തതാണെങ്കിൽ മാത്രം. പ്രൊഡക്ഷനിലെ എന്തെങ്കിലും അതിനെ ആശ്രയിക്കുന്നുണ്ടെങ്കിൽ, ആദ്യം ഒന്നിന് പകരം മറ്റൊന്ന് സൃഷ്ടിക്കുക, ഡിപ്ലോയ് ചെയ്യുക, പരിശോധിക്കുക, തുടർന്ന് പഴയത് ഡിആക്ടിവേറ്റ് ചെയ്യുക.
• ചോർന്ന ഒരു ക്ലൗഡ് കീ ഇപ്പോഴും ഉപയോഗിക്കുന്നുണ്ടോയെന്ന് ഞാൻ എങ്ങനെ അറിയും? — മിക്ക പ്രൊവൈഡർമാരും ആക്സസ് കീകൾക്കായി അവസാനം ഉപയോഗിച്ച സമയത്തിന്റെ സ്റ്റാമ്പ് നൽകുന്നു, ഏതെങ്കിലും കൺസ്യൂമർ ഇപ്പോഴും അതിനെ ആശ്രയിക്കുന്നുണ്ടോ എന്ന് ഇതിൽ നിന്നും മനസ്സിലാക്കാം.
• ആപ്ലിക്കേഷൻ രഹസ്യങ്ങൾ ഇതിനുപകരം എവിടെയായിരിക്കണം? — ഒരു സീക്രട്ട് സ്റ്റോറിലോ നിങ്ങളുടെ ബിൽഡ് സിസ്റ്റത്തിന്റെ ക്രെഡൻഷ്യൽ സ്റ്റോറിലോ, ഡിപ്ലോയ് ചെയ്യുന്ന സമയത്ത് ഇൻജക്റ്റ് ചെയ്യപ്പെടുന്നതിനാൽ സോഴ്സ് കൺട്രോളിൽ വാല്യൂ ഒരിക്കലും വരില്ല.
• ഡിപ്ലോയ്മെന്റ് പൈപ്പ്‌ലൈൻ രഹസ്യത്തെ സംരക്ഷിക്കാത്തത് എന്തുകൊണ്ട്? — ഡാറ്റാബേസ് കണക്ഷൻ സ്ട്രിംഗുകൾ പോലെയുള്ള ചില ക്രമീകരണങ്ങൾ മാത്രമേ പൈപ്പ്‌ലൈനുകൾ മിക്കപ്പോഴും ഇൻജക്റ്റ് ചെയ്യാറുള്ളൂ, മറ്റെല്ലാ വാല്യൂകളും കമ്മിറ്റ് ചെയ്തത് പോലെ തന്നെ നിലനിർത്തുന്നു.
• ഇത് വീണ്ടും സംഭവിക്കുന്നത് എനിക്ക് എങ്ങനെ തടയാം? — ഇതിലേക്ക് കോൺഫിഗ് ഫയലുകൾ ചേർക്കുക .gitignore, നിങ്ങളുടെ റെപ്പോസിറ്ററികളിൽ ഓട്ടോമേറ്റഡ് സീക്രട്ട് സ്കാനിംഗ് പ്രവർത്തനക്ഷമമാക്കുക, കൂടാതെ പെർമിഷനുകൾ അവലോകനം ചെയ്യുക, അതിലൂടെ ചോർന്ന കീകൾക്ക് കഴിയുന്നത്ര കുറഞ്ഞ മൂല്യം മാത്രമേ ഉണ്ടാകൂ.

ടാഗുകൾ

#Security #DevOps #Git #SecretsManagement #CloudSecurity #IAM #KeyRotation #DevSecOps #ConfigManagement #InfrastructureAsCode