Gitలో సీక్రెట్స్: ఫైల్‌ను తొలగించడం వల్ల సమస్య ఎందుకు పరిష్కారం కాదు

ఈ వారం ఒకరు నన్ను ఒక విసుగు పుట్టించే ప్రశ్న అడిగారు: "ఆ ప్రొడక్షన్ కాన్ఫిగ్ ఫైల్ ఎక్కడ ఉంది?" ఇరవై నిమిషాల తర్వాత నేను Git రిపోజిటరీలో ఉన్న ఒక యాక్టివ్ క్లౌడ్ యాక్సెస్ కీని చూస్తున్నాను, టీమ్‌లోని ప్రతి ఒక్కరూ, దాన్ని క్లోన్ చేసిన ఎవరైనా చదివే విధంగా అది ఉంది.

ఈరోజు సెప్టెంబర్ 29, 2026, ప్రస్తుతం జరుగుతున్న ఒక కారణం వల్ల ఇది పదేపదే జరుగుతోంది. ఉన్న ప్రొడక్ట్‌లకు 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లో సీక్రెట్‌ను చూసినప్పుడు దాన్ని డిలీట్ చేసి, అంతా బాగానే ఉందని అనుకోవడం మన సహజ ప్రవృత్తి. ఆ ప్రవృత్తి క్లీన్‌గా కనిపించే రిపోజిటరీని ఇస్తుంది కానీ ప్రమాదాన్ని అలాగే ఉంచుతుంది. హిస్టరీ శాశ్వతమైనది, క్లోన్‌లు అన్నిచోట్లా ఉంటాయి మరియు బ్యాకప్‌లు ఎప్పటికీ ఉంచడానికి నిర్మించబడతాయి. నిజంగా సహాయపడే ఏకైక విషయం క్రెడెన్షియల్‌ను మార్చడం మరియు ప్రొడక్షన్‌కి అంతరాయం కలిగించని క్రమంలో దాన్ని చేయడం. అది లైవ్‌లో ఉందో లేదో చెక్ చేయండి, అది ఏమి చేయగలదో అంచనా వేయండి, కొత్త కీని తీసుకురండి, వెరిఫై చేయండి, తర్వాత పాతదాన్ని ఆఫ్ చేయండి. రిపోజిటరీని క్లీన్ చేయడం చివరి దశ, మొదటిది కాదు.

లాభాలు

• డిటెక్షన్ చెక్ అనేది ఒక సింగిల్ కమాండ్ మరియు ఇది ఏ రిపోజిటరీలోనైనా పనిచేస్తుంది
• ఫైల్‌ని డిలీట్ చేయడం లేదా హిస్టరీని తిరిగి రాయడం లాగా కాకుండా రొటేషన్ అనేది శాశ్వత పరిష్కారం
• రెండవ కీతో రోలింగ్ ఓవర్ చేయడం వల్ల లైవ్ సిస్టమ్‌లకు డౌన్‌టైమ్ ఉండదు
• రొటేషన్ సమయంలో పర్మిషన్లను ఆడిట్ చేయడం వల్ల తరచుగా ఓవర్-ప్రివిలేజ్డ్ అకౌంట్స్ బయటపడతాయి
• ఇప్పటికే ఉన్న సీక్రెట్ స్టోర్‌లోకి సీక్రెట్‌లను తరలించడానికి సాధారణంగా కొత్త టూలింగ్ అవసరం లేదు
• చివరిగా డిలీట్ చేసే వరకు మొత్తం ప్రక్రియను వెనక్కి తీసుకోవచ్చు

నష్టాలు

• రొటేషన్‌కు ఆ కీ యొక్క ప్రతి కన్స్యూమర్‌ను కనుగొనడం అవసరం, ఇది అరుదుగా డాక్యుమెంట్ చేయబడుతుంది
• మీరు ఒరిజినల్ ఎక్స్‌పోజర్‌ని అన్‌డూ చేయలేరు, దాని ప్రభావాన్ని మాత్రమే పరిమితం చేయగలరు
• హిస్టరీని తిరిగి రాయడం వల్ల ఇప్పటికే ఉన్న క్లోన్‌లు బ్రేక్ అవుతాయి మరియు ఇది టీమ్‌కు అంతరాయం కలిగిస్తుంది
• ఇప్పటికే ల్యాప్‌టాప్‌లు మరియు బ్యాకప్‌లకు కాపీ చేయబడిన సీక్రెట్‌లు మీ నియంత్రణలో ఉండవు
• క్లీనప్ చేయడానికి పట్టే సమయం, ఫీచర్ వర్క్‌కి కేటాయించాల్సిన సమయంతో పోటీపడుతుంది మరియు దీన్ని వాయిదా వేయడం సులభం
• కొన్ని పాత సిస్టమ్‌లు క్రెడెన్షియల్ రొటేషన్‌ను నిజంగా ఇబ్బందికరంగా మారుస్తాయి

జాగ్రత్త

ఈ కథనం ఎడ్యుకేషనల్ మరియు మీ ఎన్విరాన్‌మెంట్‌కి ఒక సూచన కంటే సాధారణ విధానాన్ని వివరిస్తుంది. ఇక్కడి ప్రతి కమాండ్, ఫైల్ పాత్, అకౌంట్ పేరు మరియు కీ ఐడెంటిఫైయర్ కేవలం ప్లేస్‌హోల్డర్‌లు మరియు వాటిని మీ సొంత సిస్టమ్‌ల విలువలతో భర్తీ చేయాలి. ఏదైనా కన్స్యూమర్ మిస్ అయితే క్రెడెన్షియల్స్ రొటేట్ చేయడం వల్ల లైవ్ సర్వీస్‌లకు అంతరాయం కలగవచ్చు, కాబట్టి ముందుగా ప్రతి దశను నాన్-ప్రొడక్షన్ ఎన్విరాన్‌మెంట్‌లో వెరిఫై చేయండి, దాన్ని డీయాక్టివేట్ చేసే ముందు ఒక కీపై ఏది ఆధారపడి ఉందో నిర్ధారించండి మరియు ఇక్కడ వ్రాసిన దేనిపైనైనా ఆధారపడే ముందు మీ క్లౌడ్ ప్రొవైడర్ మరియు టూలింగ్ కోసం ప్రస్తుత డాక్యుమెంటేషన్‌ను చెక్ చేయండి.

తరచుగా అడిగే ప్రశ్నలు

• Git రిపోజిటరీ నుండి ఒక సీక్రెట్‌ను డిలీట్ చేస్తే అది తొలగిపోతుందా? — లేదు. ఆ విలువ కమిట్ హిస్టరీలో మరియు ఇప్పటికే ఉన్న ప్రతి క్లోన్‌లో ఉంటుంది, కాబట్టి రిపోజిటరీ ఉన్న ఎవరైనా దాన్ని ఇప్పటికీ చదవగలరు.
• లీకైన సీక్రెట్‌ను ఫిక్స్ చేయడానికి Git హిస్టరీని తిరిగి రాస్తే సరిపోతుందా? — లేదు. ఇది రిపోజిటరీని క్లీన్ చేస్తుంది కానీ ఇప్పటికే వ్యక్తులు క్లోన్ చేసిన కాపీల గురించి ఏమీ చేయదు, కాబట్టి క్రెడెన్షియల్‌ని తప్పనిసరిగా రొటేట్ చేయాలి.
• కాన్ఫిగ్ ఫైల్ Git ద్వారా ట్రాక్ చేయబడుతుందో లేదో నేను ఎలా చెక్ చేయాలి? — రన్ చేయండి git ls-files --error-unmatch <path>. ఇది విజయవంతమైతే, ఫైల్ ట్రాక్ చేయబడుతుంది మరియు దాని కంటెంట్ హిస్టరీలో ఉంటుంది.
• లీకైన కీని నేను వెంటనే డిలీట్ చేయాలా? — అది వాడుకలో లేకుంటేనే. ప్రొడక్షన్‌లో ఏదైనా దానిపై ఆధారపడి ఉంటే, ముందుగా దానికి ప్రత్యామ్నాయాన్ని సృష్టించండి, డిప్లాయ్ చేయండి, వెరిఫై చేయండి, తర్వాత పాతదాన్ని డీయాక్టివేట్ చేయండి.
• లీకైన క్లౌడ్ కీ ఇంకా ఉపయోగించబడుతుందో లేదో నాకు ఎలా తెలుస్తుంది? — చాలా మంది ప్రొవైడర్‌లు యాక్సెస్ కీల కోసం చివరిగా ఎప్పుడు వాడారనే టైమ్‌స్టాంప్‌ను చూపుతారు, అది కన్స్యూమర్ ఇప్పటికీ దానిపై ఆధారపడుతున్నారో లేదో మీకు తెలియజేస్తుంది.
• అప్లికేషన్ సీక్రెట్స్ దానికి బదులుగా ఎక్కడ ఉండాలి? — ఒక సీక్రెట్ స్టోర్ లేదా మీ బిల్డ్ సిస్టమ్ యొక్క క్రెడెన్షియల్ స్టోర్‌లో, ఇది డిప్లాయ్ సమయంలో ఇంజెక్ట్ చేయబడుతుంది, తద్వారా ఆ విలువ సోర్స్ కంట్రోల్‌లో ఎప్పటికీ కనిపించదు.
• డిప్లాయ్‌మెంట్ పైప్‌లైన్ ఆ సీక్రెట్‌ను ఎందుకు రక్షించలేదు? — పైప్‌లైన్‌లు తరచుగా డేటాబేస్ కనెక్షన్ స్ట్రింగ్స్ వంటి కొన్ని సెట్టింగ్‌లను మాత్రమే ఇంజెక్ట్ చేస్తాయి, మరియు మిగతా అన్ని విలువలను కమిట్ చేసిన విధంగానే వదిలివేస్తాయి.
• ఇది మళ్ళీ జరగకుండా నేను ఎలా ఆపగలను? — కాన్ఫిగ్ ఫైల్‌లను వీటికి జోడించండి .gitignore, మీ రిపోజిటరీలలో ఆటోమేటెడ్ సీక్రెట్ స్కానింగ్‌ని ఎనేబుల్ చేయండి మరియు పర్మిషన్లను రివ్యూ చేయండి, తద్వారా లీకైన కీల ప్రభావం వీలైనంత తక్కువగా ఉంటుంది.

ట్యాగ్‌లు

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