‏این‌جوری Cilium زنجیره تأمین CI/CD رو امن نگه می‌داره

این اولین پست از یه سری سه‌قسمتیه که André Martins و Feroz Salam از تیم Cilium نوشتن. به گفتهٔ نویسنده‌ها، یه سال گذشته برای زنجیره تأمین متن‌باز سخت بوده: از آلوده شدن پکیج Axios روی npm و هایجک شدن LiteLLM روی PyPI گرفته تا فورک‌های typosquat‌شدهٔ Trivy و البته نمونهٔ کلاسیک حملهٔ SolarWinds در سال ۲۰۲۰. چون Cilium تو مسیر شبکهٔ سطح کرنل میلیون‌ها پاد Kubernetes اجرا می‌شه، اگه زنجیره تأمینش لو بره دامنهٔ آسیبش کوچیک نیست. این قسمت روی کنترل دسترسی تمرکز داره.

اولین لایه یه بات داخلیه به اسم Ariane که ورک‌فلوهای CI رو از روی کامنت‌های PR اجرا می‌کنه. وقتی یه نگه‌دارنده تو پول‌ریکوئست چیزی مثل /test یا /ci-eks می‌نویسه، Ariane اول چک می‌کنه که کامنت‌گذار عضو تیم سازمانه، بعد می‌فهمه کدوم ورک‌فلوها باید اجرا بشن (با وابستگی‌هاشون، مثل بیلد ایمیج که باید قبلش انجام بشه) و اونا رو دیسپچ می‌کنه. نکتهٔ اصلیش یه allow-list دستیه: فقط اعضای تأییدشده می‌تونن تریگر بزنن و مجموعهٔ ورک‌فلوهای مجاز هم تو کانفیگ دستی فهرست شده.

allowed-teams:
  - organization-members

triggers:
  /test:
    workflows:
      - conformance-aws-cni.yaml
      - conformance-eks.yaml
    depends-on:
      - /build-images-dependency

به این ترتیب یه آدم ناشناس از بیرون که تو PR بنویسه /test نادیده گرفته می‌شه و نمی‌تونه سوییت‌های گرون‌قیمت کلود رو راه بندازه یا دقیقه‌های CI رو بسوزونه.

بخش دوم دربارهٔ جدا کردن کد قابل‌اعتماد از کد ناشناسه. وقتی یکی PR باز می‌کنه باید کدش بیلد بشه ولی نمی‌شه بهش اعتماد کرد؛ این همون مشکل معروف pull_request_target هست. نویسنده‌ها می‌گن تا جایی که بشه ازش دوری می‌کنن، ولی چند ورک‌فلو بهش نیاز دارن و دور اونا کنترل‌های محافظتی گذاشتن. ورک‌فلوی بیلد ایمیج چک‌اوت رو دو تیکه می‌کنه: اول شاخهٔ پایه (کد بازبینی‌شده و مرج‌شده) رو می‌گیره تا اکشن‌های کامپوزیت و منطق امضای Cosign از یه منبع مطمئن لود بشن، و فقط بعدش شاخهٔ PR رو چک‌اوت می‌کنه که اون هم صرفاً به‌عنوان context برای docker build استفاده می‌شه، نه به‌عنوان اسکریپتی که اجرا بشه.

نویسنده‌ها توضیح می‌دن چرا این الگو با وجود اینکه اسکنرها بهش گیر می‌دن، تو حالت اونا امنه: هیچ مرحلهٔ run: اسکریپتی از چک‌اوت ناشناس اجرا نمی‌کنه، هیچ اکشن کامپوزیتی از اون لود نمی‌شه، و BuildKit که Dockerfile ناشناس رو اجرا می‌کنه تو ایزولاسیون کامله؛ بدون دسترسی به متغیرهای محیطی اکشنز، secretها یا اعتبارنامهٔ داکر رانر. تنها دادهٔ ناشناسی که جلوتر می‌ره فایل runtime-image به اکشن قابل‌اعتماد set-runtime-image داده می‌شه که چک می‌کنه ارجاع ایمیج با quay.io/cilium/ شروع شه و خطوط جدید رو پاک می‌کنه تا کسی نتونه از طریق GITHUB_ENV تزریق کنه.

به گفتهٔ نویسنده‌ها بدترین حالت یه بیلد PR آلوده اینه که یه ایمیج CI مخرب تو رجیستری توسعه (-ci) بشینه، چون لاگین داکر فقط با اعتبارنامهٔ CI انجام می‌شه و اعتبارنامهٔ پروداکشن اصلاً روی رانر نیست. لایهٔ آخر هم CODEOWNERS هست: هر چیزی زیر مسیر .github/ مالکیتش دست تیم امنیت CI و تیم ساختار CIه، پس هیچ‌کس نمی‌تونه پایپ‌لاین رو بدون بازبینی صریح اون تیم‌ها عوض کنه. نویسنده‌ها می‌گن قسمت دوم به سفت کردن وابستگی‌ها (اکشن‌های پین‌شده با SHA و وندورینگ ماژول‌های Go) می‌پردازه.

نکات کلیدی:

• بات داخلی Ariane با یه allow-list دستی مشخص می‌کنه کی و چه ورک‌فلوهایی رو می‌تونه از کامنت PR تریگر کنه
• ورک‌فلوهای pull_request_target چک‌اوت رو دو تیکه می‌کنن تا کد ناشناس هیچ‌وقت به‌عنوان اسکریپت اجرا نشه
• BuildKit کد ناشناس رو تو ایزولاسیون و بدون دسترسی به secretها و اعتبارنامه‌ها بیلد می‌کنه
• فقط اعتبارنامهٔ CI روی رانره؛ اعتبارنامهٔ پروداکشن اصلاً در دسترس نیست
• CODEOWNERS باعث می‌شه تغییر کانفیگ CI حتماً از زیر دست تیم امنیت رد شه