کنٹینرز کو ڈیفالٹ کے طور پر روٹ کے طور پر کیوں نہیں چلایا جائے؟

کنٹینرز کو روٹ کے طور پر چلانا پروڈکشن ماحول میں سب سے عام — اور سب سے زیادہ خطرناک — غلط ترتیبات میں سے ایک ہے۔ یہ ہر کام کے سطح پر حملے کی سطح کو خاموشی سے بڑھاتا ہے، اور زیادہ تر ٹیموں کو اس کا احساس نہیں ہوتا جب تک کہ کوئی واقعہ مسئلے کو سامنے نہ لے آئے۔

"روٹ کے طور پر چلنا" درست طور پر کیا مطلب ہے

ڈیفالٹ کے طور پر، بہت سے کنٹینر امیجز (خاص طور پر کم سے کم یا پرانے) اپنے مرکزی عمل کو کنٹینر کے اندر UID 0 کے طور پر چلاتے ہیں۔ چونکہ کنٹینرز دوسرے کنٹینرز اور ہوسٹ کے ساتھ ہوسٹ کرنل کو شیئر کرتے ہیں، کنٹینر کے اندر روٹ مکمل طور پر الگ تھلگ ورچوئل مشین میں روٹ جیسا نہیں ہے — لیکن یہ ابھی بھی اس سے بہت زیادہ طاقتور ہے۔ اگر ایک حملہ آور روٹ سے تعلق رکھنے والے کنٹینر کے اندر کوڈ کی تنفیذ حاصل کرتا ہے، تو وہ حاصل کرتے ہیں:

• کنٹینر میں شامل کی گئی کسی بھی فائل تک مکمل ریڈ/رائٹ رسائی، مطلوبہ اختیارات سے قطع نظر
• پیکجز انسٹال کرنے، بائنریز میں ترمیم کرنے، یا ایپلیکیشن کی حالت میں ہیرا پھیری کرنے کی صلاحیت
• کنٹینر براکآؤٹ کی طرف ایک بہت آسان راستہ اگر کوئی کرنل یا رن ٹائم کی کمزوری قابل استحصال ہے
• غلط طریقے سے ترتیب دیے گئے والیومز کے ساتھ ملا کر اضافی اثر، جیسے ایک شامل ڈاکر ساکٹ یا ہوسٹ فائل سسٹم کا راستہ

کرنل کے استحصال کے بغیر بھی، کنٹینر کے اندر روٹ رسائی کسی بھی ایپلیکیشن سطح کی کمزوری (SSRF، deserialization کے بگ، درخواست فائل لکھنا وغیرہ) کے دھماکے کی رفتار کو ڈرامائی طور پر بڑھاتی ہے۔

یہ Orchestrated ماحول میں زیادہ اہم کیوں ہے

Kubernetes کلسٹرز میں، ایک روٹ کنٹینر جو بہت زیادہ Linux صلاحیتوں یا اجازت دینے والی سیکیورٹی سیاق و سباق کے ساتھ ہو، ایک حملہ آور کو اجازت دے سکتا ہے:

• /proc یا /sys میں ترمیم کرنے کی طریقے سے جو ہوسٹ کو متاثر کریں
• اختیارات کو بڑھانے کی اگر hostPID، hostNetwork، یا hostIPC فعال ہوں
• کلسٹر میں لیٹرلی محور کرنے کے لیے ایک شامل سروس اکاؤنٹ ٹوکن کو بدستور استعمال کریں
• نوڈ سے بچنے اگر privileged: true سیٹ ہو یا خطرناک صلاحیتیں جیسے SYS_ADMIN دی گئی ہوں

روٹ یوزر خود ہی ہمیشہ کمزوری نہیں ہوتا — یہ ترکیب ہے روٹ کے علاوہ بہت سخاوتمند کرنل کی صلاحیتوں، ہوسٹ ماؤنٹس، یا namespace شیئرنگ کی جو ایک محدود سمجھوتے کو کلسٹر کے وسیع پیمانے پر بنا دیتی ہے۔

عملی سخت بنانے کی اقدامات

1. امیج میں غیر روٹ صارف سیٹ کریں

ڈیفالٹ پر انحصار کرنے کی بجائے اپنے Dockerfile میں واضح طور پر غیر روٹ صارف کی تعریف کریں:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. اسے Orchestrator سطح پر نافذ کریں

صرف امیج پر اعتماد نہ کریں — رن ٹائم میں پالیسی کو نافذ کریں۔ Kubernetes میں، securityContext استعمال کریں:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true pod کو ناکام کر دیتا ہے داخلے پر اگر امیج UID 0 کے طور پر چلنے کی کوشش کرے، آپ کو ایک سخت ضمانت دیتے ہوئے بہترین کوشش کے روایتی کے بجائے۔

3. غیر ضروری صلاحیتوں کو ڈراپ کریں

زیادہ تر ایپلیکیشنوں کو کنٹینرز کو دی گئی ڈیفالٹ Linux صلاحیتوں میں سے کوئی بھی ضرورت نہیں ہے۔ سب کچھ ڈراپ کریں اور صرف وہی شامل کریں جو بند و بست ضروری ہے (نایاب معاملات جیسے کم پورٹس سے منسلک ہونے کے لیے NET_BIND_SERVICE کی ضرورت ہو سکتی ہے)۔

4. Privileged موڈ اور ہوسٹ Namespace شیئرنگ سے بچیں

privileged: true، hostNetwork: true، اور hostPID: true بہت خاص بنیادی ڈھانچے کے کاموں کے لیے محفوظ رکھے جانے چاہیں (جیسے کچھ CNI یا نگرانی والے ایجنٹ) — عام ایپلیکیشن کنٹینرز کے لیے کبھی نہیں۔

5. Policy Tools کے ساتھ Scan اور نافذ کریں

داخلہ کنٹرولرز یا policy engines استعمال کریں (مثال کے طور پر، Kyverno، OPA/Gatekeeper) تاکہ خودکار طور پر ان اصولوں کی خلاف ورزی کرنے والی تعیناتیوں کو مسترد کریں، دستی کوڈ کی نظرثانی پر انحصار کرنے کی بجائے۔ اسے CI میں امیج اسکیننگ کے ساتھ جوڑیں تاکہ روٹ یوزر امیجز کو کلسٹر تک پہنچنے سے پہلے پکڑ لیں۔

ایک Layered، مکمل نہیں، دفاع

غیر روٹ کے طور پر چلنا خطرے کو مکمل طور پر ختم نہیں کرتا — کرنل سطح کے کنٹینر escapes کنٹینر کے اندر صارف سے قطع نظر موجود ہیں — لیکن یہ کم کوشش والی سہولت میں اضافے اور لیٹرل موومنٹ تکنیکوں کی ایک بہت بڑی فہرست کو ہٹاتا ہے۔ صرف پڑھنے والے فائل سسٹم، ڈراپ کی گئی صلاحیتوں، اور پابندی والی نیٹ ورک پالیسیوں کے ساتھ ملا کر، یہ دفاع میں گہرائی والی کنٹینر سیکیورٹی حکمت عملی میں سب سے سستے اور موثر تہوں میں سے ایک بنتا ہے۔

کلاؤڈ نیٹیو کام کے سخت بنانے پر گہرائی میں جانا چاہتے ہیں؟ Korra Studio کے شعبوں کو Cloud سیکیورٹی اور DevOps پائپ لائن سخت بنانے پر تلاش کریں تاکہ اپنی بقیہ دفاع میں گہرائی والی حکمت عملی کو بہتر بنایا جائے۔