एनवायरनमेंट वेरिएबल्स और Secrets

यह क्यों ज़रूरी है

Configuration की गलतियाँ pipeline के कुछ सबसे भ्रामक results देती हैं। जो missing variable किसी default पर गिर जाए, वह pull request के tests को production पर भेज सकता है; गलत base URL से green run उस build के बारे में कुछ साबित नहीं करता जिसे टेस्ट होना था; rotate हुआ password रातों-रात पूरी suite को red कर देता है, और कोई बीस product defects दर्ज कर देता है जो असल में एक ही configuration change है।

Secrets security की कीमत भी जोड़ते हैं। Repository में commit हुआ, debug line में print हुआ या upload हुए trace में पकड़ा गया token हर वह व्यक्ति copy कर सकता है जो repository पढ़ सकता है या run खोल सकता है, और shared environments के test accounts अक्सर असली systems तक पहुँचते हैं: payment sandboxes, e-mail providers, cloud accounts। इसी वजह से OWASP Secrets Management Cheat Sheet में CI/CD pipelines का अपना अलग section है। Testers ये jobs लिखते और चलाते हैं, इसलिए वे भी बचाव का हिस्सा हैं।

Recap: configuration test code के बाहर रहती है

CI/CD testing guide ने बुनियादी नियम तय किए थे: pipeline tests जहाँ संभव हो ephemeral environments में चलते हैं, और जहाँ realism ज़रूरी हो वहाँ staging जैसे shared environments में; test data pipeline ख़ुद बनाती है; और secrets CI platform के secret store या किसी external vault में रहते हैं, सिर्फ़ ज़रूरी environments तक सीमित, logs में masked और rotate होते हुए — कभी repository में नहीं, कभी print नहीं, कभी artifacts में नहीं। Forks से आए pull requests से शुरू हुए workflows को default रूप से repository secrets नहीं मिलते। यह lesson एक कदम और गहराई में जाता है: कोई value platform से चलते हुए test तक कैसे पहुँचती है, और यह रास्ता सही और सुरक्षित कैसे रहे।

Runs या targets के बीच जो कुछ बदलता है वह configuration है: टेस्ट होने वाला address, test account, timeouts, browser, कौन-से tests चलें। यह test code के बाहर रहती है। The Twelve-Factor App methodology इसे config और code का सख़्त अलगाव कहती है और एक आसान कसौटी देती है: क्या repository को अभी public किया जा सकता है, बिना एक भी credential उजागर किए? अगर नहीं, तो secret store में रहने वाली कोई चीज़ code में पड़ी है।

• Configuration variables: non-sensitive settings, जैसे BASE_URL, TEST_ENV या BROWSER। इन्हें पढ़ा, review और print किया जा सकता है।
• Secrets: access देने वाली values, जैसे test account का password, API key या database password। ये encrypted रूप में store होते हैं, logs में masked होते हैं और सिर्फ़ उन्हीं jobs को मिलते हैं जिन्हें इनकी ज़रूरत है।
• Platform variables: वे values जो CI platform हर run पर ख़ुद set करता है, जैसे CI=true, commit (GitHub Actions में GITHUB_SHA, GitLab में CI_COMMIT_SHA) और run id (GITHUB_RUN_ID, CI_PIPELINE_ID)। इन्हें reports पर लिखें ताकि हर result exact build और run की ओर इशारा करे।

Environment variables: test अपनी configuration कैसे पढ़ता है

Environment variable एक name–value pair है जो operating system किसी process को शुरू होते समय देता है; child processes इसे inherit करते हैं। CI runner हर step के लिए variables set करता है, test runner उन्हें inherit करता है, और test code उन्हें पढ़ता है: JavaScript और TypeScript में process.env.BASE_URL, Python में os.environ["BASE_URL"], Java में System.getenv("BASE_URL")।

Values कई levels पर set हो सकती हैं। GitHub Actions में env key workflow, job और step level पर काम करती है, और सबसे specific value जीतती है: step की value job की value पर भारी पड़ती है। Platform की settings में saved configuration variables (vars context) organization, repository और environment level पर होते हैं; environment की value repository वाली पर, और repository वाली organization वाली पर भारी पड़ती है। GitLab यही विचार project या group settings के CI/CD variables से देता है। जब किसी test को अनपेक्षित value मिले, तो product पर शक करने से पहले पता करें कि value किस level से आई।

• हर value एक string है। HEADLESS=false text "false" बनकर आता है, जो JavaScript में truthy है; text से compare करें, और numbers को Number() से convert करें।
• JavaScript में missing variable बस undefined होता है, error नहीं: तब test undefined/login call करता है, या इससे भी बुरा, कोई fallback address।
• Defaults timeout जैसी हानिरहित settings के लिए ठीक हैं, target या credentials के लिए कभी नहीं। BASE_URL न मिले तो run रुकना चाहिए, production पर नहीं जाना चाहिए।
• Variables masked नहीं होते। GitHub के docs चेतावनी देते हैं कि variables build outputs में unmasked दिखते हैं, इसलिए variable में रखा password साफ़ print होता है।

// tests/config.ts: read once, check early, never print a secret
const required = ['TEST_ENV', 'BASE_URL', 'TEST_USER', 'TEST_PASSWORD'];
const missing = required.filter((name) => !process.env[name]);
if (missing.length > 0) {
  throw new Error('Missing variables: ' + missing.join(', ')); // no silent fallback
}

export const config = {
  env: process.env.TEST_ENV!,                        // staging | production
  baseUrl: process.env.BASE_URL!,
  user: process.env.TEST_USER!,
  password: process.env.TEST_PASSWORD!,             // a secret: use it, never log it
  headless: process.env.HEADLESS !== 'false',        // every value is a string
  timeoutMs: Number(process.env.TIMEOUT_MS ?? '30000'), // harmless default
  allowWrites: process.env.TEST_ENV !== 'production',
};

console.log('env=' + config.env + ' baseUrl=' + config.baseUrl); // never the password

Secrets: storage, masking और least privilege

Secret एक बार store होता है, CI platform के secret store या external vault में, और run के समय job में inject होता है, आम तौर पर environment variable बनकर। GitHub saved secret को दोबारा कभी नहीं दिखाता; आप उसे सिर्फ़ replace कर सकते हैं। GitLab यही अपने “Masked and hidden” option के साथ देता है। Secrets कभी repository में नहीं जाते: न pipeline file में, न commit हुई .env में, न test data file में, न export हुए Postman environment में, न bug report के screenshot में। अपनी machine पर उन्हें ऐसी .env file में रखें जिसे .gitignore बाहर रखे। जो secret Git history तक पहुँच गया वह leak माना जाता है, भले अगला commit उसे delete कर दे, क्योंकि history हर version रखती है: पहले उसे revoke और rotate करें, फिर सफ़ाई करें।

Masking job log में secret की exact value को *** (GitHub) या [MASKED] (GitLab) से बदल देती है। यह छेदों वाला safety net है, और दोनों platforms कहते हैं कि यह guaranteed नहीं है। GitHub के docs कहते हैं कि हर transformed value (Base64 या URL-encoded) और हर derived value, जैसे secret key से sign किया गया token, को भी ::add-mask:: workflow command से secret के रूप में register करें, और चेतावनी देते हैं कि JSON या YAML blob के अंदर रखे secret के redact होने की संभावना बहुत कम हो जाती है। Masking सिर्फ़ log को cover करती है: traces, HAR files, screenshots, videos और HTML reports, जिन्होंने Authorization header या type किया गया password पकड़ लिया हो, वैसे ही upload होते हैं।

• हर environment के लिए अलग test credentials, उतने ही role के साथ जितना tests को चाहिए: कभी किसी व्यक्ति का अपना account नहीं, और “safe रहने के लिए” admin कभी नहीं।
• हर secret को उसी environment तक सीमित करें जिसे उसकी ज़रूरत है। GitHub Actions में environment secret सिर्फ़ उन jobs तक पहुँचता है जो उस environment को reference करते हैं, और required reviewers होने पर job उसे approval से पहले नहीं पढ़ सकता; GitLab के protected variables सिर्फ़ protected branches या tags की pipelines तक पहुँचते हैं।
• Pipeline के अपने token को default रूप से read-only access दें (GITHUB_TOKEN के लिए permissions: contents: read) और उसे सिर्फ़ उसी job में बढ़ाएँ जिसे ज़्यादा चाहिए।
• Fork वाला नियम बनाए रखें: forks से आए pull requests से शुरू हुए workflows को repository secrets नहीं मिलते। इसका तोड़ ढूँढने की बजाय secret पर निर्भर tests merge के बाद चलाएँ।
• Long-lived keys की बजाय short-lived credentials चुनें: OpenID Connect (OIDC) में job cloud provider को CI platform का जारी किया token दिखाता है और उस run के लिए short-lived credentials पाता है, इसलिए कोई cloud key secret के रूप में store नहीं करनी पड़ती। बाकी को schedule पर और किसी भी exposure के तुरंत बाद rotate करें, और जिन्हें कोई job इस्तेमाल नहीं करता उन्हें delete करें।

आज़माएँ: रैंडम सीक्रेट जनरेटर आज़माएँ: Base64 एन्कोडर आज़माएँ: API ऑथेंटिकेशन टेस्टर

हर environment की configuration: एक suite, कई targets

वही suite pull request के ephemeral environment, staging और production पर बिना code बदले चलनी चाहिए: सिर्फ़ configuration बदलती है। Team के साथ लिखित रूप में तय करें कि हर environment में क्या बदलता है और क्या नहीं बदलना चाहिए। Test code और टेस्ट होने वाला build वही रहते हैं; एक आम practice है build एक बार बनाना और वही build environments में आगे promote करना, ताकि staging पर pass उस build के बारे में कुछ बताए जो production तक पहुँचता है।

ये अंतर दो तरीकों से आते हैं। Non-secret settings हर environment की review की गई, commit हुई file (config/staging.json) में या environment-level variables में रह सकती हैं; secrets सिर्फ़ store से आते हैं, हर environment तक सीमित। GitHub Actions में environments के अपने variables, secrets और protection rules होते हैं; GitLab में project variable को environment scope दिया जा सकता है (group variables के लिए यह सिर्फ़ paid tiers में है)। Production के अपने नियम हों: छोटा read-only smoke set, एक dedicated monitoring account, और suite में एक guard जो वहाँ data बदलने वाले tests चलाने से मना कर दे।

Setting           PR run (ephemeral)    staging                 production
----------------  --------------------  ----------------------  ----------------------
BASE_URL          localhost:3000        staging.shop.example    shop.example
Test account      seeded per run        qa-buyer (staging)      smoke-monitor (read)
Payments          mocked                provider sandbox        not exercised
Tests that run    @pr subset            full regression         @smoke only
Writes data       yes, reset per run    yes, own records        no
Secrets from      none needed           staging environment     production environment
Approval          none                  none                    required reviewer

आज़माएँ: टेक्स्ट डिफ़

Worked example: staging tests और production smoke check

एक online shop main से deploy करती है। Team हर merge के बाद staging पर पूरी end-to-end suite चलाना चाहती है, और release production तक पहुँचने पर read-only account से एक smoke subset। नीचे के excerpt में test jobs हैं; build और deploy jobs हटा दिए गए हैं।

• नाम वही, values अलग: vars.BASE_URL और secrets.TEST_PASSWORD job के environment के हिसाब से staging या production की value बनते हैं, क्योंकि environment-level value उसी नाम की repository-level value पर भारी पड़ती है। Test code नहीं बदलता।
• Workflow सिर्फ़ main पर push होने पर चलता है; pull requests ऊपर की table वाला ephemeral setup इस्तेमाल करते हैं और उन्हें shared environment के secrets की ज़रूरत नहीं।
• permissions: contents: read दोनों jobs में GITHUB_TOKEN को read-only रखता है।
• Production job एक required reviewer का इंतज़ार करता है (repository settings में environment पर set), और उसके बाद ही production secrets पढ़ सकता है; फिर वह read-only account से @smoke tests चलाता है, और config में allowWrites false है।
• Log में Run npx playwright test group step की env values दिखाता है: BASE_URL साफ़, और TEST_PASSWORD *** के रूप में। फिर tests env=staging baseUrl=https://staging.shop.example print करते हैं। जब कोई run fail हो, तो यही lines बताती हैं कि असल में क्या टेस्ट हुआ — अगला lesson इन्हीं पर आगे बढ़ता है।

# .github/workflows/e2e.yml (excerpt; build and deploy jobs omitted)
on:
  push:
    branches: [main]
permissions:
  contents: read                       # GITHUB_TOKEN can only read the code
jobs:
  e2e-staging:
    runs-on: ubuntu-latest
    environment: staging               # staging variables and secrets only
    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
        env:
          TEST_ENV: staging
          BASE_URL: ${{ vars.BASE_URL }}                # variable: shown in logs
          TEST_USER: ${{ vars.TEST_USER }}
          TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}   # secret: masked in logs
  smoke-production:
    needs: e2e-staging                 # full file: after the production deploy job
    runs-on: ubuntu-latest
    environment: production            # waits for a required reviewer
    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --grep @smoke
        env:
          TEST_ENV: production
          BASE_URL: ${{ vars.BASE_URL }}
          TEST_USER: ${{ vars.TEST_USER }}
          TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}

आज़माएँ: YAML फ़ॉर्मेटर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• OWASP Cheat Sheet Series: Secrets ManagementOWASP FoundationAPI की और सीक्रेट कैसे जनरेट, स्टोर, रोटेट किए जाएँ और कोड व लॉग से बाहर रखे जाएँ।
• Using secrets in GitHub ActionsGitHubcredentials को repository, environment या organization secrets के रूप में रखना, GitHub उन्हें logs में कैसे छिपाता है, और forks से शुरू हुए workflows को वे क्यों नहीं मिलते।
• GitHub Actions documentationGitHubGitHub Actions में workflows, jobs, runners और artifacts कैसे परिभाषित होते हैं — जहाँ हर push या pull request पर ऑटोमेटेड टेस्ट चलते हैं।
• GitLab CI/CDGitLabपाइपलाइन, जॉब और आर्टिफ़ैक्ट कैसे परिभाषित होते हैं — जहाँ हर बदलाव पर ऑटोमेटेड रिग्रेशन सूट चलता है।