سيڪيورٽي پروفيشنلز لاءِ ڪبرنيٽس نيٽورڪ پاليسين جو هڪ تعارف

نوٽ. ترجمو: مضمون جو ليکڪ، ريوون هيريسن، سافٽ ويئر ڊولپمينٽ ۾ 20 سالن کان مٿي جو تجربو آهي، ۽ اڄڪلهه CTO ۽ Tufin جو ڪو باني آهي، هڪ ڪمپني جيڪا سيڪيورٽي پاليسي مئنيجمينٽ حل ٺاهي ٿي. جڏهن ته هو Kubernetes نيٽ ورڪ پاليسين کي ڪلستر ۾ نيٽ ورڪ ورهائڻ لاءِ هڪ انتهائي طاقتور اوزار طور ڏسي ٿو، هو اهو به مڃي ٿو ته انهن کي عملي طور تي لاڳو ڪرڻ ايترو آسان ناهي. هي مواد (بلڪل وڏي) جو مقصد آهي ماهرن جي هن مسئلي جي آگاهي کي بهتر بڻائڻ ۽ انهن کي ضروري ترتيب ڏيڻ ۾ مدد ڏيڻ.

اڄ، ڪيتريون ئي ڪمپنيون تيزيء سان چونڊي رهيا آهن ڪبرنيٽس انهن جي ايپليڪيشنن کي هلائڻ لاء. هن سافٽ ويئر ۾ دلچسپي تمام گهڻي آهي ته ڪجهه Kubernetes کي سڏي رهيا آهن "ڊيٽا سينٽر لاء نئين آپريٽنگ سسٽم." تدريجي طور تي، Kubernetes (يا k8s) کي ڪاروبار جي هڪ نازڪ حصي طور سمجهيو وڃي ٿو، جنهن لاءِ نيٽ ورڪ سيڪيورٽي سميت بالغ ڪاروباري عملن جي تنظيم جي ضرورت آهي.

سيڪيورٽي پروفيشنلز لاءِ جيڪي ڪبرنيٽس سان ڪم ڪندي حيران ٿي ويا آهن، حقيقي وحي پليٽ فارم جي ڊفالٽ پاليسي ٿي سگهي ٿي: هر شي کي اجازت ڏيو.

هي گائيڊ توهان کي نيٽ ورڪ پاليسين جي اندروني ڍانچي کي سمجهڻ ۾ مدد ڏيندو. سمجھو ته اهي باقاعده فائر والز جي ضابطن کان ڪيئن مختلف آهن. اهو پڻ ڪجهه نقصانن کي ڍڪيندو ۽ ڪبرنيٽس تي محفوظ ايپليڪيشنن ۾ مدد لاءِ سفارشون مهيا ڪندو.

Kubernetes نيٽ ورڪ پاليسيون

Kubernetes نيٽ ورڪ پاليسي ميڪانيزم توهان کي نيٽ ورڪ پرت تي پليٽ فارم تي مقرر ڪيل ايپليڪيشنن جي رابطي کي منظم ڪرڻ جي اجازت ڏئي ٿو (او ايس آئي ماڊل ۾ ٽيون). نيٽ ورڪ پاليسين ۾ جديد فائر والز جي ڪجهه جديد خصوصيتن جو فقدان آهي، جهڙوڪ OSI Layer 7 لاڳو ڪرڻ ۽ خطري جو پتو لڳائڻ، پر اهي نيٽ ورڪ سيڪيورٽي جو بنيادي سطح مهيا ڪن ٿيون جيڪو هڪ سٺو شروعاتي نقطو آهي.

نيٽ ورڪ پاليسيون پوڊ جي وچ ۾ رابطي کي ڪنٽرول ڪن ٿيون

ڪبرنيٽس ۾ ڪم لوڊ پوڊس ۾ ورهايو ويندو آهي، جنهن ۾ هڪ يا وڌيڪ ڪنٽينر گڏ ڪيا ويندا آهن. Kubernetes هر پوڊ کي هڪ IP پتو تفويض ڪري ٿو جيڪو ٻين پوڊس کان رسائي لائق آهي. ڪبرنيٽس نيٽ ورڪ پاليسيون پوڊ جي گروپن لاءِ رسائي جا حق مقرر ڪن ٿيون جيئن بادل ۾ سيڪيورٽي گروپ ورچوئل مشين جي مثالن تائين رسائي کي ڪنٽرول ڪرڻ لاءِ استعمال ٿين ٿا.

نيٽ ورڪ پاليسين جي وضاحت

ٻين 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

(نوٽ. ترجمو: هي اسڪرين شاٽ، جيئن پوءِ آيل سڀني ملندڙ جلندڙن وانگر، ٺاهيو ويو آهي اصلي ڪبرنيٽس ٽولز استعمال ڪندي نه، پر Tufin Orca ٽول استعمال ڪندي، جيڪو اصل مضمون جي ليکڪ جي ڪمپني پاران تيار ڪيو ويو هو ۽ جنهن جو ذڪر مواد جي آخر ۾ ڪيو ويو آهي.)

توهان جي پنهنجي نيٽ ورڪ پاليسي جي وضاحت ڪرڻ لاء، توهان کي YAML جي بنيادي ڄاڻ جي ضرورت پوندي. هيءَ ٻولي انڊينٽيشن تي مبني آهي (ٽيب جي بجاءِ اسپيس طرفان بيان ڪيل). انڊينٽ ٿيل عنصر جو تعلق ان جي مٿان ويجھي انڊينٽ ٿيل عنصر سان آھي. هڪ نئين فهرست عنصر هڪ هائيفن سان شروع ٿئي ٿو، ٻين سڀني عنصرن جو فارم آهي اهم-قدر.

YAML ۾ پاليسي بيان ڪرڻ، استعمال ڪريو ڪيوبڪبلان کي ڪلستر ۾ ٺاهڻ لاء:

kubectl create -f policy.yaml

نيٽ ورڪ پاليسي جي وضاحت

Kubernetes نيٽ ورڪ پاليسي جي وضاحت ۾ چار عناصر شامل آهن:

1. podSelector: ھن پاليسيءَ کان متاثر ٿيل پوڊس جي وضاحت ڪري ٿو (ھدف) - گھربل؛
2. policyTypes: اشارو ڪري ٿو ته هن ۾ ڪهڙي قسم جون پاليسيون شامل آهن: داخل ٿيڻ ۽/يا نڪرڻ - اختياري، پر مان سفارش ڪريان ٿو ته ان کي سڀني صورتن ۾ واضح طور بيان ڪيو وڃي.
3. ingress: وضاحت جي اجازت ايندڙ ٽارگيٽ پوڊس ڏانهن ٽرئفڪ - اختياري؛
4. egress: وضاحت جي اجازت goingاهر وڻ وارو ٽارگيٽ پوڊس کان ٽرئفڪ اختياري آهي.

مثال 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 اصل ۾ ڊولپرز طرفان ٺهيل هئي ايپليڪيشن جي مداخلت کي فعال ڪرڻ لاء. نيٽ ورڪ پاليسيون بعد ۾ شامل ڪيون ويون.

نالا

Namespaces آهن Kubernetes collaboration mechanism. اهي ٺهيل آهن منطقي ماحول کي هڪ ٻئي کان ڌار ڪرڻ لاءِ، جڏهن ته خالن جي وچ ۾ رابطي کي ڊفالٽ جي اجازت هوندي آهي.

ڪبرنيٽس جي اڪثر حصن وانگر، نيٽ ورڪ پاليسيون هڪ مخصوص نالي واري جاءِ ۾ رهن ٿيون. بلاڪ ۾ 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 پاليسي ۾ نالي جي جاءِ مان پوڊز کي چونڊيندو جنهن سان پاليسي تعلق رکي ٿي (ان کي ڪنهن ٻئي نالي جي جڳهه کان پوڊ تائين رسائي کان انڪار ڪيو ويو آهي).

ساڳئي طرح، podSelectors داخل ٿيڻ ۽ نڪرڻ واري بلاڪ ۾ صرف پوڊز کي پنھنجي نالي جي جڳھ مان چونڊي سگھو ٿا، جيستائين توھان انھن سان گڏ نه ڪريو 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 شيون، جهڙوڪ پوڊس ۽ نالي جي جاءِ تي ڪسٽم ليبل ڳنڍي سگهو ٿا. ليبل (ليبل - ٽيگ) بادل ۾ ٽيگ جي برابر آهن. 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 سوالن کي مناسب ڪبرنيٽس سروس ڏانهن موڪليو (عام طور تي خلا ۾ هلندڙ 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) انهن سڀني پاليسين جي جن ان کي چونڊيو آهي. پوڊ ڪنهن به پاليسي کان متاثر نه هوندا کليل رهندا.

توھان ھن رويي کي تبديل ڪري سگھو ٿا ھڪڙي قاعدي کي استعمال ڪندي.

ڪٽڻ جو قاعدو ("انڪار")

فائر وال پاليسيون عام طور تي ڪنهن به ٽرئفڪ کي رد ڪن ٿيون جيڪي واضح طور تي اجازت نه هجن.

ڪوبرنيٽس ۾ ڪو به رد عمل ناهيجڏهن ته، ساڳيو اثر حاصل ڪري سگهجي ٿو باقاعده (اجازت واري) پاليسي سان ذريعن جي پوڊس جي هڪ خالي گروپ کي منتخب ڪندي (انگريس):

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

مهرباني ڪري اهو نوٽ ڪريو ڪا به اضافي پاليسيون جيڪي ٽريفڪ کي نيم اسپيس ۾ پوڊز ڏانهن وڃڻ جي اجازت ڏين ٿيون هن قاعدي تي اوليت وٺنديون (فائر وال جي ترتيب ۾ رد ڪرڻ واري قاعدي کان اڳ اجازت واري قاعدي کي شامل ڪرڻ جي برابر).

سڀڪنھن شيء کي اجازت ڏيو (ڪنهن به-ڪنهن به- اجازت ڏيو)

ھڪڙي ٺاھڻ جي اجازت ڏيو سڀني پاليسين کي، توھان کي ضرورت آھي ھڪڙي خالي عنصر سان مٿي ڏنل رد ڪرڻ واري پاليسي کي ingress:

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

مان رسائي جي اجازت ڏئي ٿي سڀ پوڊ سڀني نالن جي اسپيس ۾ (۽ سڀ IP) نالي جي جاءِ ۾ ڪنهن به پوڊ ڏانهن 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 ساڳئي فهرست جي عنصر ڏانهن رجوع ڪريو. تنهن ڪري، اهي منطقي AND سان گڏ آهن.

اڳ ۾ هڪ هائيفن شامل ڪرڻ 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

ڪيترن ئي شين (ميزبان، نيٽ ورڪ، گروپن) سان گڏ فائر وال لاء ضابطا منطقي يا استعمال ڪندي گڏيل آهن. ھيٺ ڏنل قاعدو ڪم ڪندو جيڪڏھن پيڪيٽ جو ذريعو ملندو Host_1 يا Host_2:

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

ان جي برعڪس، ڪبرنيٽس ۾ مختلف ليبلز ۾ podSelector يا namespaceSelector منطقي AND سان گڏ ٿيل آهن. مثال طور، هيٺ ڏنل قاعدو پوڊس کي چونڊيندو جن ۾ ٻئي ليبل هوندا، role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

ساڳيو منطق سڀني قسمن جي آپريٽرز تي لاڳو ٿئي ٿو: پاليسي ٽارگيٽ چونڊيندڙ، پوڊ چونڊيندڙ، ۽ نالي جي جڳھ چونڊيندڙ.

سبنيٽس ۽ IP پتي (IPBlocks)

فائر والز استعمال ڪن ٿا VLANs، IP پتي، ۽ ذيلي نيٽ ورڪ کي ڀاڱي ڪرڻ لاءِ.

Kubernetes ۾، IP پتي کي خودڪار طريقي سان مقرر ڪيو ويو آهي پوڊ ۽ اڪثر تبديل ٿي سگهن ٿا، تنهن ڪري ليبل استعمال ڪيا ويندا آهن پوڊ ۽ نيٽ ورڪ پاليسين ۾ نالا اسپيس کي چونڊڻ لاء.

سبنيٽس (ipBlocks) استعمال ڪيو ويندو آهي جڏهن انتظام ڪرڻ ۾ ايندڙ (انڪري) يا ٻاهر نڪرندڙ (انڪري) خارجي (اتر-ڏکڻ) ڪنيڪشن. مثال طور، هي پاليسي نالا اسپيس مان سڀني پوڊز ڏانهن کليل آهي default Google DNS سروس تائين رسائي:

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. اشارو ڪندي اندروني IP پوڊ، توهان اصل ۾ انهن ايڊريس سان پوڊز کان / کان ڪنيڪشن جي اجازت ڏيندا. عملي طور تي، توهان کي خبر ناهي ته ڪهڙي IP پتي کي استعمال ڪرڻ لاء، ڇو ته انهن کي پوڊ چونڊڻ لاء استعمال نه ڪيو وڃي.

جوابي مثال طور، ھيٺ ڏنل پاليسي ۾ سڀ 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

توھان صرف خارجي IPs تائين رسائي کولي سگھو ٿا، پوڊس جي اندروني IP پتي کانسواءِ. مثال طور، جيڪڏهن توهان جي پوڊ جو سب نيٽ 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 نيٽ ورڪ پاليسيون پوڊ بندرگاهن تي ڪم ڪن ٿيون، نه سروس بندرگاهن تي.

مثال طور، جيڪڏهن هڪ خدمت ٻڌي ٿي پورٽ 80، پر ٽريفڪ کي ريڊائريڪٽ ڪري ٿو پورٽ 8080 ڏانهن ان جي پوڊ، توهان کي ضرور بيان ڪرڻ گهرجي 8080 نيٽ ورڪ پاليسي ۾.

اهڙي ميکانيزم کي ذيلي اپٽيمل سمجهيو وڃي ٿو: جيڪڏهن خدمت جي اندروني جوڙجڪ (جنهن جا بندرگاهن ٻڌن ٿا) تبديل ٿي وڃن، نيٽ ورڪ پاليسين کي اپڊيٽ ڪرڻو پوندو.

سروس ميش استعمال ڪندي نئين تعميراتي انداز (مثال طور، هيٺ ڏنل Istio بابت ڏسو - تقريبن ترجمو.) توهان کي هن مسئلي کي منهن ڏيڻ جي اجازت ڏئي ٿو.

ڇا اهو ضروري آهي ته داخل ٿيڻ ۽ نڪرڻ ٻنهي کي رجسٽر ڪرڻ لاء؟

مختصر جواب ها آھي، پوڊ اي لاءِ پوڊ بي سان ڳالھ ٻولھ ڪرڻ لاءِ، ان کي ھڪ ٻاھر نڪرندڙ ڪنيڪشن ٺاھڻ جي اجازت ھجڻ گھرجي (ان لاءِ توھان کي ايگريس پاليسي ٺاھڻ جي ضرورت آھي)، ۽ پوڊ بي کي لازمي طور تي اچڻ واري ڪنيڪشن کي قبول ڪرڻ جي قابل ھجڻ گھرجي ( ان لاءِ، ان جي مطابق، توهان کي داخل ٿيڻ واري پاليسي جي ضرورت آهي).

بهرحال، عملي طور تي، توهان هڪ يا ٻئي طرف ڪنيڪشن جي اجازت ڏيڻ لاءِ ڊفالٽ پاليسي تي ڀروسو ڪري سگهو ٿا.

جيڪڏهن ڪجهه ٻج-ذريعو هڪ يا وڌيڪ طرفان چونڊيو ويندو نڪرڻ-سياستدان، مٿس جيڪي پابنديون لڳل آهن، تن جو تعين انهن جي نااهلي سان ٿيندو. انهي حالت ۾، توهان کي واضح طور تي پوڊ سان ڪنيڪشن جي اجازت ڏيڻ جي ضرورت پوندي.مخاطب. جيڪڏهن هڪ پوڊ ڪنهن به پاليسي طرفان نه چونڊيو ويو آهي، ان جي نڪرڻ واري (ايگريس) ٽرئفڪ کي ڊفالٽ جي اجازت ڏني وئي آهي.

ساڳيءَ طرح، پوڊ جي قسمت آهيپتو ڏيڻ واروهڪ يا وڌيڪ طرفان چونڊيو ويو آهي داخل ٿيڻ-سياستدان، انهن جي اختلافن سان طئي ٿيندا. انهي حالت ۾، توهان کي واضح طور تي ان کي اجازت ڏيڻ گهرجي ته اهو ذريعو پوڊ مان ٽرئفڪ حاصل ڪري. جيڪڏهن ڪو پوڊ ڪنهن به پاليسيءَ طرفان نه چونڊيو ويو آهي، ته ان لاءِ سڀ داخلا ٽريفڪ ڊفالٽ جي اجازت هوندي آهي.

هيٺ ڏسو Stateful يا Stateless.

لاگز

Kubernetes نيٽ ورڪ پاليسيون ٽرئفڪ کي لاگ ان نٿا ڪري سگهن. اهو اهو طئي ڪرڻ ڏکيو بڻائي ٿو ته ڇا هڪ پاليسي ڪم ڪري رهي آهي جيئن مقصد ۽ تمام گهڻو پيچيده سيڪيورٽي تجزيو.

ٻاهرين خدمتن ڏانهن ٽرئفڪ جو ڪنٽرول

Kubernetes نيٽ ورڪ پاليسيون توهان کي مڪمل طور تي قابليت وارو ڊومين نالو (DNS) بيان ڪرڻ جي اجازت نه ڏيندا آهن خارجي حصن ۾. اها حقيقت اهم تڪليف جي ڪري ٿي جڏهن ٽريفڪ کي ٻاهرين منزلن ڏانهن محدود ڪرڻ جي ڪوشش ڪري ٿي جن وٽ مقرر IP پتو نه آهي (جهڙوڪ aws.com).

پاليسي چيڪ

فائر والز توهان کي ڊيڄاريندا يا غلط پاليسي کي قبول ڪرڻ کان به انڪار ڪندا. ڪبرنيٽس پڻ ڪجهه تصديق ڪري ٿو. جڏهن kubectl ذريعي هڪ نيٽ ورڪ پاليسي ترتيب ڏيڻ، ڪبرنيٽس اهو اعلان ڪري سگهي ٿو ته اهو غلط آهي ۽ ان کي قبول ڪرڻ کان انڪار ڪري ٿو. ٻين حالتن ۾، Kubernetes پاليسي کڻندو ۽ ان کي گم ٿيل تفصيلن سان ڀريندو. اهي حڪم استعمال ڪندي ڏسي سگهجن ٿا:

kubernetes get networkpolicy <policy-name> -o yaml

ذهن ۾ رکو ته Kubernetes جي تصديق واري نظام کي درست نه آهي ۽ ڪجهه قسم جي غلطين کي ياد ڪري سگھي ٿو.

تياري

Kubernetes پاڻ نيٽ ورڪ پاليسين تي عمل نه ڪندو آهي، پر صرف هڪ API گيٽ وي آهي جيڪو ڪنٽرول جي بوجھ کي هڪ هيٺئين سسٽم ڏانهن موڪلي ٿو جنهن کي ڪنٽينر نيٽورڪنگ انٽرفيس (CNI) سڏيو ويندو آهي. مناسب CNI تفويض ڪرڻ کان سواءِ ڪبرنيٽس ڪلستر تي پاليسيون سيٽ ڪرڻ ساڳيو ئي آهي جيئن فائر وال مئنيجمينٽ سرور تي پاليسيون ٺاهڻ کان سواءِ انهن کي فائر والز تي انسٽال ڪرڻ کان سواءِ. اهو توهان تي آهي انهي کي يقيني بڻائڻ ته توهان وٽ هڪ مهذب CNI آهي يا، ڪبرنيٽس پليٽ فارم جي صورت ۾، ڪلائوڊ ۾ ميزباني (توهان مهيا ڪندڙن جي فهرست ڏسي سگهو ٿا هتي - لڳ ڀڳ ٽرانس.)، نيٽ ورڪ پاليسين کي فعال ڪريو جيڪي توهان لاءِ CNI سيٽ ڪنديون.

نوٽ ڪريو ته Kubernetes توهان کي ڊيڄاري نه سگھندو جيڪڏهن توهان مناسب مددگار CNI کان سواءِ نيٽ ورڪ پاليسي سيٽ ڪريو ٿا.

رياستي يا بي وطن؟

سڀئي Kubernetes CNIs جن سان مون منهن ڪيو آهي رياستي آهن (مثال طور، Calico استعمال ڪري ٿو Linux conntrack). هي پوڊ کي اجازت ڏئي ٿو جواب حاصل ڪرڻ جي TCP ڪنيڪشن تي جيڪو ان کي ٻيهر قائم ڪرڻ جي بغير شروع ڪيو ويو آهي. بهرحال، مان هڪ ڪبرنيٽس جي معيار کان واقف نه آهيان جيڪو رياستي حيثيت جي ضمانت ڏيندو.

ترقي يافته سيڪيورٽي پاليسي جو انتظام

هتي ڪبرنيٽس ۾ سيڪيورٽي پاليسي لاڳو ڪرڻ کي بهتر ڪرڻ جا ڪجهه طريقا آهن:

1. سروس ميش آرڪيٽيڪچرل نمونو سائڊ ڪار ڪنٽينرز استعمال ڪري ٿو تفصيلي ٽيليميٽري ۽ سروس جي سطح تي ٽرئفڪ ڪنٽرول مهيا ڪرڻ لاءِ. مثال طور اسين وٺي سگهون ٿا استيو.
2. ڪجھ CNI وينڊرز ڪبرنيٽس نيٽ ورڪ پاليسين کان اڳتي وڌڻ لاءِ پنھنجي اوزار کي وڌايو آھي.
3. توفين اورڪا Kubernetes نيٽ ورڪ پاليسين جي نمائش ۽ خودڪار مهيا ڪري ٿي.

Tufin Orca پيڪيج Kubernetes نيٽ ورڪ پاليسين کي منظم ڪري ٿو (۽ مٿي ڏنل اسڪرين شاٽ جو ذريعو آهي).

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

• GKE کان احمد الپ بلقان پاران تيار ڪيل نيٽ ورڪ پاليسين جا مثال;
• سرڪاري Kubernetes ويب سائيٽ تان دستاويز;
• ڪبرنيٽس نيٽورڪنگ ماڊل لاءِ هڪ گائيڊ;
• نيٽ ورڪ پاليسين چيڪ ڪرڻ لاء اسڪرپٽ.

ٿڪل

Kubernetes نيٽ ورڪ پاليسيون پيش ڪن ٿيون اوزارن جو هڪ سٺو سيٽ ڪلسٽرن کي ورهائڻ لاءِ، پر اهي سمجهه وارا نه آهن ۽ گهڻيون ذهين شيون آهن. انهي پيچيدگي جي ڪري، مان سمجهان ٿو ته ڪيتريون ئي موجوده ڪلسٽر پاليسيون خراب آهن. ھن مسئلي جي ممڪن حلن ۾ شامل آھن خودڪار پاليسي جي وصفن کي استعمال ڪرڻ يا ٻين ڀاڱيداري جا اوزار استعمال ڪرڻ.

مون کي اميد آهي ته هي گائيڊ ڪجهه سوالن کي صاف ڪرڻ ۽ انهن مسئلن کي حل ڪرڻ ۾ مدد ڪندو جيڪي توهان کي منهن ڏئي سگھن ٿا.

پي ايس مترجم کان

اسان جي بلاگ تي پڻ پڙهو:

• "Istio سان microservices ڏانهن واپس": حصو 1 (مکيه خصوصيتن جو تعارف), حصو 2 (روٽنگ، ٽرئفڪ ڪنٽرول), حصو 3 (سيڪيورٽي);
• "ڪبرنيٽس ۾ نيٽ ورڪنگ لاءِ هڪ مثالي گائيڊ": حصا 1 ۽ 2 (نيٽ ورڪ ماڊل، اوورلي نيٽ ورڪ), حصو 3 (سروسز ۽ ٽرئفڪ پروسيسنگ);
• «ڊاکر ۽ ڪبرنيٽس سيڪيورٽي گهربل ماحول ۾"؛
• «ڪبرنيٽس سيڪيورٽي لاءِ 9 بهترين طريقا"؛
• «11 طريقا (نه) هڪ ڪبرنيٽس هيڪ جو شڪار ٿيڻ».

جو ذريعو: www.habr.com