پینترست RPP: خط‌لوله متمرکز و امن برای Terraform در مقیاس

پینترست موتور اجرای Terraform خود را تحت عنوان Resource Provisioner Pipeline (RPP) پیاده‌سازی کرده تا مدیریت هزاران منبع AWS را تحت یک سیاست امنیتی واحد قرار دهد. این سامانه با تمرکز بر نگاشت workspaceها به نقش‌های محدود و اجرای مدل OIDC-محور برای فرض نقش‌ها، دسترسی را به حداقل لازم کاهش می‌دهد و اجرای تغییرات را به مراحل جداگانهٔ قابل حسابرسی تقسیم می‌کند.

چرا RPP لازم بود؟

کدهای Terraform پینترست در صدها مخزن پراکنده است و هر تیم مالک بخش خود است. تا زمان تکمیل مهاجرت به مونو-ریپو، اعطای مجوزهای گسترده به سیستم‌های CI/CD خطر پیکربندی نادرست و سوءاستفاده را افزایش می‌دهد. RPP برای امن‌سازی همین ساختار چندمخزنی طراحی شده تا نیازی به انتظار برای مهاجرت کامل نباشد.

معماری و جریان اجرای RPP

خط‌لوله به‌صورت مجموعه‌ای از GitHub Actions مرکزی اجرا می‌شود و روی رویدادهای Pull Request فعال می‌گردد. به‌جای اجرای اسکریپت در هر مخزن، یک PR به اجراهای مجزا برای هر workspace تبدیل می‌شود. مراحل کلیدی عبارت‌اند از:

• نقش مرکزی اجرا: یک workflow نقش RPPActionsRole را برعهده می‌گیرد که فقط به گردش‌کارهای مجاز از طریق اعتبارسنجی OIDC اجازه می‌دهد.
• خواندن منبع حقیقت: فایل source-of-truth برای هر workspace مخزن مجاز، دایرکتوری کاری، تیم مالک و نقش IAM اجرایی را نگاشت می‌کند.
• اعتبارسنجی بک‌اند: پیش از کاهش دامنه دسترسی، RPP تطابق مسیر کد Terraform با بک‌اند S3 و کلید KMS مشخص برای همان workspace را بررسی می‌کند تا از لینک شدن اشتباه state جلوگیری شود.
• فرض نقش با دسترسی محدود: پس از اعتبارسنجی بک‌اند، خط‌لوله نقش تیم مربوطه را می‌پذیرد و دستوراتی مانند terraform fmt و terraform plan را اجرا می‌کند.
• کنترل دوگانه برای اعمال تغییرات: مرحلهٔ apply تنها پس از یک کامنت انسانی در PR و تایید یک بازبین مجاز در مخزن مالک انجام می‌شود؛ به این ترتیب plan و apply به اقدامات جداگانه و قابل حسابرسی تبدیل می‌شوند.

ویژگی‌های محافظتی و ابزارهای کمکی

تأکید اصلی روی اعتبارسنجی بک‌اند (S3 + KMS) است؛ این گام از فساد یا اشتباه در اشتراک state بین workspaceها جلوگیری می‌کند. دیگر قابلیت‌های مهم عبارت‌اند از:

• استفاده از composite actions برای اجرای یکنواخت بررسی‌ها در تمام PRها (مراجعه به مستندات GitHub Actions).
• آنالیز ایستا با قوانین سفارشی Semgrep و اسکن‌های همیار با هوش مصنوعی.
• اجرای شبیه‌سازی اختیاری با LocalStack برای آزمایش رفتار AWS پیش از تأثیرگذاری روی حساب‌های واقعی.

اهمیت الگو برای تیم‌های دیگر

نگاشت مسیر workspace به نقش به همراه اعتبارسنجی بک‌اند و فرض نقش با دامنهٔ کاهش‌یافته، یک الگوی عملی برای تیم‌هایی است که ساختار چندمخزنی دارند. این الگو اصل حداقل اختیارات را در خطوط‌لوله PR-محور پیاده می‌کند، بدون نیاز فوری به انتقال کامل به مونو-ریپو.

مقایسه با دیگر راهکارها

سایر شرکت‌ها راه‌حل‌های متفاوتی اتخاذ کرده‌اند و هیچ نسخهٔ واحدی مناسب همه نیست:

• Mercari: با مونو-ریپوی Terraform مواجه شد و از حساب‌های «plan» فقط خواندنی و حساب‌های «apply» مخصوص هر سرویس به‌همراه امپرسونیشن در GCP استفاده کرد.
• Slack: مالکیت state را به تیم‌ها واگذار کرد ولی قاعدهٔ plan سپس apply را حفظ نمود تا تغییرات ابتدا در محیط‌های sandbox و توسعه آزمایش شوند.

RPP با افزودن گام صریح اعتبارسنجی بک‌اند و کلید KMS پیش از فرض نقش، یک لایهٔ محافظتی اضافی ایجاد می‌کند و خطر تبدیل خط‌لوله متمرکز IaC به یک نقطهٔ واحد شکست را کاهش می‌دهد.

محدودیت‌ها و موارد قابل توجه

RPP فعلاً داخلی و خصوصی است و متن‌باز نشده. با این حال اصول معماری—زنجیره‌سازی نقش‌ها با OIDC، نگاشت منبع حقیقت و اعتبارسنجی بک‌اند—قابل بازتولید برای دیگر تیم‌هاست. سازمان‌هایی که هنوز به مونو-ریپو مهاجرت نکرده‌اند می‌توانند از این الگو برای افزایش امنیت و شفافیت خطوط‌لوله Terraform بهره ببرند.

نگاهی به آینده

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

منابع و مطالعه بیشتر: مستندات رسمی GitHub Actions، صفحهٔ Terraform در ویکی‌پدیا، ابزار Semgrep و LocalStack.