GitHub Secrets — maxfiy ma'lumotlarni saqlash

~10 daq · Git · GitHub Imkoniyatlari

Muammodan boshlaylik

Deploy workflow ga (39-dars) SSH kalit, Telegram bot token, Payme API kaliti kerak. Eng oson yo'l:

      - run: ssh -i "-----BEGIN OPENSSH PRIVATE KEY-----..." deploy@45.12.34.56
        env:
          PAYME_KEY: "sk_live_8f3a2b..."

Workflow fayli — repozitoriyda. Repozitoriyni ko'ra oladigan har kim — hamkasblar, sobiq xodimlar, ommaviy bo'lsa butun internet — production serveringizga kirish kalitini va to'lov tizimi kalitini oladi. Va ular Git tarixida abadiy qoladi (11-dars).

Sirlar uchun alohida, himoyalangan joy kerak — GitHub Secrets.

Secret yaratish

Repozitoriy → Settings → Secrets and variables → Actions → New repository secret:

• Name: SSH_KEY (katta harflar, _ bilan)
• Secret: qiymat (ko'p qatorli bo'lishi mumkin — SSH kalit kabi)

Saqlangandan keyin qiymatni hech kim ko'ra olmaydi — hatto siz ham. Faqat yangilash yoki o'chirish mumkin.

Terminaldan (54-dars):

gh secret set SSH_KEY < ~/.ssh/deploy_key
gh secret set PAYME_KEY --body "sk_live_8f3a2b..."
gh secret list

Workflow da ishlatish

steps:
  - name: Deploy
    env:
      PAYME_KEY: ${{ secrets.PAYME_KEY }}
      SERVER: ${{ secrets.SERVER_HOST }}
    run: ./deploy.sh

• ${{ secrets.NOM }} — qiymatni olish
• env: orqali muhit o'zgaruvchisi sifatida berish — eng xavfsiz usul (skript uni $PAYME_KEY deb o'qiydi)

Loglarda yashirish

GitHub sir qiymatlarini loglarda avtomatik *** ga almashtiradi:

Run echo "Kalit: $PAYME_KEY"
Kalit: ***

[!WARNING] Bu himoya mutlaq emas. Sirni o'zgartirib chiqarsangiz (base64, teskari tartibda, harflar orasiga bo'shliq) — u logda ochiq ko'rinadi. Sirlarni hech qachon ataylab echo qilmang, va JSON kabi tuzilmali sirlarning har bir qismi alohida yashirilmasligini yodda tuting.

Sirlar darajalari

Environment secrets — production uchun eng yaxshisi:

jobs:
  deploy:
    environment: production          # ← production sirlari faqat shu yerda
    steps:
      - run: ./deploy.sh
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

Environment ga "Required reviewers" qo'yilgan bo'lsa — sirlar faqat inson tasdiqlagandan keyin beriladi. PR dagi test job lari production sirlarini umuman ko'rmaydi.

GITHUB_TOKEN — avtomatik sir

Har bir workflow uchun GitHub avtomatik vaqtinchalik token yaratadi — yaratish shart emas:

permissions:
  contents: write        # reliz yaratish, push
  packages: write        # ghcr.io ga push
  pull-requests: write   # PR ga izoh

steps:
  - run: gh release create v1.0.0
    env:
      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

• Faqat shu repozitoriy uchun ishlaydi
• Workflow tugashi bilan bekor bo'ladi
• permissions: — minimal kerakli huquqlarni bering (standart holatda faqat o'qish bo'lishi tavsiya etiladi: Settings → Actions → Workflow permissions → Read)

Boshqa repozitoriylarga kirish kerak bo'lsa — alohida token yoki GitHub App.

Variables — maxfiy bo'lmagan sozlamalar

Har bir sozlama sir emas. Server manzili, Node versiyasi, domen — Variables tabida:

env:
  APP_URL: ${{ vars.APP_URL }}
  NODE_VERSION: ${{ vars.NODE_VERSION }}

Variables loglarda ko'rinadi va qiymati sozlamalarda o'qiladi — tahrirlash qulay.

OIDC — sirsiz bulutga kirish

AWS, Google Cloud, Azure uchun uzoq muddatli kalitlarni saqlash o'rniga — OIDC: GitHub har bir workflow ga qisqa muddatli identifikatsiya tokeni beradi, bulut uni tekshirib, vaqtinchalik kirish huquqini beradi.

permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/github-deploy
      aws-region: eu-central-1

Saqlanadigan sir yo'q — sizib chiqadigan narsa ham yo'q. Bulutga deploy uchun zamonaviy eng yaxshi amaliyot.

Xavfsizlik qoidalari

1. Kodda va workflow fayllarida — hech qachon sir yo'q. Faqat ${{ secrets.X }}
2. Minimal huquq — deploy kaliti faqat deploy foydalanuvchisiga, token faqat kerakli repozitoriy va ruxsatlarga
3. Muntazam almashtirish — ayniqsa jamoa a'zosi ketganda
4. Fork PR lari sirlarni ko'rmaydi — buni pull_request_target bilan chetlab o'tmang (38-dars)
5. Uchinchi tomon action larini ehtiyotkorlik bilan: ular sirlaringizga kira oladi. Ishonchli mualliflar, aniq versiya — yoki eng xavfsizi, commit SHA bilan qotirish: uses: some/action@a1b2c3d...
6. Sir sizib chiqdimi — darhol almashtiring (bekor qilib, yangisini yarating), keyin sabab va tarixni tozalash bilan shug'ullaning

Secret scanning

GitHub repozitoriylarni ma'lum formatdagi sirlar (AWS kalitlari, GitHub tokenlari, Stripe kalitlari...) uchun avtomatik tekshiradi. Push protection yoqilgan bo'lsa (Settings → Code security), sir bor commit ni push qilishga urinsangiz — GitHub uni rad etadi. Ommaviy repozitoriylarda standart holatda yoqilgan.

Nima uchun shunday?

Nima uchun sirlar kod bilan birga emas, alohida saqlanishi kerak — repozitoriy baribir yopiq-ku?

Chunki "yopiq" — vaqtinchalik holat. Repozitoriy ommaviy qilinishi, fork qilinishi, sobiq xodimning noutbukida qolishi, noto'g'ri sozlangan CI orqali sizib chiqishi mumkin — va Git tarixi hamma narsani abadiy eslaydi. Kod va sirlarning hayot sikli ham turlicha: kod ko'p kishilar tomonidan o'qiladi va o'zgartiriladi, sirlar esa — juda kam kishi tomonidan, va ular muntazam almashtirilishi kerak. Ajratilgan sirlar: kod kim tomonidan o'qilishidan qat'i nazar xavfsiz, sirni almashtirish — kodni o'zgartirmasdan bir daqiqalik ish, va kim qaysi sirga kirishi aniq nazorat qilinadi.

Xulosa

Eslab qoling:

• Sirlar — Settings → Secrets and variables → Actions; qiymati keyin ko'rinmaydi
• ${{ secrets.NOM }} — env: orqali bering
• Loglarda *** — lekin mutlaq himoya emas, sirni chiqarmang
• Darajalar: repository, environment (production uchun), organization
• GITHUB_TOKEN — avtomatik, vaqtinchalik; permissions: — minimal
• Maxfiy bo'lmagan sozlamalar — vars.NOM
• Bulut uchun — OIDC, saqlanadigan kalit yo'q
• Secret scanning + push protection — yoqing
• Sir sizib chiqsa — darhol almashtiring

Keyingi bo'lim

8-bo'lim: Ilg'or Git — submodule, worktree, hook lar, archive va bare repozitoriylar.