کلید انتشار چرا نباید همیشگی باشد؟

در بسیاری از خط‌های انتشار، یک access key با عمر طولانی در secrets ذخیره می‌شود و هر اجرای workflow از همان کلید استفاده می‌کند. اگر کلید در جای دیگری کپی شود یا مجوزش بیش از نیاز باشد، دامنه رخداد بزرگ‌تر می‌شود. OIDC به GitHub Actions اجازه می‌دهد هویت اجرای جاری را به ارائه‌دهنده ابری معرفی کند و اعتبارنامه کوتاه‌عمر بگیرد. حذف کلید ثابت یک بهبود مهم است؛ اما جای تعریف درست نقش، محدود کردن اعتماد و بررسی خود workflow را نمی‌گیرد.

دو لایه را جدا بررسی کنید: trust policy مشخص می‌کند کدام اجرای GitHub می‌تواند نقش را بگیرد و permission policy مشخص می‌کند آن نقش در AWS چه کاری می‌تواند انجام دهد. id-token: write در YAML فقط اجازه دریافت توکن OIDC را می‌دهد؛ خود آن مجوز ساخت یا حذف منابع ابری نیست. در نمونه آموزشی، عملیات فقط خواندن هویت با sts get-caller-identity است. این انتخاب به شما فرصت می‌دهد مسیر اعتماد را بررسی کنید، پیش از آنکه فرمان واقعی انتشار یا تغییر زیرساخت را اضافه کنید.

اعتماد باید به کار مشخص محدود شود

در حساب آزمایشی، ارائه‌دهنده OIDC و نقش را مطابق مستندات پیکربندی کنید. aud باید با مخاطب مورد انتظار، مانند sts.amazonaws.com، و sub با مخزن و زمینه مجاز هماهنگ باشد. اگر job از environment نام‌گذاری‌شده استفاده می‌کند، مقدار sub شکل مربوط به environment دارد و با شکل branch تفاوت دارد. wildcard گسترده برای تمام مخزن‌ها مشکل را فقط از secrets به trust policy منتقل می‌کند. نقش انتشار را به پروژه و محیط مشخص محدود کنید و برای production محافظت environment و بازبینی لازم را تعیین کنید.

فرمان‌ها و actionها هم بخشی از مرز اعتمادند. نسخه action حساس را پس از بررسی به commit SHA ثابت متصل کنید و برنامه به‌روزرسانی آن را داشته باشید. در نمونه SHA آمده در مستندات رسمی را استفاده کرده‌ایم؛ ثابت بودن SHA نیاز به بررسی دوره‌ای را حذف نمی‌کند. workflow دریافت‌کننده توکن نباید ورودی کنترل‌نشده را مستقیم داخل فرمان shell قرار دهد. اجرای pull requestهای خارجی، مخصوصاً همراه با دسترسی محیط تولید، باید مسیر و مجوز جدا داشته باشد و با یک شرط ظاهری ناامن ترکیب نشود.

پیشنهاد تحریریه این است که سه سناریو را آزمایش کنید: اجرای مجاز، اجرای همان فایل از زمینه غیرمجاز و درخواست عملیاتی خارج از نقش. نتیجه دوم باید در گرفتن نقش و نتیجه سوم در مجوز ابری رد شود. اگر هر دو موفق‌اند، مرز اعتماد و سطح مجوز را دوباره بررسی کنید. توکن و اعتبارنامه موقت را در log ننویسید. گزارش اجرای سالم باید حساب و نقش مورد انتظار را نشان دهد و امکان ردیابی به commit منتشرشده فراهم باشد؛ برای این کار نیازی به نمایش خود کلید نیست.

نمونه کد و روش بررسی

این مثال آموزشی برای فهم مسیر پیاده‌سازی نوشته شده است. نسخه‌ها و پیش‌نیازهای ذکرشده را در محیط آزمایش بررسی کنید؛ نکات زیر مشخص می‌کنند برای استفاده عملی چه چیزهایی باید تکمیل شوند.

فقط بررسی هویت؛ مقدار role و منطقه را جایگزین کنید
name: Check AWS identity
on: workflow_dispatch
permissions:
  contents: read
jobs:
  identity:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Assume the reviewed AWS role
        uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-demo
          aws-region: eu-central-1
          role-session-name: github-identity-check
      - name: Inspect the caller
        run: aws sts get-caller-identity

این نمونه به role و OIDC provider از پیش ساخته‌شده نیاز دارد و بدون آن اجرا موفق نمی‌شود. برای environment=production مقدار sub باید repo:OWNER/REPO:environment:production باشد؛ aud در trust policy نیز sts.amazonaws.com است. مقادیر OWNER و REPO و ARN نمونه را جایگزین کنید. خروجی باید Account و Arn نقش مورد انتظار را نشان دهد. هیچ کلید ثابت AWS در YAML لازم نیست و این workflow چیزی منتشر نمی‌کند.

پیش از اولین انتشار چه چیزی را آزمایش کنیم؟

پس از موفقیت آزمون هویت، فرمان انتشار را با دامنه کوچک و artifact مشخص اضافه کنید. ابتدا مسیر برگشت و اثر شکست نیمه‌کاره را تعریف کنید، سپس اتصال را به production ببرید. سند نهایی باید نقش، محیط، شرایط اعتماد، صاحب workflow و روش لغو دسترسی را ثبت کند. اعتبارنامه کوتاه‌عمر مانع همه رخدادها نیست؛ اگر workflow در همان بازه مجاز فرمان اشتباه اجرا کند، اثر آن همچنان واقعی است. سود اصلی، کاهش عمر رازها و قابل بررسی شدن ارتباط میان یک اجرا و مجوز محدود آن است.

چک‌لیست اجرای عملی

  • در حساب آزمایشی، OIDC provider و role را قبل از YAML ایجاد کنید.
  • aud و sub را دقیق و متناسب با environment یا branch محدود کنید.
  • برای environment تولید، قواعد حفاظت و دسترسی مستقل تعیین کنید.
  • اجرا از زمینه غیرمجاز و عملیات بیرون از permission policy را تست کنید.

توضیح‌ها و پیشنهادهای اجرایی این مطلب، تحلیل تحریریه دانشنامه لیان هستند.منابع: GitHub — OIDC in AWS · GitHub — OpenID Connect · GitHub — Security hardening

این مطلب بازنویسی تحلیلی دانشنامه لیان بر پایه منبع اصلی است.مشاهده منبع اصلی