سیکورٹی پروفیشنلز کے لیے Kubernetes نیٹ ورک کی پالیسیوں کا ایک تعارف

نوٹ. ترجمہ: مضمون کے مصنف، ریوین ہیریسن، سافٹ ویئر ڈیولپمنٹ میں 20 سال سے زیادہ کا تجربہ رکھتے ہیں، اور آج سیکیورٹی پالیسی مینجمنٹ سلوشنز بنانے والی کمپنی Tufin کے CTO اور شریک بانی ہیں۔ جب کہ وہ Kubernetes نیٹ ورک کی پالیسیوں کو کلسٹر میں نیٹ ورک کی تقسیم کے لیے کافی طاقتور ٹول کے طور پر دیکھتے ہیں، وہ یہ بھی مانتے ہیں کہ عملی طور پر ان کا نفاذ اتنا آسان نہیں ہے۔ یہ مواد (کافی بڑا) اس مسئلے کے بارے میں ماہرین کی آگاہی کو بہتر بنانے اور ضروری کنفیگریشنز بنانے میں ان کی مدد کرنا ہے۔

آج، بہت سی کمپنیاں تیزی سے اپنی ایپلی کیشنز چلانے کے لیے Kubernetes کا انتخاب کر رہی ہیں۔ اس سافٹ ویئر میں دلچسپی اتنی زیادہ ہے کہ کچھ لوگ Kubernetes کو "ڈیٹا سینٹر کے لیے نیا آپریٹنگ سسٹم" کہہ رہے ہیں۔ آہستہ آہستہ، Kubernetes (یا k8s) کو کاروبار کے ایک اہم حصے کے طور پر سمجھا جانے لگا ہے، جس کے لیے نیٹ ورک سیکیورٹی سمیت بالغ کاروباری عمل کی تنظیم کی ضرورت ہوتی ہے۔

سیکورٹی کے پیشہ ور افراد کے لیے جو Kubernetes کے ساتھ کام کر کے حیران ہیں، حقیقی انکشاف پلیٹ فارم کی ڈیفالٹ پالیسی ہو سکتی ہے: ہر چیز کی اجازت دیں۔

یہ گائیڈ آپ کو نیٹ ورک کی پالیسیوں کے اندرونی ڈھانچے کو سمجھنے میں مدد کرے گا۔ سمجھیں کہ وہ باقاعدہ فائر وال کے قوانین سے کیسے مختلف ہیں۔ یہ کچھ خرابیوں کا بھی احاطہ کرے گا اور کوبرنیٹس پر محفوظ ایپلیکیشنز میں مدد کے لیے سفارشات فراہم کرے گا۔

Kubernetes نیٹ ورک کی پالیسیاں

Kubernetes نیٹ ورک پالیسی میکانزم آپ کو پلیٹ فارم پر نیٹ ورک پرت (OSI ماڈل میں تیسرا) پر تعینات ایپلی کیشنز کے تعامل کا انتظام کرنے کی اجازت دیتا ہے۔ نیٹ ورک کی پالیسیوں میں جدید فائر والز کی کچھ جدید خصوصیات کا فقدان ہے، جیسا کہ OSI Layer 7 نفاذ اور خطرے کا پتہ لگانا، لیکن وہ نیٹ ورک سیکیورٹی کی بنیادی سطح فراہم کرتی ہیں جو کہ ایک اچھا نقطہ آغاز ہے۔

نیٹ ورک کی پالیسیاں پوڈ کے درمیان مواصلات کو کنٹرول کرتی ہیں۔

Kubernetes میں کام کے بوجھ کو پوڈز میں تقسیم کیا جاتا ہے، جو ایک یا زیادہ کنٹینرز پر مشتمل ہوتے ہیں جو ایک ساتھ تعینات ہوتے ہیں۔ Kubernetes ہر پوڈ کو ایک IP ایڈریس تفویض کرتا ہے جو دوسرے pods سے قابل رسائی ہے۔ Kubernetes نیٹ ورک کی پالیسیاں پوڈز کے گروپس کے لیے اسی طرح رسائی کے حقوق متعین کرتی ہیں جس طرح کلاؤڈ میں سیکیورٹی گروپس کو ورچوئل مشین کے واقعات تک رسائی کو کنٹرول کرنے کے لیے استعمال کیا جاتا ہے۔

نیٹ ورک کی پالیسیوں کی وضاحت

دیگر Kubernetes وسائل کی طرح، نیٹ ورک کی پالیسیاں YAML میں متعین ہیں۔ ذیل کی مثال میں، درخواست balance تک رسائی postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(نوٹ. ترجمہ: یہ اسکرین شاٹ، اس کے بعد کے تمام ملتے جلتے لوگوں کی طرح، مقامی Kubernetes ٹولز کا استعمال کرتے ہوئے نہیں بلکہ Tufin Orca ٹول کا استعمال کرتے ہوئے بنایا گیا تھا، جسے اصل مضمون کے مصنف کی کمپنی نے تیار کیا تھا اور جس کا ذکر مواد کے آخر میں کیا گیا ہے۔)

آپ کی اپنی نیٹ ورک پالیسی کی وضاحت کرنے کے لیے، آپ کو YAML کے بنیادی علم کی ضرورت ہوگی۔ یہ زبان انڈینٹیشن پر مبنی ہے (ٹیبز کے بجائے خالی جگہوں سے مخصوص)۔ ایک حاشیہ دار عنصر اس کے اوپر قریب ترین حاشیہ دار عنصر سے تعلق رکھتا ہے۔ فہرست کا ایک نیا عنصر ہائفن سے شروع ہوتا ہے، باقی تمام عناصر کی شکل ہوتی ہے۔ کلیدی قدر.

YAML میں پالیسی بیان کرنے کے بعد، استعمال کریں۔ کیوبیکٹلاسے کلسٹر میں بنانے کے لیے:

kubectl create -f policy.yaml

نیٹ ورک پالیسی کی تفصیلات

Kubernetes نیٹ ورک پالیسی کی تفصیلات میں چار عناصر شامل ہیں:

1. podSelector: اس پالیسی (اہداف) سے متاثرہ پوڈز کی وضاحت کرتا ہے - مطلوبہ؛
2. policyTypes: اس بات کی نشاندہی کرتا ہے کہ اس میں کس قسم کی پالیسیاں شامل ہیں: داخل اور/یا اخراج - اختیاری، لیکن میں اسے تمام صورتوں میں واضح طور پر بیان کرنے کی تجویز کرتا ہوں؛
3. ingress: اجازت کی وضاحت کرتا ہے۔ آنے والی ٹارگٹ پوڈز پر ٹریفک - اختیاری؛
4. egress: اجازت کی وضاحت کرتا ہے۔ سبکدوش ہونے والے ٹارگٹ پوڈز سے ٹریفک اختیاری ہے۔

Kubernetes ویب سائٹ سے لی گئی مثال (میں نے تبدیل کر دیا ہے۔ role پر app)، دکھاتا ہے کہ چاروں عناصر کیسے استعمال ہوتے ہیں:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: db
  policyTypes:    # <<<
  - Ingress
  - Egress
  ingress:        # <<<
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:         # <<<
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

براہ کرم نوٹ کریں کہ تمام چار عناصر کو شامل کرنے کی ضرورت نہیں ہے۔ یہ صرف لازمی ہے۔ podSelector، دوسرے پیرامیٹرز کو حسب ضرورت استعمال کیا جاسکتا ہے۔

اگر آپ چھوڑ دیں۔ policyTypes، پالیسی کی تشریح اس طرح کی جائے گی:

• پہلے سے طے شدہ طور پر، یہ فرض کیا جاتا ہے کہ یہ داخلی پہلو کی وضاحت کرتا ہے۔ اگر پالیسی واضح طور پر یہ بیان نہیں کرتی ہے، تو سسٹم فرض کرے گا کہ تمام ٹریفک ممنوع ہے۔
• اخراج کی طرف رویے کا تعین متعلقہ اخراج پیرامیٹر کی موجودگی یا غیر موجودگی سے کیا جائے گا۔

غلطیوں سے بچنے کے لیے میں تجویز کرتا ہوں۔ ہمیشہ اسے واضح کریں policyTypes.

مندرجہ بالا منطق کے مطابق، اگر پیرامیٹرز ingress اور / یا۔ egress چھوڑ دیا گیا، پالیسی تمام ٹریفک کو مسترد کر دے گی (نیچے "اسٹرپنگ رول" دیکھیں)۔

پہلے سے طے شدہ پالیسی اجازت ہے۔

اگر کوئی پالیسی متعین نہیں ہے، تو Kubernetes تمام ٹریفک کو بطور ڈیفالٹ اجازت دیتا ہے۔ تمام پوڈ آزادانہ طور پر آپس میں معلومات کا تبادلہ کر سکتے ہیں۔ یہ سیکورٹی کے نقطہ نظر سے متضاد معلوم ہو سکتا ہے، لیکن یاد رکھیں کہ Kubernetes کو اصل میں ڈویلپرز نے ایپلیکیشن انٹرآپریبلٹی کو فعال کرنے کے لیے ڈیزائن کیا تھا۔ نیٹ ورک کی پالیسیاں بعد میں شامل کی گئیں۔

نام کی جگہیں

نام کی جگہیں Kubernetes تعاون کا طریقہ کار ہیں۔ وہ منطقی ماحول کو ایک دوسرے سے الگ کرنے کے لیے ڈیزائن کیے گئے ہیں، جبکہ خالی جگہوں کے درمیان مواصلت کی بطور ڈیفالٹ اجازت ہے۔

زیادہ تر Kubernetes اجزاء کی طرح، نیٹ ورک کی پالیسیاں ایک مخصوص نام کی جگہ میں رہتی ہیں۔ بلاک میں metadata آپ بتا سکتے ہیں کہ پالیسی کس جگہ سے تعلق رکھتی ہے:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

اگر میٹا ڈیٹا میں نام کی جگہ واضح طور پر متعین نہیں کی گئی ہے، تو سسٹم kubectl میں مخصوص نام کی جگہ استعمال کرے گا (بطور ڈیفالٹ namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

میری سفارش ہے نام کی جگہ واضح طور پر بیان کریں۔، جب تک کہ آپ ایسی پالیسی نہیں لکھ رہے ہیں جو ایک ساتھ متعدد نام کی جگہوں کو نشانہ بناتی ہے۔

مین عنصر podSelector پالیسی میں نام کی جگہ سے پوڈز کا انتخاب کرے گا جس سے پالیسی کا تعلق ہے (اسے کسی اور نام کی جگہ سے پوڈ تک رسائی سے انکار ہے)۔

اسی طرح، پوڈ سلیکٹرز داخلی اور خارجی بلاکس میں صرف ان کے اپنے نام کی جگہ سے پوڈز کو منتخب کر سکتے ہیں، جب تک کہ آپ ان کے ساتھ یکجا نہ ہوں۔ namespaceSelector (اس پر سیکشن "نام کی جگہوں اور پوڈز کے ذریعے فلٹر کریں" میں بحث کی جائے گی)۔

پالیسی نام دینے کے قواعد

پالیسی کے نام ایک ہی نام کی جگہ کے اندر منفرد ہیں۔ ایک ہی جگہ میں ایک ہی نام کے ساتھ دو پالیسیاں نہیں ہوسکتی ہیں، لیکن مختلف جگہوں پر ایک ہی نام کی پالیسیاں ہوسکتی ہیں۔ جب آپ ایک ہی پالیسی کو متعدد جگہوں پر دوبارہ لاگو کرنا چاہتے ہیں تو یہ مفید ہے۔

مجھے خاص طور پر نام دینے کا ایک طریقہ پسند ہے۔ یہ ٹارگٹ پوڈز کے ساتھ نام کی جگہ کے نام کو ملانے پر مشتمل ہے۔ مثال کے طور پر:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

لیبل

آپ Kubernetes اشیاء، جیسے pods اور namespaces کے ساتھ حسب ضرورت لیبل منسلک کر سکتے ہیں۔ لیبلز (لیبل - ٹیگز) کلاؤڈ میں ٹیگز کے مساوی ہیں۔ Kubernetes نیٹ ورک کی پالیسیاں منتخب کرنے کے لیے لیبل استعمال کرتی ہیں۔ پھلیاںجس پر وہ لاگو ہوتے ہیں:

podSelector:
  matchLabels:
    role: db

… یا نام کی جگہیںجس پر وہ درخواست دیتے ہیں۔ یہ مثال نام کی جگہوں میں تمام پوڈز کو متعلقہ لیبل کے ساتھ منتخب کرتی ہے:

namespaceSelector:
  matchLabels:
    project: myproject

ایک احتیاط: استعمال کرتے وقت namespaceSelector اس بات کو یقینی بنائیں کہ آپ کے منتخب کردہ نام کی جگہوں میں درست لیبل موجود ہے۔. آگاہ رہیں کہ بلٹ ان نام کی جگہیں جیسے default и kube-system، بطور ڈیفالٹ لیبل پر مشتمل نہیں ہے۔

آپ اس طرح کی جگہ پر لیبل شامل کر سکتے ہیں:

kubectl label namespace default namespace=default

ایک ہی وقت میں، سیکشن میں نام کی جگہ metadata اصل جگہ کے نام کا حوالہ دینا چاہئے، لیبل کا نہیں:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

ماخذ اور منزل

فائر وال پالیسیاں ذرائع اور منازل کے ساتھ قواعد پر مشتمل ہوتی ہیں۔ Kubernetes نیٹ ورک کی پالیسیاں ایک ہدف کے لیے بیان کی جاتی ہیں - پوڈز کا ایک سیٹ جس پر وہ لاگو ہوتے ہیں - اور پھر داخلے اور/یا نکلنے والے ٹریفک کے لیے اصول طے کرتے ہیں۔ ہماری مثال میں، پالیسی کا ہدف نام کی جگہ میں موجود تمام پوڈز ہوں گے۔ default کلید کے ساتھ لیبل کے ساتھ app اور معنی db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

ذیلی دفعہ ingress اس پالیسی میں، ٹارگٹ پوڈز پر آنے والی ٹریفک کو کھولتا ہے۔ دوسرے الفاظ میں، داخل ہونا ذریعہ ہے اور ہدف متعلقہ منزل ہے۔ اسی طرح اخراج منزل ہے اور ہدف اس کا ذریعہ ہے۔

یہ فائر وال کے دو اصولوں کے برابر ہے: Ingress → Target; مقصد → اخراج۔

Egress اور DNS (اہم!)

باہر جانے والی ٹریفک کو محدود کرکے، DNS پر خصوصی توجہ دیں۔ - Kubernetes اس سروس کو IP پتوں پر خدمات کا نقشہ بنانے کے لیے استعمال کرتا ہے۔ مثال کے طور پر، درج ذیل پالیسی کام نہیں کرے گی کیونکہ آپ نے درخواست کی اجازت نہیں دی ہے۔ balance DNS تک رسائی:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

آپ DNS سروس تک رسائی کھول کر اسے ٹھیک کر سکتے ہیں:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

آخری عنصر to خالی ہے، اور اس لیے یہ بالواسطہ طور پر منتخب کرتا ہے۔ تمام پوڈز تمام نام کی جگہوں میں، اجازت دیتا ہے۔ balance DNS استفسارات مناسب Kubernetes سروس کو بھیجیں (عام طور پر خلا میں چلتی ہیں۔ kube-system).

یہ نقطہ نظر کام کرتا ہے، تاہم حد سے زیادہ اجازت دینے والا اور غیر محفوظکیونکہ یہ DNS سوالات کو کلسٹر سے باہر بھیجنے کی اجازت دیتا ہے۔

آپ اسے لگاتار تین مراحل میں بہتر کر سکتے ہیں۔

1. صرف DNS سوالات کی اجازت دیں۔ اندر شامل کرکے کلسٹر namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. صرف نام کی جگہ کے اندر DNS سوالات کی اجازت دیں۔ kube-system.

ایسا کرنے کے لیے آپ کو نام کی جگہ پر ایک لیبل شامل کرنا ہوگا۔ kube-system: kubectl label namespace kube-system namespace=kube-system - اور اسے استعمال کرتے ہوئے پالیسی میں لکھیں۔ namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. بے وقوف لوگ اور بھی آگے جا سکتے ہیں اور DNS سوالات کو ایک مخصوص DNS سروس تک محدود کر سکتے ہیں۔ kube-system. سیکشن "نام کی جگہوں اور پوڈز کے ذریعہ فلٹر کریں" آپ کو بتائے گا کہ اسے کیسے حاصل کیا جائے۔

دوسرا آپشن نام کی جگہ کی سطح پر DNS کو حل کرنا ہے۔ اس صورت میں، اسے ہر سروس کے لیے کھولنے کی ضرورت نہیں ہوگی:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

خالی podSelector نام کی جگہ میں تمام پوڈز کو منتخب کرتا ہے۔

پہلا میچ اور رول آرڈر

روایتی فائر والز میں، ایک پیکٹ پر ایکشن (اجازت دیں یا انکار) کا تعین پہلے اصول سے کیا جاتا ہے جس سے وہ مطمئن ہوتا ہے۔ Kubernetes میں، پالیسیوں کی ترتیب سے کوئی فرق نہیں پڑتا۔

پہلے سے طے شدہ طور پر، جب کوئی پالیسی سیٹ نہیں ہوتی ہے، تو پوڈز کے درمیان مواصلات کی اجازت ہوتی ہے اور وہ آزادانہ طور پر معلومات کا تبادلہ کر سکتے ہیں۔ ایک بار جب آپ پالیسیاں بنانا شروع کر دیتے ہیں، تو ان میں سے کم از کم ایک سے متاثر ہر پوڈ ان تمام پالیسیوں کے منقطع (منطقی OR) کے مطابق الگ ہو جاتا ہے جنہوں نے اسے منتخب کیا تھا۔ کسی پالیسی سے متاثر نہ ہونے والی پھلیاں کھلی رہیں۔

آپ سٹرپنگ اصول کا استعمال کرتے ہوئے اس رویے کو تبدیل کر سکتے ہیں۔

اتارنے کا اصول ("انکار")

فائر وال پالیسیاں عام طور پر کسی بھی ٹریفک سے انکار کرتی ہیں جس کی واضح طور پر اجازت نہیں ہے۔

Kubernetes میں کوئی رد عمل نہیں ہے۔تاہم، اسی طرح کا اثر ایک باقاعدہ (اجازت دینے والی) پالیسی کے ذریعے حاصل کیا جا سکتا ہے سورس پوڈز کے خالی گروپ (انگرس):

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

یہ پالیسی نام کی جگہ میں تمام پوڈز کو منتخب کرتی ہے اور آنے والی تمام ٹریفک کو مسترد کرتے ہوئے، غیر متعینہ اندراج کو چھوڑ دیتی ہے۔

اسی طرح، آپ نام کی جگہ سے باہر جانے والی تمام ٹریفک کو محدود کر سکتے ہیں:

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

براہ مہربانی نوٹ کریں کوئی بھی اضافی پالیسیاں جو ٹریفک کو نام کی جگہ میں پوڈ تک جانے کی اجازت دیتی ہیں اس اصول پر فوقیت حاصل کریں گی۔ (فائر وال کنفیگریشن میں انکار کے اصول سے پہلے اجازت نامہ شامل کرنے کے مترادف)۔

ہر چیز کی اجازت دیں (Any-Any-Any-Allow)

تمام کو اجازت دینے کی پالیسی بنانے کے لیے، آپ کو اوپر دی گئی انکار کی پالیسی کو خالی عنصر کے ساتھ پورا کرنا ہوگا۔ ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

سے رسائی کی اجازت دیتا ہے۔ نام کی جگہ میں تمام پوڈز (اور تمام آئی پی) نام کی جگہ میں کسی بھی پوڈ پر default. یہ رویہ بطور ڈیفالٹ فعال ہوتا ہے، اس لیے اسے عام طور پر مزید وضاحت کرنے کی ضرورت نہیں ہوتی۔ تاہم، بعض اوقات آپ کو مسئلہ کی تشخیص کے لیے کچھ مخصوص اجازتوں کو عارضی طور پر غیر فعال کرنے کی ضرورت پڑ سکتی ہے۔

صرف تک رسائی کی اجازت دینے کے لیے اصول کو محدود کیا جا سکتا ہے۔ پھلیوں کا ایک مخصوص سیٹ (app:balanceنام کی جگہ میں default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

درج ذیل پالیسی کلسٹر کے باہر کسی بھی IP تک رسائی سمیت تمام داخلے اور نکلنے والے ٹریفک کی اجازت دیتی ہے۔

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

متعدد پالیسیوں کا امتزاج

پالیسیوں کو تین سطحوں پر منطقی یا استعمال کرتے ہوئے یکجا کیا جاتا ہے۔ ہر پوڈ کی اجازتیں اس پر اثر انداز ہونے والی تمام پالیسیوں کے منقطع ہونے کے مطابق مقرر کی گئی ہیں:

1. کھیتوں میں from и to عناصر کی تین اقسام کی وضاحت کی جا سکتی ہے (جن میں سے سبھی OR کا استعمال کرتے ہوئے جوڑے جاتے ہیں):

• namespaceSelector - پوری نام کی جگہ کو منتخب کرتا ہے؛
• podSelector - پھلیوں کو منتخب کرتا ہے؛
• ipBlock - ایک ذیلی نیٹ کا انتخاب کرتا ہے۔

مزید برآں، ذیلی حصوں میں عناصر کی تعداد (یہاں تک کہ ایک جیسے) from/to محدود نہیں. ان سب کو منطقی OR سے ملایا جائے گا۔

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. پالیسی سیکشن کے اندر ingress بہت سے عناصر ہوسکتے ہیں from (منطقی OR کے ساتھ مل کر)۔ اسی طرح، سیکشن egress بہت سے عناصر شامل ہو سکتے ہیں to (اختلاف سے بھی ملا ہوا):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. مختلف پالیسیوں کو منطقی OR کے ساتھ بھی ملایا جاتا ہے۔

لیکن ان کو یکجا کرتے وقت، ایک حد ہوتی ہے جس پر نشاندہی کی کرس کوونی: Kubernetes صرف مختلف پالیسیوں کو یکجا کر سکتے ہیں۔ policyTypes (Ingress یا Egress)۔ داخلے (یا اخراج) کی وضاحت کرنے والی پالیسیاں ایک دوسرے کو اوور رائٹ کر دیں گی۔

نام کی جگہوں کے درمیان تعلق

پہلے سے طے شدہ طور پر، نام کی جگہوں کے درمیان معلومات کے اشتراک کی اجازت ہے۔ اسے انکار کی پالیسی کا استعمال کرتے ہوئے تبدیل کیا جا سکتا ہے جو ٹریفک کے باہر جانے اور/یا نام کی جگہ میں آنے والے کو محدود کرے گی (اوپر "اسٹرپنگ رول" دیکھیں)۔

ایک بار جب آپ نے نام کی جگہ تک رسائی کو مسدود کر دیا ہے (اوپر "اسٹرپنگ رول" دیکھیں)، آپ کسی مخصوص نام کی جگہ سے کنکشن کی اجازت دے کر انکار کرنے کی پالیسی میں مستثنیات بنا سکتے ہیں۔ namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

نتیجے کے طور پر، نام کی جگہ میں تمام پھلی default پھلیوں تک رسائی حاصل ہوگی۔ postgres نام کی جگہ میں database. لیکن اگر آپ اس تک رسائی کھولنا چاہتے ہیں۔ postgres نام کی جگہ میں صرف مخصوص پوڈز default?

نام کی جگہوں اور پوڈز کے حساب سے فلٹر کریں۔

Kubernetes ورژن 1.11 اور اس سے زیادہ آپ کو آپریٹرز کو یکجا کرنے کی اجازت دیتا ہے۔ namespaceSelector и podSelector منطقی AND کا استعمال کرتے ہوئے یہ اس طرح لگتا ہے:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

اس کی تشریح عام OR کے بجائے AND سے کیوں کی جاتی ہے؟

براہ کرم نوٹ کریں podSelector ہائفن سے شروع نہیں ہوتا ہے۔ YAML میں اس کا مطلب ہے۔ podSelector اور اس کے سامنے کھڑا ہو گیا namespaceSelector اسی فہرست عنصر کا حوالہ دیں۔ لہذا، وہ منطقی اور کے ساتھ مل کر ہیں.

پہلے ایک ہائفن شامل کرنا podSelector اس کے نتیجے میں ایک نئی فہرست عنصر کا ظہور ہوگا، جو پچھلے ایک کے ساتھ مل جائے گا۔ namespaceSelector منطقی OR کا استعمال کرتے ہوئے.

ایک مخصوص لیبل کے ساتھ پھلیوں کو منتخب کرنے کے لیے تمام نام کی جگہوں میں، خالی درج کریں۔ namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

متعدد لیبلز I کے ساتھ مل کر

ایک سے زیادہ اشیاء (میزبان، نیٹ ورکس، گروپس) کے ساتھ فائر وال کے قواعد کو منطقی OR کا استعمال کرتے ہوئے جوڑ دیا جاتا ہے۔ مندرجہ ذیل اصول کام کرے گا اگر پیکٹ کا ذریعہ مماثل ہے۔ Host_1 OR Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

اس کے برعکس، Kubernetes میں مختلف لیبلز podSelector یا namespaceSelector منطقی AND کے ساتھ جوڑ دیا گیا ہے۔ مثال کے طور پر، درج ذیل اصول ایسے پوڈز کو منتخب کرے گا جن میں دونوں لیبل ہوں، role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

ایک ہی منطق ہر قسم کے آپریٹرز پر لاگو ہوتی ہے: پالیسی ٹارگٹ سلیکٹرز، پوڈ سلیکٹرز، اور نیم اسپیس سلیکٹرز۔

ذیلی نیٹ اور IP پتے (IPBlocks)

فائر والز نیٹ ورک کو سیگمنٹ کرنے کے لیے VLANs، IP ایڈریسز اور سب نیٹس کا استعمال کرتے ہیں۔

Kubernetes میں، IP ایڈریس خود بخود پوڈز کو تفویض کیے جاتے ہیں اور اکثر بدل سکتے ہیں، اس لیے لیبلز کا استعمال نیٹ ورک کی پالیسیوں میں پوڈز اور نام کی جگہوں کو منتخب کرنے کے لیے کیا جاتا ہے۔

ذیلی نیٹ (ipBlocks) استعمال کیا جاتا ہے جب آنے والے (اندرس) یا آؤٹ گوئنگ (ایگریس) بیرونی (شمالی-جنوب) کنکشن کا انتظام کرتے ہیں۔ مثال کے طور پر، یہ پالیسی نام کی جگہ سے تمام پوڈز کے لیے کھلتی ہے۔ default گوگل ڈی این ایس سروس تک رسائی:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

اس مثال میں خالی پوڈ سلیکٹر کا مطلب ہے "نام کی جگہ میں تمام پوڈز کو منتخب کریں۔"

یہ پالیسی صرف 8.8.8.8 تک رسائی کی اجازت دیتی ہے۔ کسی دوسرے IP تک رسائی ممنوع ہے۔ لہذا، جوہر میں، آپ نے اندرونی Kubernetes DNS سروس تک رسائی کو مسدود کر دیا ہے۔ اگر آپ اب بھی اسے کھولنا چاہتے ہیں تو واضح طور پر اس کی نشاندہی کریں۔

عام طور پر ipBlocks и podSelectors باہمی طور پر خصوصی ہیں، کیونکہ پوڈز کے اندرونی IP پتے استعمال نہیں ہوتے ہیں۔ ipBlocks. اشارہ کرکے اندرونی آئی پی پوڈز، آپ اصل میں ان پتوں کے ساتھ پوڈ سے/سے کنکشن کی اجازت دیں گے۔ عملی طور پر، آپ کو معلوم نہیں ہوگا کہ کون سا آئی پی ایڈریس استعمال کرنا ہے، اسی لیے انہیں پوڈز کو منتخب کرنے کے لیے استعمال نہیں کیا جانا چاہیے۔

جوابی مثال کے طور پر، درج ذیل پالیسی میں تمام IPs شامل ہیں اور اس لیے دیگر تمام پوڈز تک رسائی کی اجازت دیتی ہے۔

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

آپ پوڈز کے اندرونی IP پتوں کو چھوڑ کر صرف بیرونی IPs تک رسائی کھول سکتے ہیں۔ مثال کے طور پر، اگر آپ کے پوڈ کا سب نیٹ 10.16.0.0/14 ہے:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

بندرگاہیں اور پروٹوکول

عام طور پر پوڈ ایک بندرگاہ کو سنتے ہیں۔ اس کا مطلب یہ ہے کہ آپ صرف پالیسیوں میں پورٹ نمبر نہیں بتا سکتے اور ہر چیز کو بطور ڈیفالٹ چھوڑ سکتے ہیں۔ تاہم، پالیسیوں کو ہر ممکن حد تک محدود کرنے کی سفارش کی جاتی ہے، لہذا بعض صورتوں میں آپ اب بھی بندرگاہوں کی وضاحت کر سکتے ہیں:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

نوٹ کریں کہ سلیکٹر ports بلاک کے تمام عناصر پر لاگو ہوتا ہے۔ to یا from، جس میں ہے. عناصر کے مختلف سیٹوں کے لیے مختلف بندرگاہوں کی وضاحت کرنے کے لیے، تقسیم کریں۔ ingress یا egress کے ساتھ کئی ذیلی حصوں میں to یا from اور ہر ایک میں اپنی بندرگاہوں کو رجسٹر کریں:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

ڈیفالٹ پورٹ آپریشن:

• اگر آپ پورٹ کی تعریف کو مکمل طور پر چھوڑ دیتے ہیں (ports)، اس کا مطلب ہے تمام پروٹوکول اور تمام بندرگاہیں؛
• اگر آپ پروٹوکول کی تعریف کو چھوڑ دیتے ہیں (protocol) اس کا مطلب ہے TCP;
• اگر آپ پورٹ کی تعریف کو چھوڑ دیتے ہیں (port)، اس کا مطلب ہے تمام بندرگاہیں۔

بہترین عمل: پہلے سے طے شدہ اقدار پر بھروسہ نہ کریں، واضح کریں کہ آپ کو کس چیز کی ضرورت ہے۔

براہ کرم نوٹ کریں کہ آپ کو پوڈ پورٹس کا استعمال کرنا چاہیے، سروس پورٹ نہیں (اس پر مزید اگلے پیراگراف میں)۔

کیا پوڈز یا خدمات کے لیے پالیسیاں بیان کی گئی ہیں؟

عام طور پر، Kubernetes میں پوڈز ایک سروس کے ذریعے ایک دوسرے تک رسائی حاصل کرتے ہیں - ایک ورچوئل لوڈ بیلنسر جو ٹریفک کو ان پوڈز کی طرف ری ڈائریکٹ کرتا ہے جو سروس کو نافذ کرتے ہیں۔ آپ سوچ سکتے ہیں کہ نیٹ ورک کی پالیسیاں خدمات تک رسائی کو کنٹرول کرتی ہیں، لیکن ایسا نہیں ہے۔ Kubernetes نیٹ ورک کی پالیسیاں پوڈ پورٹس پر کام کرتی ہیں، سروس پورٹس پر نہیں۔

مثال کے طور پر، اگر کوئی سروس پورٹ 80 کو سنتی ہے، لیکن ٹریفک کو اس کے پوڈز کے پورٹ 8080 پر ری ڈائریکٹ کرتی ہے، تو آپ کو نیٹ ورک پالیسی میں بالکل 8080 کی وضاحت کرنی چاہیے۔

اس طرح کے طریقہ کار کو سب سے بہتر سمجھا جانا چاہئے: اگر سروس کا اندرونی ڈھانچہ (بندرگاہیں جن کے پوڈ سنتے ہیں) تبدیل ہوتے ہیں، تو نیٹ ورک کی پالیسیوں کو اپ ڈیٹ کرنا ہوگا۔

سروس میش کا استعمال کرتے ہوئے نیا تعمیراتی نقطہ نظر (مثال کے طور پر، ذیل میں اسٹیو کے بارے میں دیکھیں - تقریباً ترجمہ۔) آپ کو اس مسئلے سے نمٹنے کی اجازت دیتا ہے۔

کیا Ingress اور Egress دونوں کو رجسٹر کرنا ضروری ہے؟

مختصر جواب ہاں میں ہے، پوڈ اے کو پوڈ بی کے ساتھ بات چیت کرنے کے لیے، اسے ایک آؤٹ گوئنگ کنکشن بنانے کی اجازت ہونی چاہیے (اس کے لیے آپ کو ایک ایگریس پالیسی ترتیب دینے کی ضرورت ہے)، اور پوڈ بی کو آنے والے کنکشن کو قبول کرنے کے قابل ہونا چاہیے ( اس کے لیے، اس کے مطابق، آپ کو ایک داخلی پالیسی کی ضرورت ہے۔

تاہم، عملی طور پر، آپ ایک یا دونوں سمتوں میں کنکشن کی اجازت دینے کے لیے پہلے سے طے شدہ پالیسی پر انحصار کر سکتے ہیں۔

اگر کچھ پھلی-ذرائع ایک یا زیادہ کے ذریعہ منتخب کیا جائے گا۔ پتہ-سیاستدانوں، اس پر لگائی جانے والی پابندیوں کا تعین ان کے منحرف ہونے سے ہوگا۔ اس صورت میں، آپ کو پوڈ سے کنکشن کی واضح طور پر اجازت دینی ہوگی۔مخاطب کو. اگر کسی پوڈ کو کسی پالیسی کے ذریعے منتخب نہیں کیا جاتا ہے، تو اس کے آؤٹ گوئنگ (ایگریس) ٹریفک کو بطور ڈیفالٹ اجازت دی جاتی ہے۔

اسی طرح پھلی کی قسمت ہے۔ایڈریس، ایک یا زیادہ کے ذریعہ منتخب کیا گیا ہے۔ داخل کرنا-سیاستدان، ان کے اختلاف سے طے ہوں گے۔ اس صورت میں، آپ کو واضح طور پر اسے سورس پوڈ سے ٹریفک حاصل کرنے کی اجازت دینی چاہیے۔ اگر کسی پوڈ کو کسی پالیسی کے ذریعے منتخب نہیں کیا جاتا ہے، تو اس کے لیے تمام داخلی ٹریفک کو بطور ڈیفالٹ اجازت دی جاتی ہے۔

نیچے اسٹیٹفول یا سٹیٹ لیس دیکھیں۔

نوشتہ جات

Kubernetes نیٹ ورک کی پالیسیاں ٹریفک کو لاگ نہیں کر سکتی ہیں۔ اس سے اس بات کا تعین کرنا مشکل ہو جاتا ہے کہ آیا کوئی پالیسی مطلوبہ طور پر کام کر رہی ہے اور سیکورٹی کے تجزیہ کو بہت پیچیدہ بنا دیتی ہے۔

بیرونی خدمات تک ٹریفک کا کنٹرول

Kubernetes نیٹ ورک کی پالیسیاں آپ کو خارجی حصوں میں مکمل طور پر اہل ڈومین نام (DNS) کی وضاحت کرنے کی اجازت نہیں دیتی ہیں۔ یہ حقیقت اس وقت نمایاں تکلیف کا باعث بنتی ہے جب ٹریفک کو بیرونی منزلوں تک محدود کرنے کی کوشش کی جاتی ہے جن کا IP ایڈریس نہیں ہوتا ہے (جیسے aws.com)۔

پالیسی چیک

فائر والز آپ کو متنبہ کریں گے یا غلط پالیسی کو قبول کرنے سے انکار کر دیں گے۔ Kubernetes کچھ توثیق بھی کرتا ہے۔ kubectl کے ذریعے نیٹ ورک پالیسی ترتیب دیتے وقت، Kubernetes یہ اعلان کر سکتا ہے کہ یہ غلط ہے اور اسے قبول کرنے سے انکار کر سکتا ہے۔ دیگر معاملات میں، Kubernetes پالیسی لے گا اور اسے گمشدہ تفصیلات سے پُر کرے گا۔ انہیں کمانڈ کا استعمال کرتے ہوئے دیکھا جا سکتا ہے:

kubernetes get networkpolicy <policy-name> -o yaml

ذہن میں رکھیں کہ Kubernetes کی توثیق کا نظام درست نہیں ہے اور اس میں کچھ قسم کی غلطیاں رہ سکتی ہیں۔

پھانسی

Kubernetes خود نیٹ ورک کی پالیسیوں پر عمل درآمد نہیں کرتا ہے، لیکن یہ محض ایک API گیٹ وے ہے جو کنٹینر نیٹ ورکنگ انٹرفیس (CNI) نامی ایک بنیادی نظام کو کنٹرول کا بوجھ سونپتا ہے۔ مناسب CNI تفویض کیے بغیر Kubernetes کلسٹر پر پالیسیاں ترتیب دینا ایسا ہی ہے جیسا کہ فائر وال مینجمنٹ سرور پر پالیسیاں بنائے بغیر فائر والز پر انسٹال کیے جائیں۔ یہ یقینی بنانا آپ پر منحصر ہے کہ آپ کے پاس ایک معقول CNI ہے یا، Kubernetes پلیٹ فارمز کی صورت میں، کلاؤڈ میں میزبان (آپ فراہم کنندگان کی فہرست دیکھ سکتے ہیں۔ یہاں - تقریبا. ٹرانس.)، نیٹ ورک کی پالیسیوں کو فعال کریں جو آپ کے لیے CNI سیٹ کریں گی۔

یاد رکھیں کہ اگر آپ مناسب مددگار CNI کے بغیر نیٹ ورک پالیسی ترتیب دیتے ہیں تو Kubernetes آپ کو متنبہ نہیں کرے گا۔

ریاستی یا بے وطن؟

تمام Kubernetes CNIs جن کا میں نے سامنا کیا ہے وہ ریاستی ہیں (مثال کے طور پر، Calico Linux conntrack استعمال کرتا ہے)۔ یہ پوڈ کو دوبارہ قائم کیے بغیر شروع کیے گئے TCP کنکشن پر جوابات حاصل کرنے کی اجازت دیتا ہے۔ تاہم، میں Kubernetes کے ایسے معیار سے واقف نہیں ہوں جو ریاستی ہونے کی ضمانت دیتا ہو۔

اعلی درجے کی سیکیورٹی پالیسی مینجمنٹ

Kubernetes میں سیکورٹی پالیسی کے نفاذ کو بہتر بنانے کے کچھ طریقے یہ ہیں:

1. سروس میش آرکیٹیکچرل پیٹرن سروس کی سطح پر تفصیلی ٹیلی میٹری اور ٹریفک کنٹرول فراہم کرنے کے لیے سائڈ کار کنٹینرز کا استعمال کرتا ہے۔ مثال کے طور پر ہم لے سکتے ہیں۔ Istio.
2. کچھ CNI وینڈرز نے Kubernetes نیٹ ورک کی پالیسیوں سے آگے جانے کے لیے اپنے ٹولز کو بڑھایا ہے۔
3. ٹوفن اورکا Kubernetes نیٹ ورک کی پالیسیوں کی مرئیت اور آٹومیشن فراہم کرتا ہے۔

Tufin Orca پیکیج Kubernetes نیٹ ورک کی پالیسیوں کا انتظام کرتا ہے (اور اوپر اسکرین شاٹس کا ذریعہ ہے)۔

اضافی معلومات

• GKE سے احمد الپ بلقان کی تیار کردہ نیٹ ورک پالیسیوں کی مثالیں۔;
• سرکاری Kubernetes ویب سائٹ سے دستاویزات;
• Kubernetes نیٹ ورکنگ ماڈل کے لیے ایک گائیڈ;
• نیٹ ورک کی پالیسیوں کی جانچ کے لیے اسکرپٹ.

حاصل يہ ہوا

Kubernetes نیٹ ورک کی پالیسیاں کلسٹروں کو الگ کرنے کے لیے ٹولز کا ایک اچھا سیٹ پیش کرتی ہیں، لیکن وہ بدیہی نہیں ہیں اور ان میں بہت سی باریکیاں ہیں۔ اس پیچیدگی کی وجہ سے، مجھے یقین ہے کہ بہت سی موجودہ کلسٹر پالیسیاں چھوٹی چھوٹی ہیں۔ اس مسئلے کے ممکنہ حل میں پالیسی کی تعریفوں کو خودکار بنانا یا دوسرے سیگمنٹیشن ٹولز کا استعمال شامل ہے۔

مجھے امید ہے کہ یہ گائیڈ کچھ سوالات کو صاف کرنے اور آپ کو درپیش مسائل کو حل کرنے میں مدد کرے گا۔

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

• "استیو کے ساتھ مائیکرو سروسز پر واپس جائیں": حصہ 1 (اہم خصوصیات کا تعارف), حصہ 2 (روٹنگ، ٹریفک کنٹرول), حصہ 3 (سیکیورٹی);
• "کوبرنیٹس میں نیٹ ورکنگ کے لیے ایک مصوری گائیڈ": حصے 1 اور 2 (نیٹ ورک ماڈل، اوورلے نیٹ ورکس), حصہ 3 (سروسز اور ٹریفک پروسیسنگ);
• «سیکیورٹی کا مطالبہ کرنے والے ماحول میں ڈوکر اور کبرنیٹس؛ "
• «Kubernetes سیکیورٹی کے لیے 9 بہترین طریقے؛ "
• «کبرنیٹس ہیک کا شکار بننے کے (نہیں) 11 طریقے'.

ماخذ: www.habr.com