امن‌سازی داکر و هاردنینگ کوبرنتیز: راهنمای امنیت کانتینر

امن‌سازی داکر و هاردنینگ کوبرنتیز (Docker and Kubernetes Hardening) یعنی ایمن کردن تک‌تک لایه‌های پلتفرم کانتینر: ایمیج‌هایی که می‌سازید، میزبان و Runtime که آن‌ها را اجرا می‌کند، صفحه کنترل کوبرنتیز، خود بارهای کاری و شبکه و Secretهایی که آن‌ها را به هم وصل می‌کند. کانتینر به‌طور پیش‌فرض مرز امنیتی محکمی نیست؛ کانتینری که با کاربر root و Capabilityهای اضافه اجرا می‌شود یا Podی که به همه‌ی Podهای دیگر دسترسی دارد، مسیر مهاجم را از یک باگ ساده تا کل کلاستر کوتاه می‌کند.

کوبرنتیز با پیش‌فرض‌های منعطف عرضه می‌شود، نه سخت‌گیرانه. Podها می‌توانند با root اجرا شوند، هر Pod به هر Pod دیگری دسترسی دارد و Secretها تا وقتی رمزنگاری را فعال نکنید فقط با base64 کدگذاری می‌شوند. در این راهنما کنترل‌هایی را مرور می‌کنیم که این شکاف‌ها را می‌بندند؛ هم‌راستا با CIS Docker Benchmark، CIS Kubernetes Benchmark و استانداردهای Pod Security کوبرنتیز.

لایه‌های امنیت کانتینر در داکر و کوبرنتیز

امنیت کانتینر با رویکرد دفاع در عمق (Defense in Depth) بهترین نتیجه را می‌دهد؛ هر لایه، اگر لایه‌ی بالاتر شکست بخورد، دامنه‌ی کار مهاجم را محدود می‌کند.

لایه	ریسک رایج	کنترل‌های کلیدی
ایمیج	CVEهای شناخته‌شده، ایمیج پایه‌ی حجیم، Secret جاسازی‌شده	ایمیج حداقلی، اسکن، Digest ثابت، امضا
میزبان و Runtime	فرار از کانتینر، Docker Socket در معرض	کرنل وصله‌شده، حالت Rootless، بدون کانتینر Privileged
صفحه کنترل	دسترسی ناشناس به API، etcd بدون رمزنگاری	RBAC، لاگ ممیزی، TLS، رمزنگاری در حالت سکون
بار کاری	پردازه‌ی root، فایل‌سیستم قابل نوشتن	Pod Security Standards و securityContext
شبکه	حرکت جانبی بین Podها	NetworkPolicy با Default Deny

امن‌سازی ایمیج‌های کانتینر

هر بسته‌ی نرم‌افزاری داخل ایمیج یک سطح حمله‌ی بالقوه است. از Multi-stage Build استفاده کنید تا کامپایلر و ابزارهای Build هرگز به محیط عملیاتی نرسند و ایمیج نهایی را روی ایمیج پایه‌ی حداقلی یا Distroless بسازید.

FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app ./cmd/app

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /out/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

• ایمیج‌ها را در CI اسکن کنید و در صورت وجود آسیب‌پذیری High و Critical، Build را متوقف کنید؛ برای نمونه با trivy image --severity HIGH,CRITICAL --exit-code 1 registry.example.com/web:1.4.2.
• ایمیج‌های موجود در Registry را هم دوباره اسکن کنید؛ هر روز CVE جدید منتشر می‌شود.
• در مانیفست‌های محیط عملیاتی، ایمیج را با Digest ثابت کنید، نه با برچسب‌های تغییرپذیر مثل latest.
• ایمیج‌ها را امضا کنید و امضا را هنگام Admission بررسی کنید.
• هرگز رمز، توکن یا کلید را داخل لایه‌های ایمیج قرار ندهید.

امن‌سازی میزبان داکر و Runtime

میزبان کانتینر بین همه‌ی کانتینرهای روی آن مشترک است؛ پس امن‌سازی آن به اندازه‌ی خود کانتینرها اهمیت دارد. برای سیستم‌عامل پایه راهنمای هاردنینگ سرور لینوکس را دنبال کنید و سپس محدودیت‌های زمان اجرا را اعمال کنید:

docker run -d --name web \
  --read-only --tmpfs /tmp \
  --user 10001:10001 \
  --cap-drop ALL --cap-add NET_BIND_SERVICE \
  --security-opt no-new-privileges:true \
  --pids-limit 200 --memory 512m --cpus 1 \
  registry.example.com/web:1.4.2

• کانتینر را جز در صورت نبود هیچ راه دیگر، با --privileged یا Namespaceهای میزبان اجرا نکنید.
• هرگز /var/run/docker.sock را داخل کانتینر Mount نکنید؛ این کار معادل دسترسی root روی میزبان است.
• Daemon داکر را بدون TLS دوطرفه روی TCP در دسترس قرار ندهید.
• از حالت Rootless یا userns-remap استفاده کنید تا root داخل کانتینر، root میزبان نباشد.
• پروفایل‌های پیش‌فرض seccomp و AppArmor یا SELinux را فعال نگه دارید.

استانداردهای Pod Security و securityContext

کوبرنتیز سه سطح Pod Security Standards تعریف کرده است: privileged بدون محدودیت، baseline که جلوی ارتقای دسترسی شناخته‌شده مانند کانتینر Privileged، Namespaceهای میزبان و Volumeهای hostPath را می‌گیرد، و restricted که اجرای Non-root، حذف Capabilityها و الزام seccomp را هم اضافه می‌کند. کنترلر داخلی Pod Security Admission که جایگزین PodSecurityPolicy شده، این سطوح را با برچسب روی هر Namespace اعمال می‌کند:

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

یک Pod سازگار با سطح restricted به این شکل است:

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: payments
spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: web
      image: registry.example.com/web:1.4.2
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          cpu: "500m"
          memory: "512Mi"

Namespaceهای جدید را با سطح restricted شروع کنید و baseline را فقط برای بارهای کاری‌ای به کار ببرید که هنوز واقعاً نمی‌توانند با آن سازگار شوند.

RBAC، NetworkPolicy و مدیریت Secretها

RBAC با حداقل دسترسی

تا جای ممکن Role را در Namespace مشخص تعریف کنید، نه ClusterRole. از Wildcard پرهیز کنید، اتصال‌های cluster-admin را به حداقل برسانید و مجوزهایی مانند خواندن Secretها، pods/exec، escalate، bind و impersonate را دسترسی ممتاز بدانید. برای دیدن مجوزهای یک هویت از kubectl auth can-i --list --as=system:serviceaccount:payments:ci-bot -n payments استفاده کنید.

NetworkPolicy با Default Deny

بدون سیاست شبکه، هر Pod به هر Pod دیگری دسترسی دارد. در هر Namespace یک سیاست Default Deny بگذارید و فقط جریان‌های لازم را مجاز کنید. افزونه‌ی CNI شما باید از NetworkPolicy پشتیبانی کند و در قوانین Egress باید DNS را صراحتاً مجاز کنید.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Secretها

Secretهای کوبرنتیز با base64 کدگذاری می‌شوند، نه رمزنگاری. رمزنگاری در حالت سکون را با --encryption-provider-config روی API Server فعال کنید و ترجیحاً از ارائه‌دهنده‌ی KMS v2 استفاده کنید. دسترسی RBAC به Secretها را محدود کنید و برای اعتبارنامه‌های حساس از یک سامانه‌ی مدیریت Secret خارجی کمک بگیرید.

صفحه کنترل، Kubelet و ممیزی با CIS Benchmark

در کلاسترهای خودمدیریت این تنظیمات مستقیماً در اختیار شماست؛ در سرویس‌های مدیریت‌شده‌ی ابری، CIS Benchmark مخصوص همان ارائه‌دهنده را بررسی کنید تا بدانید چه بخشی بر عهده‌ی شماست.

مؤلفه	تنظیم	هدف
kube-apiserver	--anonymous-auth=false	رد درخواست‌های بدون احراز هویت
kube-apiserver	--authorization-mode=Node,RBAC	اعمال RBAC و مجوزدهی Node
kube-apiserver	--audit-policy-file و --audit-log-path	ثبت فعالیت‌های API
kube-apiserver	--profiling=false	غیرفعال کردن Endpointهای Profiling
etcd	--client-cert-auth=true و --peer-client-cert-auth=true	الزام گواهی کلاینت TLS
kubelet	authentication.anonymous.enabled: false	جلوگیری از دسترسی ناشناس به API کیوبلت
kubelet	authorization.mode: Webhook و readOnlyPort: 0	مجوزدهی درخواست‌ها و بستن پورت فقط‌خواندنی

ممیزی باید منظم و تکرارشونده باشد، نه یک‌باره:

1. kube-bench را روی نودهای صفحه کنترل و نودهای کاری اجرا کنید تا انطباق با CIS Kubernetes Benchmark سنجیده شود.
2. روی میزبان‌های مستقل داکر، Docker Bench for Security را اجرا کنید.
3. ایمیج‌های در حال اجرا و پیکربندی کلاستر را برای آسیب‌پذیری‌ها و پیکربندی‌های نادرست جدید اسکن کنید.
4. یافته‌ها را رفع کنید، بررسی‌ها را دوباره اجرا کنید و استثناها را با مالک و تاریخ بازبینی ثبت کنید.

نت‌گارد چگونه به امنیت کانتینر کمک می‌کند

نت‌گارد ایمیج‌های کانتینر را برای آسیب‌پذیری‌های شناخته‌شده اسکن می‌کند و پیکربندی کوبرنتیز را از نظر تنظیمات پرخطر مانند Podهای Privileged، نبود securityContext و دسترسی‌های بیش از حد بررسی می‌کند. پیکربندی میزبان‌ها و نودها با CIS Benchmark ممیزی می‌شود، تشخیص انحراف پیکربندی تغییراتی را که خط مبنای امن را تضعیف می‌کنند نشان می‌دهد و یافته‌ها بر اساس اطلاعات اکسپلویت و اهمیت دارایی اولویت‌بندی می‌شوند؛ اسکن مجدد هم رفع آن‌ها را تأیید می‌کند. گزارش‌ها به فارسی و انگلیسی ارائه می‌شوند. درباره‌ی ممیزی هاردنینگ بیشتر بخوانید یا با ما تماس بگیرید.

سوالات متداول

CIS Kubernetes Benchmark چیست؟

CIS Kubernetes Benchmark یک راهنمای پیکربندی اجماعی از مرکز امنیت اینترنت (CIS) است که تنظیمات پیشنهادی برای API Server، Controller Manager، Scheduler، etcd، Kubelet و سیاست‌هایی مانند RBAC و امنیت Pod را فهرست می‌کند. هر توصیه شامل روش ممیزی و روش اصلاح است. ابزارهایی مانند kube-bench بسیاری از این بررسی‌ها را به‌صورت خودکار انجام می‌دهند.

تفاوت سطح baseline و restricted در Pod Security چیست؟

سطح baseline جلوی روش‌های شناخته‌شده‌ی ارتقای دسترسی را می‌گیرد؛ یعنی کانتینر Privileged، Namespaceهای میزبان، Volumeهای hostPath و افزودن Capabilityهای خطرناک. سطح restricted همه‌ی این موارد را دارد و علاوه بر آن اجرای Non-root، ممنوعیت ارتقای دسترسی، حذف همه‌ی Capabilityها و تعیین پروفایل seccomp را الزامی می‌کند. برای بیشتر بارهای کاری برنامه‌ای، سطح restricted توصیه می‌شود.

آیا کانتینر باید با root اجرا شود؟

خیر. پردازه‌ای که داخل کانتینر با root اجرا می‌شود، در صورت وجود آسیب‌پذیری فرار از کانتینر یا پیکربندی نادرست، فاصله‌ی کمی تا root میزبان دارد. در ایمیج یک کاربر غیر root تعریف کنید، در کوبرنتیز runAsNonRoot را اجباری کنید، همه‌ی Capabilityها را حذف و ارتقای دسترسی را غیرفعال کنید. بیشتر برنامه‌ها بدون تغییر با کاربر غیر root اجرا می‌شوند.

آیا Secretهای کوبرنتیز رمزنگاری می‌شوند؟

به‌طور پیش‌فرض خیر. Secretها با کدگذاری base64 در etcd ذخیره می‌شوند و هر کسی که به etcd یا بکاپ آن دسترسی داشته باشد می‌تواند آن‌ها را بخواند. رمزنگاری در حالت سکون را با پیکربندی رمزنگاری روی API Server و ترجیحاً با ارائه‌دهنده‌ی KMS فعال کنید، دسترسی RBAC به Secretها را محدود کنید و etcd را با TLS و محدودیت دسترسی شبکه محافظت کنید.

چطور امنیت یک کلاستر کوبرنتیز را ممیزی کنیم؟

با kube-bench تنظیمات نودها و صفحه کنترل را با CIS Kubernetes Benchmark مقایسه کنید، اتصال‌های RBAC و NetworkPolicyها را بازبینی کنید و ایمیج‌های در حال اجرا را برای آسیب‌پذیری اسکن کنید. برچسب‌های Pod Security Admission را در همه‌ی Namespaceها بررسی کنید و لاگ ممیزی API را مرور کنید. این ممیزی را به‌طور منظم تکرار کنید، چون پیکربندی کلاستر و ایمیج‌ها دائماً تغییر می‌کنند.