OIDC بدل AWS keys في GitHub Actions: امسح الـ secrets الثابتة من الـ CI

الـ AWS_SECRET_ACCESS_KEY اللي قاعد في GitHub Secrets من سنتين… لو اتسرّب النهارده، هيفضل شغّال لحد ما حد يفتكر يلغيه. ده الجزء ٣٦ من «Full Stack Tips»، وموضوعه إزاي تشيل الـ access keys الثابتة من الـ CI خالص وتستخدم OIDC بدلها.

الفكرة في سطرين

بدل مفتاح عايش للأبد، كل تشغيل للـ workflow بياخد token موقّع من GitHub، و AWS بتتأكد منه وتبدّله بـ مفاتيح مؤقتة. يعني مفيش secret محفوظ أصلًا يتسرّب، ولو الـ token نفسه اتسرق، بيبطل لوحده لما مدته تخلص.

ليه دلوقتي؟

يوم 22 أكتوبر 2026 Vercel نشرت إنها عملت survey لأكتر من 1,000 SaaS vendor، ولقت إن 8.4% بس منهم بيدعموا طرق auth آمنة. وقالت إنها هتحط علامة «Not secure» على الـ vendors اللي من غير OIDC في الـ Marketplace بتاعها بحلول 30 نوفمبر 2026. الاتجاه واضح: الـ static credentials بقت تتعامل كـ ثغرة، مش كـ عادة.

الخطوات (من docs GitHub الرسمية)

1. ضيف GitHub كـ OIDC provider في IAM

الـ provider URL هو:

https://token.actions.githubusercontent.com

والـ audience هو sts.amazonaws.com لو بتستخدم الـ action الرسمي.

2. اقفل الـ role بشرط sub في الـ trust policy

ده أهم سطر في الموضوع كله. الشرط بيحدد أنهي repo وأنهي branch مسموح لها تاخد الـ role:

"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"

ولو الـ job شغال في environment، الشرط يبقى بالشكل ده:

repo:ORG/REPO:environment:prod

3. اسمح للـ job يطلب الـ token

permissions:
  id-token: write
  contents: read

الـ id-token: write مش بتدي صلاحية كتابة على أي resource، هي بس بتسمح للـ job يطلب الـ OIDC token.

4. استخدم role-to-assume بدل الـ keys

استخدم aws-actions/configure-aws-credentials وادّيله الـ role-to-assume بتاع الـ role اللي عملته، بدل aws-access-key-id و aws-secret-access-key. وبعد ما تتأكد إن الـ pipeline شغال، امسح الـ secrets القديمة وعطّل الـ access keys من IAM.

خلي بالك من الحاجات دي

• من غير شرط sub أي repo تقدر تطلب token من GitHub ممكن تاخد الـ role بتاعك. ده مش تفصيلة، ده الفرق بين أمان حقيقي ووهم أمان.
• الـ repos الجديدة: الـ repos اللي اتعملت بعد 15 يوليو 2026 (أو اللي فعّلت immutable subject claims) الـ sub فيها بيبقى فيه IDs، زي repo:octo-org@123456/octo-repo@456789:…، فلازم تطابق الـ trust policy مع الشكل ده وإلا الـ assume هيفشل.
• الـ environments: لو بتستخدمها في الشرط، ضيف لها protection rules عشان محدش يقدر يشغّل deploy على prod من غير مراجعة.

رأيي

مش لازم تحوّل كل حاجة في يوم. ابدأ بأخطر مفتاح عندك، وغالبًا ده مفتاح الـ deploy على production. حوّله لـ OIDC، اتأكد إن الـ pipeline شغال، امسح المفتاح القديم، وبعدين كمّل على الباقي واحد واحد. كل access key ثابت بتمسحه هو حاجة أقل ممكن تتسرّب.

لسه عندك access keys ثابتة في الـ CI؟ كام واحد؟

المصادر

• GitHub Docs: Configuring OpenID Connect in Amazon Web Services
• Vercel: Death to long-lived static credentials