WIUNIX ACADEMY
آزمایش NetworkPolicy در Kubernetes؛ منع پیش‌فرض با دسترسی محدود به DNS و API
در یک فضای نام تازه و دورریختنی، هم مسیر مجاز و هم مسیر ممنوع را آزمایش کنید تا اجرای واقعی سیاست شبکه و دسترسی DNS روشن شود.
محیطت را انتخاب کنآموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من4 مقدار قابل‌تغییر
از اینجا شروع کن
در پایان چه چیزی خواهی داشت؟
برای یک محیط آزمایش مستقل، سیاست منع پیش‌فرض بسازید و با آزمون‌های مثبت و منفی نشان دهید فقط کلاینت منتخب به API می‌رسد و DNS مورد نیاز برقرار می‌ماند.
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده
فرمان‌ها و تفاوت‌های محیط‌های منتخب با مستندات رسمی بررسی شده‌اند؛ این بررسی به معنای اجرای عملی روی همهٔ سیستم‌ها یا سرویس شما نیست. فرم فعلی نام‌های ساده تا ۳۲کاراکتر را می‌پذیرد؛ این محدودیت فرم است، نه Kubernetes. اگر نام واقعی طولانی‌تر است، مقدار نمونه را کپی نکنید؛ فرمان را در ویرایشگر خودتان با نام کامل تنظیم کنید. نام منبع را تغییر ندهید.
قبل از شروع
- تأیید مسئول کلاستر و مستندات CNI مبنی بر پشتیبانی از اجرای NetworkPolicy.
- مجوز ساخت یک فضای نام تازه و منابع آزمایش؛ این تمرین روی فضای نام مشترک یا محیط عملیاتی انجام نمی‌شود.
- ایمیج‌های سرور و ابزار با شناسهٔ محتوایی ثابت و تأیید امنیتی؛ نام‌های قابل خواندن نمونه، تأیید زنجیرهٔ تأمین نیستند.
قدم بعدی
ابزار میزبان انتخاب‌شده را آماده کنید
ابزارهای لازم را روی کامپیوتر یا سروری آماده کنید که فرمان‌های مدیریتی را از آن اجرا می‌کنید. پیش از تأیید، فهرست تغییر بسته‌ها را بخوانید؛ داخل کانتینر برنامه ابزار نصب نکنید. کلاستر، سرویس و باینری‌های اصلی باید از قبل با نسخهٔ مورد تأیید موجود باشند. پنل‌های بعد را در Bash اجرا کنید. نصب بسته روی همین میزبان تغییر ایجاد می‌کند، اما سرور برنامهٔ تازه‌ای راه نمی‌اندازد.
از kubectl لینوکسیِ موجود استفاده کنید که اختلاف آن با همهٔ نسخه‌های API Server حداکثر یک نسخهٔ فرعی باشد. پیش از ادامه نسخهٔ سرور را در کانتکست مجاز ببینید. برای این عیب‌یابی kubelet یا kubeadm نصب نکنید و مخزن بستهٔ کلاینت را بازنویسی نکنید.
میزبان انتخاب‌شده؛ نصب بسته فقط با مجوز تغییر همین میزبان
sudo dnf install ca-certificates bash coreutils
if ! command -v curl >/dev/null 2>&1; then sudo dnf install curl; fi
cat /etc/os-release
command -v bash curl timeout
command -v kubectl
kubectl version --client --output=yamlنسخهٔ سیستم با انتخاب شما یکسان باشد، ابزارها پیدا شوند و نسخهٔ کلاینت و سرویس با شرایط بالا سازگار باشند. اگر باینری موجود نیست یا سازگار نیست، ادامه ندهید.
حفاظت میزبان و مسیرهای نصب موجود را حفظ کنید
SELinux را در حالت enforcing و قواعد firewalld را فعال نگه دارید. ابزار کلاینت به خروجی مجازِ API، TLS یا SFTP نیاز دارد و پورت ورودی تازه‌ای لازم نیست. نتیجهٔ سرویس محدودشدهٔ systemd ممکن است با اجرای تعاملی فرق داشته باشد. خطای AVC، برچسب فایل و مجوز سرویس را با مسئول سیاست بررسی کنید؛ خاموش‌کردن SELinux یا دیوارهٔ آتش و مجوز گسترده راه‌حل نیست. خطای زنجیرهٔ اعتماد یا سیاست رمزنگاری به مقصد سازگار نیاز دارد، نه ضعیف‌کردن حفاظت سیستم. مسیر داده و پیکربندی سفارشی باید برچسب مناسب فعلی را حفظ کند؛ بازبرچسب‌گذاری بازگشتیِ کورکورانه انجام ندهید.
میزبان انتخاب‌شده؛ فقط خواندن وضعیت حفاظت
if command -v getenforce >/dev/null 2>&1; then getenforce; fi
if command -v firewall-cmd >/dev/null 2>&1; then firewall-cmd --state; fiپذیرفته‌شدن سیاست در API، اجرای آن را ثابت نمی‌کند
CNI باید NetworkPolicy را اجرا کند. در پیاده‌سازی فاقد پشتیبانی، ممکن است API شیء را بپذیرد ولی ترافیک باز بماند. مجوزهای سیاست‌های استاندارد با هم جمع می‌شوند؛ محدودیت یک سیاست، مجوز سیاست دیگر را لغو نمی‌کند: مجوز گسترده در سیاستی دیگر می‌تواند همان ارتباط را باز کند. اگر هر دو سمت محدود شده‌اند، خروجی مبدأ و ورودی مقصد هر دو باید ارتباط را مجاز کنند.
فقط در فضای نام تازه و مخصوص همین تمرین کار کنید. Podهای نمونه از شبکهٔ میزبان استفاده نمی‌کنند؛ ارتباط برنامه TCP/HTTP است و قاعدهٔ DNS به Podهای CoreDNS اشاره می‌کند. NodeLocal DNSCache و لایه‌های اختصاصی ارائه‌دهنده به قواعد دیگری نیاز دارند.
قدم بعدی
پشتیبانی CNI و آزادبودن نام محیط را بررسی کنید
پیش از شروع، مستندات CNI و اجازهٔ مسئول کلاستر را بررسی کنید. آزمون نبود فضای نام باید NotFound برگرداند؛ اگر منبع وجود دارد، نام تازه‌ای انتخاب کنید. Forbidden یا خطای ارتباط، اثبات نبود منبع نیست. ایمیج‌های پنل بعد را با نسخه‌های تأییدشده و ثابت جایگزین کنید و رفتار پورت و فرمان آن‌ها را حفظ کنید.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
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 روشن باشد و فضای نام هنوز وجود نداشته باشد.
قدم بعدی
فایل منابع آزمایش را بدون بازنویسی فایل موجود بسازید
از پوشهٔ کاری تازه استفاده کنید. ساخت انحصاری فایل جلوی بازنویسی اتفاقی فایل پیشین را می‌گیرد. پنل بعد محتوای YAML است؛ پیش از فرستادن به API آن را بازبینی کنید. درخواست و سقف منابع اندازهٔ آزمایش را محدود می‌کنند، اما بی‌خطر بودن ایمیج را ثابت نمی‌کنند.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
umask 077
mkdir '/tmp/academy-netpol' && cd '/tmp/academy-netpol' || exit 1
(set -C; : > lab.yaml) || exit 1
${EDITOR:-vi} lab.yamlفایل تازه برای بازبینی آماده باشد و هیچ فایل موجودی جایگزین نشده باشد.
قدم بعدی
نقش سرور، کلاینت مجاز و کلاینت نامجاز را جدا کنید
همهٔ Podها در فضای نام تازه ساخته می‌شوند. نقش سرور با ابزار آزمون متفاوت است. قبل از اجرا، ارجاع ایمیج‌ها را به نسخهٔ ثابت و تأییدشده تغییر دهید و پورت‌ها و رفتار فرمان را حفظ کنید. ابزار BusyBox منتظر می‌ماند تا هر درخواست آزمایشی، اتصال تازه‌ای ایجاد کند.
محتوای فایل؛ در مسیر درج‌شده ذخیره کنید
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}
سه نقش با برچسب‌های روشن و منابع محدود در فایل تعریف شده باشند؛ هنوز تغییری در کلاستر ایجاد نشده است.