AWS کے لیے GitHub ایکشنز میں OpenID Connect (OIDC) کو کیسے ترتیب دیا جائے۔

اگر آپ نے اسے بچا لیا۔ AWS_ACCESS_KEY_ID اور AWS_SECRET_ACCESS_KEY AWS میں تعیناتی کے لیے GitHub سیکریٹ اکیلا نہیں ہے۔ یہ سب سے عام طریقہ ہے اور CI/CD پائپ لائنوں میں سب سے بڑے حفاظتی خطرات میں سے ایک ہے۔

اس کی وجہ یہ ہے: جامد اسناد کی میعاد خود ختم نہیں ہوتی ہے۔ اگر غلط کنفیگرڈ ورک فلو، پبلک فورک، یا کمپرومائزڈ ریپوزٹری کے ذریعے لیک ہو جائے تو حملہ آور آپ کے AWS ماحول تک رسائی جاری رکھ سکتا ہے جب تک کہ اسے دستی طور پر تبدیل نہ کیا جائے۔ اور زیادہ تر ٹیمیں انہیں کافی بار نہیں گھماتی ہیں۔

OpenID Connect (OIDC) اس مسئلے کو مکمل طور پر حل کرتا ہے۔ اپنے اسناد کو طویل عرصے تک ذخیرہ کرنے کے بجائے، GitHub ایکشنز آپ سے پوچھتا ہے: مختصر مدت کا ٹوکن ہر بار جب کوئی ورک فلو چلتا ہے، تو اسے براہ راست AWS سے پیش کیا جاتا ہے۔ گھومنے کے لئے کوئی راز نہیں ہیں۔ لیک کرنے کے لیے کوئی اسناد نہیں ہیں۔ کوئی دستی کلید کا انتظام نہیں ہے۔

اس ٹیوٹوریل میں، آپ سیکھتے ہیں کہ GitHub ایکشنز اور AWS کے درمیان شروع سے OIDC توثیق کیسے ترتیب دی جائے۔ بالآخر، آپ کا ورک فلو محفوظ طریقے سے AWS سے تصدیق شدہ ہے بغیر کسی ایک رسائی کلید کو ذخیرہ کئے۔

انڈیکس

اوپن آئی ڈی کنیکٹ (OIDC) کیا ہے؟

OpenID Connect ایک شناختی پروٹوکول ہے جو OAuth 2.0 پر بنایا گیا ہے۔ یہ نظام کو مشترکہ راز کے بجائے ٹوکن کے ذریعے شناخت کی تصدیق کرنے کی اجازت دیتا ہے۔

GitHub ایکشنز اور AWS کے تناظر میں:

گٹ ہب کردار ادا کریں شناخت فراہم کنندہ (IdP). ہر ورک فلو کے عمل کے لیے دستخط شدہ JSON ویب ٹوکن (JWT) جاری کرتا ہے۔
AWS کردار ادا کریں سروس فراہم کرنے والا. GitHub میں اپنی عوامی کلید کے خلاف اس ٹوکن کی تصدیق کریں اور اسے عارضی AWS اسناد کے لیے تبدیل کریں۔ اسناد جو AWS واپس کرتی ہیں وہ قلیل المدتی ہیں (بطور ڈیفالٹ ایک گھنٹہ تک درست) اور آپ کے بیان کردہ IAM کردار کے دائرہ کار میں ہیں۔ ورک فلو ختم ہونے پر، وہ اسناد ضائع ہو جاتی ہیں۔

یہ ماڈل ہے۔ فیڈریشن ID. یہ وہی تصور ہے جب آپ تیسرے فریق کی ویب سائٹس پر Google کے ساتھ سائن ان کرتے ہیں۔ فرق یہ ہے کہ صارف لاگ ان کرنے کے بجائے، ورک فلو تصدیق کرتا ہے۔

GitHub ایکشنز اور AWS کے درمیان OIDC کیسے کام کرتا ہے۔

YAML کی ایک لائن لکھنے سے پہلے بہاؤ کو سمجھنا اچھا خیال ہے۔ نئی ٹیکنالوجی یا تصور کو نافذ کرتے وقت یہ ایک ذاتی نقطہ نظر ہے۔ ہر بار جب ورک فلو چلتا ہے تو یہاں کیا ہوتا ہے:

یہ خاکہ OpenID Connect (OIDC) کا استعمال کرتے ہوئے GitHub ایکشنز اور AWS کے درمیان محفوظ تصدیقی بہاؤ کو ظاہر کرتا ہے، جس سے GitHub میں طویل المدت AWS اسناد کو ذخیرہ کرنے کی ضرورت ختم ہو جاتی ہے۔ مرحلہ وار کیا ہوتا ہے یہاں ہے:

1. ابتدائی توثیق کی درخواست

جب ایک GitHub ایکشن ورک فلو شروع ہوتا ہے، ایگزیکیوٹر (ورچوئل مشین جو ورک فلو چلاتی ہے) GitHub کے OIDC فراہم کنندہ سے JSON ویب ٹوکن (JWT) کی درخواست کرتا ہے: https://token.actions.githubusercontent.com.

2. ٹوکن جاری کرنا

GitHub کا OIDC فراہم کنندہ JWT تیار کرتا ہے اور اس پر دستخط کرتا ہے جس میں ورک فلو کے بارے میں اہم دعوے (میٹا ڈیٹا) ہوتے ہیں۔ ان دعووں میں تفصیلات شامل ہیں جیسے کہ ورک فلو جس ریپوزٹری پر چل رہا ہے، وہ برانچ جس نے اسے متحرک کیا، وہ ماحول جس میں یہ چل رہا ہے، اور دیگر متعلقہ معلومات جو ورک فلو کی شناخت کو ثابت کرتی ہیں۔

3. ٹوکن کی تصدیق

GitHub ایکشنز ایگزیکیوٹر اس دستخط شدہ JWT کو AWS سیکیورٹی ٹوکن سروس (STS) فراہم کرتا ہے۔ AWS STS GitHub پر عوامی طور پر دستیاب انکرپشن کیز کے خلاف JWT دستخط کی توثیق کرتا ہے تاکہ یہ یقینی بنایا جا سکے کہ ٹوکن مستند ہے اور اس کے ساتھ چھیڑ چھاڑ نہیں کی گئی ہے۔

4. ٹرسٹ پالیسی کی تصدیق

AWS STS IAM رول پر تشکیل شدہ اعتماد کی پالیسی کی تصدیق کرتا ہے۔ یہ ٹرسٹ پالیسی بتاتی ہے کہ کون سے GitHub ریپوزٹریز، برانچز، یا ماحول اس کردار کو سنبھال سکتے ہیں۔ اگر JWT میں دعوے اعتماد کی پالیسی کی شرائط سے مماثل ہیں، توثیق کامیاب ہو جاتی ہے۔

5. عارضی سرٹیفکیٹ کا اجراء

تصدیق ہونے کے بعد، AWS STS GitHub ایکشنز ایگزیکیوٹر کو عارضی حفاظتی اسناد واپس کر دیتا ہے۔ ان اسناد میں ایک رسائی کلید ID، خفیہ رسائی کلید، اور سیشن ٹوکن شامل ہیں جو محدود وقت کے لیے درست ہیں (عام طور پر 1 گھنٹہ بذریعہ ڈیفالٹ، لیکن اسے 12 گھنٹے تک کنفیگر کیا جا سکتا ہے)۔

6. AWS API رسائی

GitHub ایکشن رنر ان عارضی اسناد کا استعمال AWS وسائل پر API کالوں کی توثیق کرنے کے لیے کرتا ہے، جیسے کہ Docker امیج کو ECR میں دھکیلنا، ECS سروس کو اپ ڈیٹ کرنا، S3 بالٹی پر لکھنا، یا Lambda فنکشن کی درخواست کرنا۔

اہم نکات: AWS آپ کے GitHub کی اسناد نہیں دیکھ سکتا، اور GitHub آپ کی AWS اسناد نہیں دیکھ سکتا۔ JWTs وہ واحد اشیاء ہیں جن کا تبادلہ کیا جاتا ہے اور ان پر دستخط، دائرہ کار اور قلیل مدتی ہوتے ہیں۔

شرطیں

شروع کرنے سے پہلے، یقینی بنائیں کہ آپ کے پاس درج ذیل ہیں:

نہیں AWS اکاؤنٹ آپ کو شناخت فراہم کرنے والے اور کردار بنانے کے لیے IAM کی اجازت ہے۔
کوئی راستہ نہیں GitHub ذخیرہ جہاں (عوامی یا نجی) ورک فلو چلے گا۔
بنیادی علم گٹ ہب آپریشنزلکھنا جانتے ہیں .yml ورک فلو فائل
بنیادی علم AWS IAM کردار، پالیسیاں، اور اجازتیں۔
کہ AWS CLI انسٹال اور کنفیگرڈ (اختیاری، لیکن تصدیق کے لیے مفید)۔ آپ کو AWS ماہر بننے کی ضرورت نہیں ہے۔ ہر قدم میں کنسول کا درست راستہ اور مطلوبہ کنفیگریشن اقدار شامل ہیں۔

مرحلہ 1: AWS میں ایک IAM OIDC شناخت فراہم کنندہ بنائیں

پہلی چیز جو آپ کو کرنے کی ضرورت ہے وہ یہ ہے کہ AWS کو GitHub پر اپنے شناختی فراہم کنندہ کے طور پر بھروسہ کرنے کو کہیں۔ یہ فی AWS اکاؤنٹ ایک وقتی سیٹ اپ ہے۔

اسے AWS کنسول میں کیسے کریں۔

AWS IAM کنسول کھولیں۔
بائیں سائڈبار میں، شناخت فراہم کرنے والے پر کلک کریں۔
فراہم کنندہ شامل کریں پر کلک کریں۔
فراہم کنندہ کی قسم کے طور پر OpenID کنیکٹ کو منتخب کریں۔
فراہم کنندہ URL کے لیے، درج کریں:

https://token.actions.githubusercontent.com

منزل میں، درج کریں:

sts.amazonaws.com

فراہم کنندہ شامل کریں پر کلک کریں۔

AWS CLI کا استعمال کرتے ہوئے اسے کیسے کریں۔

اگر آپ ٹرمینل کو ترجیح دیتے ہیں تو درج ذیل کمانڈ کو چلائیں:

aws iam create-open-id-connect-provider 
  --url https://token.actions.githubusercontent.com 
  --client-id-list sts.amazonaws.com

یہ ایک بار بننے کے بعد ظاہر ہوگا۔ token.actions.githubusercontent.com ذیل میں درج شناخت فراہم کرنے والا IAM کنسول میں۔ اس فراہم کنندہ کا حوالہ اگلے مرحلے میں IAM رول ٹرسٹ پالیسی میں دیا گیا ہے۔

مرحلہ 2: اعتماد کی پالیسی کے ساتھ ایک IAM کردار بنائیں

اب آپ کو اپنے GitHub ایکشنز ورک فلو کو سنبھالنے کے لیے IAM کردار کی ضرورت ہے۔ اس کردار کے لیے ٹرسٹ پالیسی کنٹرول کرتی ہے کہ کون سے ذخیرے اور شاخیں اسناد کی درخواست کر سکتی ہیں۔

AWS کنسول میں IAM رول کیسے بنایا جائے۔

AWS IAM کنسول کھولیں۔
بائیں سائڈبار میں کردار
کلک کریں کردار بنائیں
کے لیے قابل اعتماد ہستی کی اقساممنتخب کریں ویب شناخت
کے لیے شناخت فراہم کرنے والامنتخب کریں: token.actions.githubusercontent.com یہ پہلے بنایا گیا تھا۔
منزل میں، منتخب کریں: sts.amazonaws.com بھی
GitHub تنظیم کے لیے، اپنا GitHub صارف نام یا تنظیم کا نام درج کریں۔
GitHub ذخیرہ کے لیے، اپنا GitHub ذخیرہ درج کریں۔
GitHub برانچ کے لیے، برانچ کا نام درج کریں (جیسے مین)۔
اگلا پر کلک کریں، پھر اگلا پر کلک کریں، کردار کو ایک نام دیں، اور کردار بنائیں پر کلک کریں۔

نوٹ: جب آپ اس اپروچ کو استعمال کرتے ہوئے IAM رول بناتے ہیں، تو آپ کے پاس پہلے سے موجود ہوتا ہے۔ قابل اعتماد ہستی مندرجہ بالا مراحل 4-9 پر مبنی ایک قابل اعتماد پالیسی استعمال کریں۔ آپ بنائے گئے رول پر کلک کرکے اور ٹرسٹ ریلیشن شپس پر جا کر اسے چیک کر سکتے ہیں۔

AWS CLI کا استعمال کرتے ہوئے IAM رول کیسے بنایا جائے۔

پہلے آپ کو اپنے مقامی کمپیوٹر پر ٹرسٹ پالیسی دستاویز بنانے کی ضرورت ہے۔ trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:YOUR_GITHUB_ORG/YOUR_REPO_NAME:*"
        }
      }
    }
  ]
}

محفوظ کرنے سے پہلے درج ذیل پلیس ہولڈرز کو تبدیل کریں:

پلیس ہولڈر	سے بدل دیں۔
`YOUR_ACCOUNT_ID`	12 ہندسوں کا AWS اکاؤنٹ ID
`YOUR_GITHUB_ORG`	GitHub صارف نام یا تنظیم کا نام
`YOUR_REPO_NAME`	GitHub ذخیرے کا نام

کیسے سمجھنا ہے `sub` صورت حال

کہ sub (subject) JWT میں دعوے AWS کو بالکل بتاتے ہیں کہ درخواست کہاں سے آئی ہے۔ قدر repo:your-org/your-repo:* اس کا مطلب یہ ہے کہ اس ذخیرے کی کوئی بھی شاخ اس کردار کو سنبھال سکتی ہے۔

ضرورت کے مطابق آپ اسے مزید بڑھا سکتے ہیں۔

# Only the main branch
"token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
 
# Only a specific GitHub Environment
"token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:environment:production"

دائرہ کار کو درست کرنا اس سیٹ اپ میں سب سے اہم حفاظتی فیصلوں میں سے ایک ہے۔ فیصلہ کرنے کا طریقہ یہاں ہے:

استعمال کریں ref:refs/heads/main جب صرف مین/پروڈکشن برانچ کو AWS میں تعینات کرنے کی ضرورت ہو۔ یہ سب سے زیادہ محدود اور محفوظ آپشن ہے۔ فیچر برانچز حادثاتی طور پر (یا بدنیتی سے) تعیناتیوں کو متحرک نہیں کر سکتیں یا پیداواری وسائل میں ترمیم نہیں کر سکتیں۔
استعمال کریں environment:production اگر آپ GitHub ماحول کو تحفظ کے قواعد کے ساتھ استعمال کرتے ہیں (ضروری جائزہ لینے والے، تعیناتی دروازے)۔ یہ آپ کو GitHub کے منظوری والے ورک فلوز کے ذریعے تعیناتیوں کو کنٹرول کرنے کی اجازت دیتا ہے جبکہ یہ بھی محدود کرتا ہے کہ کون سے ورک فلو AWS تک رسائی حاصل کر سکتے ہیں۔
استعمال کریں repo:your-org/your-repo:* (وائلڈ کارڈ) صرف اس صورت میں لاگو ہوتا ہے جب آپ کو تعینات کرنے کے لیے برانچ کی ضرورت ہو۔ مثال کے طور پر، ایک ترقیاتی ماحول میں جہاں ہر فیچر برانچ اپنے الگ تھلگ اسٹیک میں تعینات ہے۔ اس فیچر کو پروڈکشن رولز میں استعمال نہ کریں۔

اعتماد کی پالیسی کے ساتھ کردار بنانے کے لیے، درج ذیل کمانڈ کو چلائیں:

aws iam create-role 
  --role-name GitHubActionsOIDCRole 
  --assume-role-policy-document file://trust-policy.json 
  --description "Role assumed by GitHub Actions via OIDC"

براہ کرم درج ذیل کو نوٹ کریں: رول اے آر این آؤٹ پٹ میں۔ یہ اس طرح نظر آئے گا:

arn:aws:iam::YOUR_ACCOUNT_ID:role/GitHubActionsOIDCRole

آپ کو مرحلہ 4 میں ورک فلو YAML میں اس ARN کی ضرورت ہے۔

مرحلہ 3: IAM کردار میں اجازتیں منسلک کریں۔

اب آپ IAM کردار کی توثیق کر سکتے ہیں، لیکن آپ کے پاس ابھی تک اجازت نہیں ہے۔ آپ کو ایسی پالیسیاں منسلک کرنے کی ضرورت ہے جو اس بات کی وضاحت کریں کہ آپ کا ورک فلو اصل میں AWS میں کیا کر سکتا ہے۔

کم از کم استحقاق کے اصول کو کیسے لاگو کیا جائے۔

صرف وہی اجازتیں دیں جو آپ کے ورک فلو کو درکار ہیں۔ اگر آپ کا ورک فلو S3 پر تعینات ہے تو S3 کی اجازت دیں۔ اگر آپ کسی تصویر کو ECR پر آگے بڑھا رہے ہیں تو ECR کی اجازت دیں۔ کبھی منسلک نہ کریں۔ AdministratorAccess CI/CD کردار۔

آپشن 1: AWS مینیجڈ پالیسی منسلک کریں (کوئیک سٹارٹ):

aws iam attach-role-policy 
  --role-name GitHubActionsOIDCRole 
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess

آپشن 2: ایک مخصوص S3 بالٹی (پیداوار کے لیے تجویز کردہ) کے دائرہ کار میں اپنی مرضی کی پالیسی بنائیں۔

پیداوار کے لیے اس نقطہ نظر کی سفارش کی جاتی ہے کیونکہ یہ سیکیورٹی واقعے کے دھماکے کے رداس کو محدود کرتا ہے۔ اگر آپ کے ورک فلو کی اسناد سے سمجھوتہ کیا جاتا ہے تو، ایک مخصوص بالٹی کے دائرہ کار میں اپنی مرضی کی پالیسی کا مطلب ہے کہ حملہ آور آپ کے AWS اکاؤنٹ میں موجود تمام S3 بالٹیوں کے بجائے صرف اس واحد بالٹی کو متاثر کر سکتا ہے۔ یہ آپ کے ورک فلو میں حادثاتی غلط کنفیگریشن کو غیر متعلقہ وسائل کو متاثر کرنے سے بھی روکتا ہے۔

نامی ایک فائل بنائیں s3-deploy-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

پھر اسے بنائیں اور منسلک کریں۔

aws iam create-policy 
  --policy-name GitHubActionsS3DeployPolicy 
  --policy-document file://s3-deploy-policy.json
 
aws iam attach-role-policy 
  --role-name GitHubActionsOIDCRole 
  --policy-arn arn:aws:iam::YOUR_ACCOUNT_ID:policy/GitHubActionsS3DeployPolicy

نوٹ: عمل درآمد بھی ممکن ہے: مرحلہ 3 کنسول کے ذریعے۔

حوالہ: دستیاب AWS IAM کارروائیوں کی مکمل فہرست کے لیے، AWS IAM ایکشنز کا حوالہ دیکھیں۔

مرحلہ 4: کردار ARN کو GitHub ایکشن متغیر کے طور پر محفوظ کریں۔

ورک فلو کو ترتیب دینے سے پہلے، آپ کو رول ARN دستیاب کرانا چاہیے۔ چونکہ ARN بذات خود حساس ڈیٹا نہیں ہے، اس لیے ہم اسے GitHub پر ایک غیر خفیہ ذخیرہ متغیر کے طور پر اسٹور کرتے ہیں۔

مخزن میں متغیرات کو کیسے شامل کیا جائے۔

اپنا GitHub ذخیرہ کھولیں اور اگلا پر کلک کریں۔ ترتیب:

بائیں سائڈبار میں نیچے سکرول کریں۔ راز اور متغیرات، پھر کلک کریں۔ عمل:

اگلا پر کلک کریں۔ متغیر ٹیب (خفیہ نہیں)
کلک کریں نیا ذخیرہ متغیر
آپ سیٹ کر سکتے ہیں نام کو:

AWS_ROLE_ARN

ترتیب قدر مثال کے طور پر، مرحلہ 2 سے ARN کے کردار میں:

arn:aws:iam::YOUR_ACCOUNT_ID::role/GitHubActionsOIDCRole

کلک کریں متغیر شامل کریں۔

آپ اپنے ورک فلو کے اگلے مرحلے میں اس متغیر کا حوالہ دیں گے۔ ${{ vars.AWS_ROLE_ARN }}.

مرحلہ 5: GitHub ایکشن ورک فلو کو کنفیگر کریں۔

اب جبکہ AWS اور GitHub مکمل طور پر کنفیگر ہو چکے ہیں، آپ کو OIDC ٹوکن کی درخواست کرنے اور اسے استعمال کرنے کی تصدیق کرنے کے لیے اپنے ورک فلو کو اپ ڈیٹ کرنے کی ضرورت ہے۔

مطلوبہ ورک فلو اجازتوں کو کیسے ترتیب دیا جائے۔

آپ کے کام کا بہاؤ ~ کرنا ہے۔ اعلان id-token: write. اس کے بغیر، GitHub ایگزیکیوٹرز کو OIDC ٹوکن جاری نہیں کرے گا۔

permissions:
  id-token: write   # Required to request the OIDC JWT
  contents: read    # Required to checkout the repository

اہم: ٹاسک لیول پر اجازتیں سیٹ کرنا تمام اعلیٰ سطح کی اجازتوں کو اوور رائیڈ کر دیتا ہے۔ یقینی بنائیں id-token: write یہ اس سطح پر موجود ہے جہاں AWS توثیق کے مراحل کو انجام دیا جاتا ہے۔

مکمل ورک فلو مثال

ذیل میں OIDC کا استعمال کرتے ہوئے AWS کی توثیق کرنے اور S3 پر ایک مستحکم سائٹ تعینات کرنے کے لیے مکمل ورک فلو ہے۔

name: Deploy to AWS S3
 
on:
  push:
    branches:
      - main
 
permissions:
  id-token: write
  contents: read
 
jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
 
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_ROLE_ARN }}
          aws-region: us-east-2
 
      - name: Verify AWS identity
        run: aws sts get-caller-identity
 
      - name: Deploy to S3
        run: |
          aws s3 sync ./code s3://your-bucket-name

ارتکاب کرنے سے پہلے درج ذیل کو تبدیل کریں:

پلیس ہولڈر	سے بدل دیں۔
`AWS_ROLE_ARN`	GitHub کے IAM رول ARN کے لیے متغیر نام
`us-east-2`	AWS ریجن کو نشانہ بنائیں
`your-bucket-name`	S3 بالٹی کا نام
`./code`	مقامی ڈائریکٹری جس میں فائلیں شامل ہیں جن کو آپ S3 کے ساتھ ہم آہنگ کرنا چاہتے ہیں۔

آپ یہاں میرے GitHub Repo میں کوڈ کے نمونے دیکھ سکتے ہیں۔

میمو: کہ aws-actions/configure-aws-credentials یہ کارروائی پورے OIDC ٹوکن ایکسچینج کو خود بخود ہینڈل کرتی ہے۔ GitHub سے JWT کی درخواست کریں اور کال کریں۔ sts:AssumeRoleWithWebIdentityاپنی باقی کارروائیوں کے لیے ماحولیاتی متغیرات کے طور پر عارضی اسناد برآمد کریں۔

براہ کرم تمام دستیاب اختیارات کے لیے کام کے لیے سرکاری دستاویزات کا حوالہ دیں۔

مرحلہ 6: ورک فلو کو چلائیں اور تصدیق کریں۔

ورک فلو main ایک شاخ کھولیں عمل ریپوزٹری کے ٹیب کو چلتے ہوئے دیکھنے کے لیے اسے تھپتھپائیں۔

ایک کامیاب عملدرآمد کیسا لگتا ہے۔

OIDC کے ذریعے AWS اسناد کو ترتیب دینے کے اقدامات کو درج ذیل دکھانا چاہیے:

Assuming role with OIDC: arn:aws:iam::YOUR_ACCOUNT_ID:role/GitHubActionsOIDCRole

AWS اسناد کی تصدیق کے مراحل (aws sts get-caller-identity) واپس آنا چاہئے:

{
    "UserId": "AROA...:GitHubActions",
    "Account": "YOUR_ACCOUNT_ID",
    "Arn": "arn:aws:sts::YOUR_ACCOUNT_ID:assumed-role/GitHubActionsOIDCRole/GitHubActions"
}

اگر آپ دیکھتے ہیں assumed-role آؤٹ پٹ میں ARN، OIDC صحیح طریقے سے کام کر رہا ہے۔ آپ کا ورک فلو اب AWS سے تصدیق کرتا ہے بغیر کسی ایک بھی سند کے ذخیرہ شدہ۔

سیکیورٹی کے بہترین طریقے

OIDC کام کرنا پہلا قدم ہے۔ اسے صحیح طریقے سے لاک کرنا دوسرا مرحلہ ہے۔

دائرہ کار کی وضاحت کریں۔ `sub` اسے ہر ممکن حد تک سخت رکھیں۔

وائلڈ کارڈ استعمال کرنے سے گریز کریں جیسے: repo:your-org/*:* یہ آپ کی تنظیم میں کسی بھی ذخیرے کو کردار ادا کرنے کی اجازت دیتا ہے۔ اس کا دائرہ درست ذخیرہ اور برانچ تک پہنچائیں جس تک آپ کو رسائی کی ضرورت ہے۔

"token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"

پیداوار کی تعیناتی کے لیے GitHub ماحول استعمال کریں۔

GitHub ماحول آپ کو دستی منظوری کے دروازے شامل کرنے اور ان شاخوں کو محدود کرنے کی اجازت دیتا ہے جن میں آپ تعینات کر سکتے ہیں۔ OIDC کے ساتھ مل کر، آپ صرف اجازت دینے کے لیے ٹرسٹ پالیسی کا دائرہ اختیار کر سکتے ہیں: production ماحول:

"token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:environment:production"

IAM کے تمام کرداروں پر کم از کم استحقاق کی اجازتوں کا اطلاق کریں۔

کبھی منسلک نہ کریں۔ AdministratorAccess یا PowerUserAccess CI/CD میں استعمال ہونے والے کردار۔ اپنی مرضی کی پالیسیوں کی وضاحت کریں جن میں صرف وہ کام شامل ہوں جو آپ کے ورک فلو کو درکار ہیں۔

ہر ماحول کے لیے الگ الگ IAM کردار بنائیں

سٹیجنگ رولز اور پروڈکشن رولز میں اجازت کے مختلف سیٹ ہونے چاہئیں۔ اسٹیجنگ تعیناتی کردار کو پیداواری وسائل تک تحریری رسائی نہیں ہونی چاہیے۔

AWS CloudTrail کو فعال کریں۔

عارضی اسناد کا استعمال کرتے ہوئے کی گئی تمام کالز CloudTrail میں فرض کردہ رول ARN کے ساتھ لاگ ان ہوتی ہیں۔ یہ AWS میں آپ کے ورک فلو کی کارکردگی کا مکمل آڈٹ ٹریل فراہم کرتا ہے۔

حوالہ: OIDC کے لیے GitHub کی آفیشل سخت گائیڈ: OpenID Connect کے ساتھ سیکیورٹی کو سخت کرنے کے بارے میں

عام غلطیوں کا ازالہ کرنا

غلطی: `Not authorized to perform sts:AssumeRoleWithWebIdentity`

اس کا عام طور پر مطلب یہ ہے کہ IAM کردار کی اعتماد کی پالیسی مماثل نہیں ہے۔ sub JWT سے دعویٰ۔

درج ذیل کو چیک کریں:

کہ sub حالت ریپوزٹری پاتھ سے بالکل میل کھاتی ہے (کیس حساس)۔
کہ aud شرائط درج ذیل ہیں: sts.amazonaws.com
کہ Federated موضوع درست AWS اکاؤنٹ ID استعمال کرتا ہے۔

آپ کے ورک فلو کو موصول ہونے والے اصل ٹوکن دعوے کا معائنہ کرنے کے لیے، عارضی طور پر درج ذیل ڈیبگ مرحلہ شامل کریں:

- name: Print OIDC token claims
  run: |
    TOKEN=((curl -s -H "Authorization: Bearer )ACTIONS_ID_TOKEN_REQUEST_TOKEN" 
      "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sts.amazonaws.com" | jq -r '.value')
    echo $TOKEN | cut -d '.' -f2 | base64 -d 2>/dev/null | jq .

غلطی: `Could not load credentials from any providers`

اس کا مطلب ہے تقریبا ہمیشہ۔ id-token: write ورک فلو کی اجازت نہیں ہے۔ براہ کرم درج ذیل کو دو بار چیک کریں:

permissions:
  id-token: write
  contents: read

غلطی: `AccessDenied` AWS سروسز کو کال کرتے وقت

توثیق کامیاب رہی، لیکن آپ کے IAM رول کو وہ کارروائی کرنے کی اجازت نہیں ہے جس کی ورک فلو کوشش کر رہا ہے۔ کردار کے ساتھ منسلک اجازتوں کی پالیسی کو چیک کریں اور غلطی کے پیغام میں مخصوص کارروائی سے اس کا موازنہ کریں۔

نتیجہ

ہم نے GitHub Secrets میں جامد، طویل المدت AWS اسناد کو ذخیرہ کرنے سے لے کر OIDC کا استعمال کرتے ہوئے مکمل طور پر بغیر کلیدی تصدیق کو ترتیب دیا۔ آپ نے جو حاصل کیا وہ یہاں ہے:

AWS نے GitHub کو ایک قابل اعتماد OIDC شناخت فراہم کنندہ کے طور پر رجسٹر کیا ہے۔
میں نے ایک مخصوص ریپوزٹری سے منسلک اسکوپڈ ٹرسٹ پالیسی کے ساتھ IAM رول بنایا ہے۔
آپ نے اس کردار کے ساتھ کم سے کم استحقاق کی اجازتیں منسلک کی ہیں۔
میں نے مختصر مدت کے AWS اسناد کی درخواست کرنے اور استعمال کرنے کے لیے ایک GitHub ایکشن ورک فلو ترتیب دیا۔
تصدیق کے بہاؤ کے اختتام سے آخر تک توثیق کی گئی۔

یہ پیٹرن تمام AWS سروسز پر کام کرتا ہے، بشمول S3، ECS، Lambda، ECR، اور Secrets Manager۔ یہاں ورک فلو کی مثال S3 کا استعمال کرتی ہے، لیکن آپ اسے اجازت کی پالیسی اور تعیناتی کمانڈ کو تبدیل کرکے کسی بھی سروس پر لاگو کرسکتے ہیں۔

اگر آپ مزید جاننا چاہتے ہیں تو اس پر ایک نظر ڈالیں:

اگر آپ DevOps پریکٹس بنا رہے ہیں اور انفراسٹرکچر آٹومیشن، CI/CD، اور پلیٹ فارم انجینئرنگ کے لیے ایک مکمل، پروڈکشن کے لیے تیار حوالہ چاہتے ہیں، تو چیک کریں: اسٹارٹ اپ DevOps فیلڈ گائیڈ. ہم حقیقی AWS ماحول میں استعمال ہونے والے نمونوں، ٹیمپلیٹس اور رن بکس کا احاطہ کرتے ہیں۔

آپ بھی مجھ سے رابطہ کر سکتے ہیں۔ لنکڈ