کارشناس زن در فضای آموزشی سیاست شبکهٔ Kubernetes

WIUNIX ACADEMY

آزمایش NetworkPolicy در Kubernetes؛ منع پیش‌فرض با دسترسی محدود به DNS و API

در یک فضای نام تازه و دورریختنی، هم مسیر مجاز و هم مسیر ممنوع را آزمایش کنید تا اجرای واقعی سیاست شبکه و دسترسی DNS روشن شود.

پیشرفته45 دقیقه مطالعهبه‌روزرسانی
محیطت را انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Debian 13بررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من4 مقدار قابل‌تغییر

از اینجا شروع کن

در پایان چه چیزی خواهی داشت؟

برای یک محیط آزمایش مستقل، سیاست منع پیش‌فرض بسازید و با آزمون‌های مثبت و منفی نشان دهید فقط کلاینت منتخب به API می‌رسد و DNS مورد نیاز برقرار می‌ماند.

سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

فرمان‌ها و تفاوت‌های محیط‌های منتخب با مستندات رسمی بررسی شده‌اند؛ این بررسی به معنای اجرای عملی روی همهٔ سیستم‌ها یا سرویس شما نیست. فرم فعلی نام‌های ساده تا ۳۲کاراکتر را می‌پذیرد؛ این محدودیت فرم است، نه Kubernetes. اگر نام واقعی طولانی‌تر است، مقدار نمونه را کپی نکنید؛ فرمان را در ویرایشگر خودتان با نام کامل تنظیم کنید. نام منبع را تغییر ندهید.

قبل از شروع

  • تأیید مسئول کلاستر و مستندات CNI مبنی بر پشتیبانی از اجرای NetworkPolicy.
  • مجوز ساخت یک فضای نام تازه و منابع آزمایش؛ این تمرین روی فضای نام مشترک یا محیط عملیاتی انجام نمی‌شود.
  • ایمیج‌های سرور و ابزار با شناسهٔ محتوایی ثابت و تأیید امنیتی؛ نام‌های قابل خواندن نمونه، تأیید زنجیرهٔ تأمین نیستند.
01

قدم بعدی

ابزار میزبان انتخاب‌شده را آماده کنید

ابزارهای لازم را روی کامپیوتر یا سروری آماده کنید که فرمان‌های مدیریتی را از آن اجرا می‌کنید. پیش از تأیید، فهرست تغییر بسته‌ها را بخوانید؛ داخل کانتینر برنامه ابزار نصب نکنید. کلاستر، سرویس و باینری‌های اصلی باید از قبل با نسخهٔ مورد تأیید موجود باشند. پنل‌های بعد را در Bash اجرا کنید. نصب بسته روی همین میزبان تغییر ایجاد می‌کند، اما سرور برنامهٔ تازه‌ای راه نمی‌اندازد.

از kubectl لینوکسیِ موجود استفاده کنید که اختلاف آن با همهٔ نسخه‌های API Server حداکثر یک نسخهٔ فرعی باشد. پیش از ادامه نسخهٔ سرور را در کانتکست مجاز ببینید. برای این عیب‌یابی kubelet یا kubeadm نصب نکنید و مخزن بستهٔ کلاینت را بازنویسی نکنید.

bash

میزبان انتخاب‌شده؛ نصب بسته فقط با مجوز تغییر همین میزبان

sudo apt-get update
sudo apt-get install --no-install-recommends ca-certificates curl bash coreutils
cat /etc/os-release
command -v bash curl timeout
command -v kubectl
kubectl version --client --output=yaml
از کجا بدانم درست انجام شد؟

نسخهٔ سیستم با انتخاب شما یکسان باشد، ابزارها پیدا شوند و نسخهٔ کلاینت و سرویس با شرایط بالا سازگار باشند. اگر باینری موجود نیست یا سازگار نیست، ادامه ندهید.

حفاظت میزبان و مسیرهای نصب موجود را حفظ کنید

در Ubuntu و Debian ممکن است AppArmor و قواعد دیوارهٔ آتش میزبان فعال باشند. این روند پورت ورودی باز نمی‌کند و پروفایل امنیتی را تغییر نمی‌دهد. اگر دسترسی فایل یا شبکه رد شد، لاگ و سیاست سرویس را با مسئول آن بررسی کنید. مسیر نصب واقعی را حفظ کنید؛ مسیرهای نمونهٔ فرم، کشف خودکار محل نصب نیستند.

پذیرفته‌شدن سیاست در API، اجرای آن را ثابت نمی‌کند

CNI باید NetworkPolicy را اجرا کند. در پیاده‌سازی فاقد پشتیبانی، ممکن است API شیء را بپذیرد ولی ترافیک باز بماند. مجوزهای سیاست‌های استاندارد با هم جمع می‌شوند؛ محدودیت یک سیاست، مجوز سیاست دیگر را لغو نمی‌کند: مجوز گسترده در سیاستی دیگر می‌تواند همان ارتباط را باز کند. اگر هر دو سمت محدود شده‌اند، خروجی مبدأ و ورودی مقصد هر دو باید ارتباط را مجاز کنند.

فقط در فضای نام تازه و مخصوص همین تمرین کار کنید. Podهای نمونه از شبکهٔ میزبان استفاده نمی‌کنند؛ ارتباط برنامه TCP/HTTP است و قاعدهٔ DNS به Podهای CoreDNS اشاره می‌کند. NodeLocal DNSCache و لایه‌های اختصاصی ارائه‌دهنده به قواعد دیگری نیاز دارند.

02

قدم بعدی

پشتیبانی CNI و آزادبودن نام محیط را بررسی کنید

پیش از شروع، مستندات CNI و اجازهٔ مسئول کلاستر را بررسی کنید. آزمون نبود فضای نام باید NotFound برگرداند؛ اگر منبع وجود دارد، نام تازه‌ای انتخاب کنید. Forbidden یا خطای ارتباط، اثبات نبود منبع نیست. ایمیج‌های پنل بعد را با نسخه‌های تأییدشده و ثابت جایگزین کنید و رفتار پورت و فرمان آن‌ها را حفظ کنید.

bash

خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید

kubectl config get-contexts 'lab'
kubectl --context='lab' get namespace 'academy-lab'
kubectl --context='lab' -n kube-system get pods -l k8s-app=kube-dns --show-labels
kubectl --context='lab' auth can-i create namespaces
از کجا بدانم درست انجام شد؟

مقصد و مجوز درست باشند، پشتیبانی CNI روشن باشد و فضای نام هنوز وجود نداشته باشد.

03

قدم بعدی

فایل منابع آزمایش را بدون بازنویسی فایل موجود بسازید

از پوشهٔ کاری تازه استفاده کنید. ساخت انحصاری فایل جلوی بازنویسی اتفاقی فایل پیشین را می‌گیرد. پنل بعد محتوای YAML است؛ پیش از فرستادن به API آن را بازبینی کنید. درخواست و سقف منابع اندازهٔ آزمایش را محدود می‌کنند، اما بی‌خطر بودن ایمیج را ثابت نمی‌کنند.

bash

خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید

umask 077
mkdir '/tmp/academy-netpol' && cd '/tmp/academy-netpol' || exit 1
(set -C; : > lab.yaml) || exit 1
${EDITOR:-vi} lab.yaml
از کجا بدانم درست انجام شد؟

فایل تازه برای بازبینی آماده باشد و هیچ فایل موجودی جایگزین نشده باشد.

04

قدم بعدی

نقش سرور، کلاینت مجاز و کلاینت نامجاز را جدا کنید

همهٔ Podها در فضای نام تازه ساخته می‌شوند. نقش سرور با ابزار آزمون متفاوت است. قبل از اجرا، ارجاع ایمیج‌ها را به نسخهٔ ثابت و تأییدشده تغییر دهید و پورت‌ها و رفتار فرمان را حفظ کنید. ابزار BusyBox منتظر می‌ماند تا هر درخواست آزمایشی، اتصال تازه‌ای ایجاد کند.

yaml · /tmp/academy-netpol/lab.yaml

محتوای فایل؛ در مسیر درج‌شده ذخیره کنید

apiVersion: v1
kind: Pod
metadata:
  name: api
  namespace: academy-lab
  labels: {app: api}
spec:
  containers:
  - name: web
    image: registry.k8s.io/e2e-test-images/agnhost:2.53
    args: [netexec, --http-port=8080]
    ports: [{containerPort: 8080}]
    resources:
      requests: {cpu: 10m, memory: 32Mi}
      limits: {cpu: 200m, memory: 128Mi}
---
apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: academy-lab
spec:
  selector: {app: api}
  ports: [{port: 8080, targetPort: 8080}]
---
apiVersion: v1
kind: Pod
metadata:
  name: client
  namespace: academy-lab
  labels: {role: client}
spec:
  containers:
  - name: tools
    image: busybox:1.37
    command: [sh, -c, 'sleep 86400']
    resources:
      requests: {cpu: 5m, memory: 8Mi}
      limits: {cpu: 100m, memory: 32Mi}
---
apiVersion: v1
kind: Pod
metadata:
  name: stranger
  namespace: academy-lab
  labels: {role: stranger}
spec:
  containers:
  - name: tools
    image: busybox:1.37
    command: [sh, -c, 'sleep 86400']
    resources:
      requests: {cpu: 5m, memory: 8Mi}
      limits: {cpu: 100m, memory: 32Mi}
از کجا بدانم درست انجام شد؟

سه نقش با برچسب‌های روشن و منابع محدود در فایل تعریف شده باشند؛ هنوز تغییری در کلاستر ایجاد نشده است.

همهٔ آموزش‌های آکادمی ↗