چرا نباید Container ها به طور پیش‌فرض با دسترسی Root اجرا شوند؟

اجرای container ها با دسترسی root یکی از شایع‌ترین — و خطرناک‌ترین — تنظیمات نادرست در محیط‌های production است. این کار به آرامی سطح حمله هر workload را افزایش می‌دهد، و بیشتر تیم‌ها متوجه این مسئله نمی‌شوند تا زمانی که یک incident مسئله را بیرون بیاورد.

معنی واقعی «اجرا با دسترسی Root»

به طور پیش‌فرض، بسیاری از container image ها (به‌خصوص image های minimal یا legacy) فرآیند اصلی خود را با UID 0 در داخل container اجرا می‌کنند. از آن‌جا که container ها kernel میزبان را با سایر container ها و خود میزبان به اشتراک می‌گذارند، root در داخل یک container با root روی یک ماشین مجازی کاملاً جدا یکی نیست — اما این هنوز بسیار قدرتمندتر از آن چیزی است که باید باشد. اگر مهاجم کد را با موفقیت در یک container مالکیت root اجرا کند، به موارد زیر دسترسی پیدا می‌کند:

• دسترسی کامل خواندن/نوشتن به هر فایلی که در container mount شده است، صرف‌نظر از مجوزهای در نظر گرفته شده
• توانایی نصب package ها، تغییر binaries یا دستکاری وضعیت برنامه
• راه بسیار ساده‌تری برای خروج از container اگر آسیب‌پذیری kernel یا runtime قابل استفاده باشد
• اهرم بیشتری هنگام ترکیب با volume های غلط تنظیم‌شده، مثل Docker socket یا host filesystem path mount شده

حتی بدون exploit kernel، دسترسی root در داخل container شعاع انفجار هر آسیب‌پذیری سطح برنامه را (SSRF، deserialization bugs، arbitrary file write و غیره) به شدت افزایش می‌دهد.

چرا این در محیط‌های Orchestrated بیشتر مهم است

در Kubernetes clusters، یک container root به همراه Linux capabilities بیش‌ازحد یا security context فراگیر می‌تواند به مهاجم اجازه دهد:

• /proc یا /sys را به شیوه‌ای تغییر دهد که بر میزبان تاثیر بگذارد
• اگر hostPID، hostNetwork یا hostIPC فعال باشند، امتیاز را افزایش دهند
• یک service account token mount شده را سوء استفاده کنند تا به طور افقی در سرتاسر cluster حرکت کنند
• اگر privileged: true تنظیم شده یا capabilities خطرناک مانند SYS_ADMIN داده شده باشند، به node فرار کنند

خود کاربر root نه‌تنها آسیب‌پذیری نیست — ترکیب root به همراه Linux capabilities بیش‌ازحد، host mounts یا namespace sharing است که یک compromise محدود را به یک cluster-wide تبدیل می‌کند.

مراحل Hardening عملی

1. یک کاربر غیر-Root در Image تنظیم کنید

به طور صریح یک کاربر غیر-root را در Dockerfile خود تعریف کنید تا بر پیش‌فرض‌ها تکیه نکنید:

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

2. آن را در سطح Orchestrator اجرا کنید

فقط بر image متکی نباشید — سیاست را در runtime اجرا کنید. در Kubernetes، از یک securityContext استفاده کنید:

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

runAsNonRoot: true باعث می‌شود که pod در صورتی که image سعی کند با UID 0 اجرا شود، در admission ناکام شود، و به شما یک تضمین سخت بدل از یک convention best-effort می‌دهد.

3. Capabilities غیر ضروری را Drop کنید

بیشتر برنامه‌ها نیازی به هیچ‌یک از Linux capabilities پیش‌فرض داده شده به container ندارند. همه چیز را drop کنید و فقط آن چه کاملاً ضروری است را اضافه کنید (موارد نادری مثل binding به low ports ممکن است به NET_BIND_SERVICE نیاز داشته باشند).

4. Privileged Mode و Host Namespace Sharing را جلوگیری کنید

privileged: true، hostNetwork: true و hostPID: true باید برای workload های خاص infrastructure (مثل برخی از CNI یا monitoring agents) محفوظ باشند — هرگز برای general application containers.

5. با Policy Tools Scan و Enforce کنید

از admission controllers یا policy engines استفاده کنید (مثل Kyverno، OPA/Gatekeeper) تا به طور خودکار deployments را که از این قوانین تخطی می‌کنند reject کنید، بجای اعتماد به manual code review. این را با image scanning در CI جفت کنید تا root-user images را قبل از اینکه به cluster برسند دستگیر کنید.

یک Defense Layered، نه Perfect

اجرای non-root نمی‌تواند ریسک را به طور کامل حذف کند — kernel-level container escapes مستقل از in-container user وجود دارند — اما یک کلاس بزرگ از تکنیک‌های escalation privilege و lateral movement با تلاش کم را حذف می‌کند. در ترکیب با read-only filesystems، dropped capabilities و restrictive network policies، یکی از ارزان‌ترین و مؤثرترین لایه‌ها در استراتژی defense-in-depth container security را تشکیل می‌دهد.

می‌خواهید بیشتر درباره hardening cloud-native workloads بدانید؟ بخش‌های مرتبط Korra Studio را درباره Cloud security و DevOps pipeline hardening کاوش کنید تا بقیه استراتژی defense-in-depth خود را بسازید.