امنیت در Kubernetes: راهنمای جامع برای حفاظت از کلاسترها

مقدمه

Kubernetes امروز به یکی از پرکاربردترین پلتفرم‌های ارکستراسیون کانتینرها تبدیل شده است. شرکت‌های بزرگ و کوچک از آن برای مدیریت سرویس‌های میکروسرویسی و اپلیکیشن‌های پیچیده استفاده می‌کنند. اما در کنار تمام مزایای آن، یک واقعیت مهم وجود دارد: هرچه معماری پیچیده‌تر باشد، سطح حملات هم گسترده‌تر می‌شود.

امنیت Kubernetes فقط به معنی جلوگیری از دسترسی غیرمجاز نیست؛ بلکه شامل کنترل دسترسی کاربران، ایزوله‌سازی شبکه، محدود کردن سطح دسترسی پادها، اطمینان از سلامت ایمیج‌ها و رعایت ده‌ها نکته دیگر است. اگر حتی یکی از این لایه‌ها ضعیف باشد، ممکن است مهاجم بتواند به‌سرعت از یک آسیب‌پذیری کوچک به دسترسی کامل روی کل کلاستر برسد.

در مقاله قبلی به معرفی این که Kubernetes چیست و چه کاربردی دارد پرداختیم. در این مقاله به صورت گام‌به‌گام با مهم‌ترین اصول امنیتی در Kubernetes آشنا می‌شویم.

چرا امنیت در Kubernetes اهمیت دارد؟

Kubernetes شامل اجزای متعددی مثل kubelet، API Server، etcd، Scheduler و کنترلرهاست. این اجزا به‌طور مداوم با یکدیگر در ارتباط هستند.

اگر یک مهاجم موفق شود به هرکدام از این بخش‌ها دسترسی پیدا کند، می‌تواند:

• داده‌های حساس (مثل Secrets) را سرقت کند.
• سرویس‌ها را از دسترس خارج کند.
• منابع سرور را مصرف و حمله DoS اجرا کند.
• حتی کل کلاستر را به کنترل خود درآورد.

بنابراین امنیت در Kubernetes یک موضوع جانبی یا انتخابی نیست؛ بلکه یک ضرورت است.

۱. کنترل دسترسی با RBAC (Role-Based Access Control)

اولین قدم در امنیت Kubernetes کنترل دسترسی کاربران و سرویس‌ها به منابع است.

با RBAC می‌توانید مشخص کنید:

• چه کسی یا چه سرویس‌اکانتی
• به چه منبعی
• با چه سطح دسترسی (خواندن، نوشتن، حذف و غیره)

اصول کلیدی RBAC:

• استفاده از Role و RoleBinding برای namespaceهای خاص.
• استفاده از ClusterRole و ClusterRoleBinding برای منابع سراسری.
• رعایت اصل Least Privilege (کمترین سطح دسترسی لازم).

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
  

۲. ایزوله‌سازی شبکه با Network Policies

به‌طور پیش‌فرض، همه پادها در یک namespace می‌توانند با هم ارتباط داشته باشند. این موضوع یک خطر امنیتی جدی است.

با NetworkPolicy می‌توانید قوانین دقیقی برای ارتباط پادها تعریف کنید. مثلاً:

• فقط پادهای frontend بتوانند با پادهای backend ارتباط برقرار کنند.
• هیچ پادی نتواند بدون مجوز به دیتابیس متصل شود.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
  

۳. محدود کردن سطح دسترسی پادها با Security Context

اگر یک کانتینر در حالت پیش‌فرض (با دسترسی root) اجرا شود، در صورت نفوذ، مهاجم دسترسی کاملی روی نود میزبان خواهد داشت.

برای جلوگیری از این مشکل باید از Security Context استفاده کنید:

• اجرای پادها به‌صورت non-root
• غیرفعال کردن privilege mode
• استفاده از فایل‌سیستم فقط‌خواندنی

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  

۴. استفاده از Pod Security Standards (PSS)

Kubernetes از نسخه‌های جدیدتر مکانیزم Pod Security Admission را معرفی کرده است که سه سطح امنیتی دارد:

• Privileged: بدون محدودیت (فقط برای تست)
• Baseline: محدودیت‌های پایه برای جلوگیری از تنظیمات خطرناک
• Restricted: سطح امنیتی بالا، مناسب محیط‌های Production

با فعال‌سازی PSS در namespaceها می‌توانید مطمئن شوید هیچ پادی خارج از قوانین تعریف‌شده اجرا نشود.

۵. جلوگیری از استفاده از تصاویر ناسالم (Untrusted Images)

یکی از رایج‌ترین راه‌های نفوذ در Kubernetes، استفاده از کانتینرهایی است که از ریجستری‌های نامطمئن دانلود می‌شوند.

راهکارها:

• فقط از ریجستری‌های امن استفاده کنید (مثلاً Harbor).
• از امضای دیجیتال imageها با ابزارهایی مثل Cosign یا Notary استفاده کنید.
• ایمیج‌ها را قبل از اجرا با ابزارهای اسکن امنیتی مثل Trivy یا Clair بررسی کنید.

نتیجه‌گیری

امنیت در Kubernetes یک فرآیند چندلایه است. هیچ ابزاری به‌تنهایی نمی‌تواند کل کلاستر شما را امن کند. بهترین روش این است که با ترکیب چندین لایه امنیتی (RBAC، Network Policy، Security Context، Pod Security Standards و استفاده از ایمیج‌های امن) ریسک حملات را به حداقل برسانید.

به خاطر داشته باشید: امنیت Kubernetes یک پروژه یک‌باره نیست؛ باید به‌طور مداوم بررسی، به‌روزرسانی و تست شود. هر تغییر کوچک در معماری، می‌تواند روی امنیت تأثیر بگذارد.