حذف secretهای بلندمدت از GitHub Actions با OIDC

OIDC به GitHub Actions اجازه می‌دهد بدون ذخیرهٔ credential بلندمدت، هویت workflow را به cloud provider ثابت کند و برای همان job یک access token کوتاه‌عمر بگیرد.

OIDC چیست و چه مسئله‌ای را حل می‌کند؟

OpenID Connect یا OIDC روشی است که به GitHub Actions اجازه می‌دهد بدون ذخیره‌کردن credential بلندمدت در secrets گیت‌هاب، هویت workflow را به یک ارائه‌دهندهٔ کلاد ثابت کند. در این مدل، GitHub برای هر اجرای مجاز یک توکن هویتی صادر می‌کند و سرویس کلاد، پس از بررسی claimها و policy اعتماد، یک access token کوتاه‌عمر تحویل می‌دهد. بنابراین secret دائمی که ممکن است ماه‌ها در مخزن باقی بماند، از مسیر deployment حذف می‌شود و دامنهٔ اثر نشت credential کاهش پیدا می‌کند.

چرا حذف secretهای بلندمدت مهم است؟

secretهای ثابت معمولاً در سطح repository یا organization نگهداری می‌شوند و اگر به‌اشتباه در log، action ثالث یا یک runner آلوده افشا شوند، مهاجم می‌تواند تا زمان لغو یا چرخش آن‌ها به منابع کلاد دسترسی داشته باشد. در مقابل، الگوی OIDC برای هر job یک هویت موقت می‌سازد. GitHub در راهنمای رسمی خود تأکید می‌کند که ارائه‌دهندهٔ کلاد باید حداقل یک شرط trust داشته باشد تا هر repository نتواند برای منابع حساس token بگیرد.

پیاده‌سازی امن OIDC در GitHub Actions

ابتدا در ارائه‌دهندهٔ کلاد یک identity provider برای issuer مربوط به GitHub بسازید و نقش یا service account محدودی تعریف کنید. شرط trust را فقط به repository، سازمان، branch، tag، event و environment موردنیاز محدود کنید. یک شرط کلی مانند «هر workflow از این سازمان مجاز است» دامنهٔ حمله را بی‌دلیل بزرگ می‌کند.

در workflow، مجوز دریافت توکن را در پایین‌ترین سطح ممکن، یعنی همان job، اضافه کنید:

“`yaml permissions: id-token: write contents: read “`

مجوز id-token: write به‌تنهایی اجازهٔ نوشتن در منابع کلاد نمی‌دهد؛ فقط به job اجازه می‌دهد توکن OIDC دریافت کند. سپس از action رسمی ارائه‌دهندهٔ کلاد استفاده کنید تا JWT گیت‌هاب را با access token کوتاه‌عمر مبادله کند. اگر action رسمی وجود ندارد، می‌توان با toolkit رسمی Actions توکن را درخواست و آن را به endpoint تبادل کلاد ارسال کرد.

کنترل‌های تکمیلی برای استقرار

اگر از environment استفاده می‌کنید، protection rule و محدودیت branch یا tag را فعال کنید. مجوزهای دیگر workflow را نیز به حداقل برسانید، actionهای ثالث را pin کنید و هرگز توکن دریافتی را در log چاپ نکنید. برای هر سرویس، audience، subject و نام environment را در policy صریح بنویسید و یک deployment آزمایشی را در محیط جدا اجرا کنید.

الگوی عملی برای حذف secretهای بلندمدت

برای شروع، یک workflow آزمایشی جدا از pipeline اصلی بسازید و فقط یک عملیات کم‌خطر مانند خواندن metadata یا انتشار artifact آزمایشی را به آن بسپارید. در همین مرحله مشخص کنید کدام repository و کدام branch باید هویت فدرال داشته باشد. سپس subject و audience را از توکن واقعی بررسی کنید و همان claimها را در policy اعتماد وارد کنید. این کار از پذیرش توکن‌هایی با منبع نامشخص جلوگیری می‌کند.

در گام بعد، نقش کلاد را به چند permission کوچک تقسیم کنید. نقش build نباید permission استقرار production داشته باشد و نقش production نیز نباید بتواند منابع نامرتبط را تغییر دهد. اگر چند حساب یا پروژه دارید، برای هرکدام provider و role جدا تعریف کنید. حذف secretهای بلندمدت زمانی قابل اتکا است که مسیر دسترسی جدید دقیقاً قابل مشاهده، قابل لغو و قابل آزمایش باشد.

در بازبینی نهایی، فهرست secretهای بلندمدت را از repository، organization و environment جداگانه استخراج کنید. برای هر secretهای بلندمدت مشخص کنید کدام job هنوز از آن استفاده می‌کند و آیا جایگزین OIDC همان رفتار را پوشش می‌دهد. secretهای بلندمدت بلااستفاده را پس از ثبت شواهد حذف کنید و برای secretهای بلندمدت باقی‌مانده، تاریخ انقضا و مالک مشخص بگذارید. هدف این نیست که فقط نام secretهای بلندمدت عوض شود؛ باید مسیر احراز هویت واقعاً به token کوتاه‌عمر منتقل شود.

برای تیم‌هایی که چند pipeline دارند، یک reusable workflow مرکزی می‌تواند الگوی مجوز، action رسمی login، بررسی environment و مدیریت خطا را یکسان کند. با این حال شرط trust نباید فقط به reusable workflow متکی باشد؛ repository فراخواننده، ref و environment نیز باید در policy کنترل شوند. مستندات راهنمای امنیت GitHub Actions در تکتاز را به‌عنوان نقطهٔ شروع داخلی کنار راهنمای رسمی نگه دارید و هر تغییر policy را در code review بررسی کنید.

همچنین لازم است رفتار failure روشن باشد. اگر صدور access token یا احراز هویت کلاد شکست خورد، job باید متوقف شود و به secret قدیمی fallback نکند؛ fallback پنهان می‌تواند باعث شود تیم تصور کند migration موفق بوده، در حالی که هنوز credential دائمی در حال استفاده است. logها باید نام role و شناسهٔ اجرای job را بدون نمایش مقدار token ثبت کنند تا عیب‌یابی ممکن بماند.

پیش از حذف secret قدیمی، اجرای واقعی build و deployment، rollback، دسترسی به artifactها و رفتار runner را بررسی کنید. پس از موفقیت، secret بلندمدت را از workflow و تنظیمات غیرضروری خارج کنید، rotation را ثبت کنید و logها را برای نشتی احتمالی بازبینی کنید. OIDC جایگزین policy دقیق نیست؛ امنیت واقعی زمانی حاصل می‌شود که هویت فدرال، least privilege، محیط محافظت‌شده و پایش رخدادها کنار هم قرار بگیرند.

منبع: GitHub Docs