GitHub Actions’da sirlar va muhitlar: xavfsiz deploy sozlamasi

Qisqa javob

GitHub Actions’da xavfsiz deploy to‘rtta tamoyilga tayanadi:

1. Sirlar doirasi tor: production kirish ma’lumotlari repozitoriy darajasida emas, production muhitida saqlanadi.
2. Production nazorati: muhit reviewer tasdig‘ini talab qiladi va deploy’ni faqat himoyalangan branch’lardan qabul qiladi.
3. Uzoq muddatli bulut kalitlari yo‘q: workflow vaqtinchalik kirish ma’lumotlarini OIDC orqali oladi.
4. Loglar va fork’lar — xavf zonasi: maskalash kafolat emas, begona kod esa sirlar yonida ishlamasligi kerak.

Sirlarning uch darajasi

Nomlar mos kelsa, aniqroq daraja ustun turadi: muhit repozitoriydan, repozitoriy tashkilotdan. Sirlar ${{ secrets.NAME }} orqali o‘qiladi va ularni qadamlarga to‘g‘ridan-to‘g‘ri skriptga qo‘ymasdan, env orqali uzatgan ma’qul.

Production’ni himoyalash

Settings → Environments → production bo‘limida sozlang:

• Required reviewers — inson yoki jamoa har bir deploy job’ini u ishga tushishidan va sirlarni olishidan oldin tasdiqlashi kerak.
• Deployment branches and tags — faqat main yoki reliz teglariga ruxsat bering. Shunda kimdir workflow’ni o‘zgartirsa ham, feature-branch deploy qila olmaydi.
• Deploy oldidan pauza kerak bo‘lsa, wait timer.
• Mavjud bo‘lsa, o‘zini o‘zi tasdiqlashni taqiqlash, toki o‘zgarish muallifi o‘z deploy’ini tasdiqlay olmasin.

Bunga main uchun branch protection yoki rulesets’ni qo‘shing: pull request uchun majburiy review, majburiy tekshiruvlar va force push taqiqi. Aks holda yozish huquqi bor har kim o‘zgartirilgan workflow’ni to‘g‘ridan-to‘g‘ri himoyalangan branch’ga push qila oladi.

Bulut kalitlari o‘rniga OIDC

Sirlarda saqlanadigan statik kirish kalitlari oylab yashaydi va istalgan joydan ishlaydi. OIDC bilan GitHub har bir ishga tushirish uchun imzolangan token chiqaradi, bulut provayderi esa uni vaqtinchalik kirish ma’lumotlariga almashtiradi — faqat token claim’lari ishonch siyosatiga (repozitoriy, branch, muhit) mos kelsa.

name: deploy
on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: eu-central-1
      - run: ./scripts/deploy.sh

Bulut tomonida ishonch siyosatini aniq subject bilan cheklang, masalan, muayyan repozitoriyning production muhiti bilan. Butun tashkilotga wildcard qo‘yish foydani yo‘qqa chiqaradi. Bu ssenariyni yirik bulutlar va Vault qo‘llab-quvvatlaydi.

Sirlar qanday sizib chiqadi

Loglar orqali:

• GitHub sirlarning aniq qiymatlarini maskalaydi, ammo o‘zgartirilganlarini emas: base64’dagi, bo‘laklarga ajratilgan, URL-kodlangan yoki JSON ichidagi.
• set -x, CLI’ning batafsil rejimi va debug-loglash sarlavha va tokenlarni chiqarib yuborishi mumkin.
• Hosila qiymatlarni ishlatishdan oldin echo "::add-mask::$VALUE" bilan ro‘yxatdan o‘tkazing.

Fork’lar va begona kod orqali:

• Fork’lardan kelgan pull_request hodisasidagi workflow’lar sirlarni olmaydi — shunday qolishi kerak.
• pull_request_target va workflow_run asosiy repozitoriy sirlari bilan ishlaydi. Ularda PR kodini checkout qilib ishga tushirsangiz, sirlaringiz istalgan tashqi ishtirokchiga o‘tadi.
• PR sarlavhasi yoki branch nomi kabi ma’lumotlarni to‘g‘ridan-to‘g‘ri run: ichiga qo‘yish buyruq inyeksiyasiga yo‘l ochadi. Ularni env orqali va qo‘shtirnoq ichida uzating.

Bog‘liqliklar orqali:

• Uchinchi tomon action’lari job’ingiz huquqlari bilan ishlaydi. Ularni to‘liq commit SHA’ga mahkamlang va nima qilishini tekshiring.

Minimal huquqlar bo‘yicha checklist

• permissions:’ni workflow darajasida belgilang; contents: read’dan boshlang va faqat keraklisini qo‘shing.
• Production sirlarini faqat production muhitida saqlang.
• Bir marta bo‘lsa ham log, commit yoki chatga tushgan har qanday sirni almashtiring.
• Foydalanilmayotgan sirlar va muhitlarni o‘chiring.
• Administrator huquqlari kimda borligini tekshiring: ular himoya qoidalarini o‘zgartira oladi.