GitHub Actions OIDC مع AWS: انشر بدون مفاتيح ثابتة

مستوى القارئ: متوسط

هتطلع من المقال ده بإعداد عملي يخلي GitHub Actions يدخل AWS بصلاحية مؤقتة، بدل ما تخزن Access Key وSecret Key يعيشوا شهور في GitHub Secrets.

المشكلة باختصار

الطريقة الشائعة إنك تعمل IAM User، تطلع منه مفاتيح، وتحطها في GitHub Secrets. الطريقة دي بتشتغل، لكنها بتفشل في نقطة مهمة: السر طويل العمر. لو اتسرّب في log، artifact، fork workflow، أو جهاز مطور، هيبقى عندك مفتاح صالح لحد ما تكتشف وتعمل rotate.

الافتراض هنا إن عندك repository بيعمل deploy إلى S3 أو ECS أو Lambda من GitHub Actions. عندك فريق من 3 إلى 10 مطورين، وبتشغل من 20 إلى 100 workflow شهريًا. في الحالة دي OIDC بيقلل سطح المخاطرة لأن كل run بياخد token قصير العمر من GitHub، ثم AWS STS يبدله credentials مؤقتة مرتبطة بـ IAM Role.

الفكرة ببساطة

ركز في التشبيه ده. بدل ما تدي عامل التوصيل مفتاح البيت، بتدي له تصريح دخول مرة واحدة للبوابة، مربوط بعنوان محدد ووقت محدد. لو التصريح اتصور أو اتنسخ، قيمته محدودة جدًا لأنه ينتهي سريعًا ومينفعش يستخدمه أي شخص من شارع تاني.

بالظبط ده اللي بيحصل مع OIDC. GitHub يصدر JWT للـ workflow. AWS لا يثق في GitHub كله بشكل مفتوح. AWS يراجع شرطين مهمين: aud لازم تكون sts.amazonaws.com، وsub لازم يطابق repo وbranch أو environment محدد. GitHub نفسه يوضح إن OIDC يسمح للـ workflows بالوصول إلى AWS بدون تخزين credentials طويلة العمر، وإن workflow محتاج id-token: write لطلب التوكن. مصدر: GitHub Docs - OIDC in AWS.

الإعداد العملي

أول خطوة تعمل OIDC provider في AWS. الأمر ده يضيف GitHub كـ identity provider. استخدمه مرة واحدة لكل AWS account غالبًا.

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

بعدها اعمل IAM Role بسياسة ثقة مقفولة على repo وbranch. غير 123456789012 وahmedhaies/my-app حسب مشروعك.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:ahmedhaies/my-app:ref:refs/heads/main"
        }
      }
    }
  ]
}

الشرط المهم هنا هو sub. من غيره، أنت بتوسع الثقة زيادة عن اللزوم. GitHub وaws-actions بينبهوا لنفس النقطة: لازم تحدد مين يقدر يعمل assume للـ role، ويفضل تضييقها على repo وbranch أو environment. مصدر: aws-actions/configure-aws-credentials.

آخر خطوة تضيف workflow. لاحظ إن id-token: write لا يعني إن GitHub يقدر يكتب على repo. ده بس يسمح للـ job يطلب OIDC token.

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

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v6.1.0
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
          aws-region: eu-central-1

      - name: Verify identity
        run: aws sts get-caller-identity

القياس والـ trade-off

قبل OIDC، عندك مفتاح IAM ممكن يعيش 90 يوم أو سنة حسب سياسة الفريق. بعد OIDC، كل تشغيل بياخد credentials مؤقتة من STS. لو workflow اتسرب منه token، نافذة الاستغلال بتبقى بالدقائق أو مدة الجلسة، بدل شهور. الرقم العملي هنا: بدل ما تعمل rotation شهري لـ 4 أسرار في 4 repositories، هتدير IAM Role واحد وسياسة ثقة واحدة لكل بيئة.

الـ trade-off هنا واضح. بتكسب أمان أعلى وتقليل rotation اليدوي. بتخسر بعض البساطة في البداية، لأنك محتاج تفهم claims زي aud وsub وتراجع IAM trust policy. لو عندك 5 repositories، وقت الإعداد الأول ممكن ياخد 60 إلى 90 دقيقة. بعدها الصيانة أقل من إدارة مفاتيح ثابتة.

في سيناريو واقعي: شركة صغيرة عندها deploy يومي إلى S3 وCloudFront. قبل OIDC عندها مفتاح deploy محفوظ في GitHub Secrets. لو مطور شغل command غلط وطبع environment variables، الخطر كبير. مع OIDC، مفيش secret ثابت يتطبع أصلًا. اللي بيظهر هو credentials مؤقتة مربوطة بالـ run وصلاحيات role محددة.

متى لا تستخدم هذه الطريقة

لا تستخدم OIDC كأول خطوة لو مشروعك محلي فقط ومفيش deploy إلى cloud. لا تستخدمه بدون تضييق sub على repo وbranch أو environment، لأنك ساعتها تنقل المشكلة من secret ثابت إلى trust policy واسعة. كمان لو عندك legacy CI لا يدعم OIDC، ممكن تحتاج حل مؤقت باستخدام IAM user مع rotation قصير وleast privilege لحد ما تنقل الـ pipeline.

مصادر اعتمد عليها المقال

• GitHub Docs: Configuring OpenID Connect in Amazon Web Services
• GitHub Docs: About security hardening with OpenID Connect
• aws-actions/configure-aws-credentials official README

الخطوة التالية

افتح آخر workflow بيعمل deploy إلى AWS، وشوف هل فيه AWS_ACCESS_KEY_ID وAWS_SECRET_ACCESS_KEY. لو موجودين، انقل أول بيئة غير حرجة إلى OIDC، وشغل aws sts get-caller-identity كاختبار قبل أي deploy فعلي.