নিরাপত্তা পেশাদারদের জন্য Kubernetes নেটওয়ার্ক নীতির একটি ভূমিকা

বিঃদ্রঃ. অনুবাদ: নিবন্ধটির লেখক - রিউভেন হ্যারিসন - সফ্টওয়্যার ডেভেলপমেন্টে 20 বছরের বেশি অভিজ্ঞতা রয়েছে, এবং আজ তিনি নিরাপত্তা নীতি ব্যবস্থাপনা সমাধান কোম্পানি Tufin-এর CTO এবং সহ-প্রতিষ্ঠাতা৷ যদিও তিনি Kubernetes নেটওয়ার্ক নীতিগুলিকে একটি ক্লাস্টারে নেটওয়ার্ককে ভাগ করার জন্য যথেষ্ট শক্তিশালী বলে মনে করেন, তিনি এটাও বিশ্বাস করেন যে বাস্তবে প্রয়োগ করা এত সহজ নয়। এই উপাদানটি (বরং প্রচুর পরিমাণে) এই বিষয়ে বিশেষজ্ঞদের সচেতনতা উন্নত করতে এবং প্রয়োজনীয় কনফিগারেশন তৈরিতে তাদের সহায়তা করার উদ্দেশ্যে।

আজ, অনেক কোম্পানি ক্রমবর্ধমানভাবে তাদের অ্যাপ্লিকেশন চালানোর জন্য Kubernetes বেছে নিচ্ছে। এই সফ্টওয়্যারটির প্রতি আগ্রহ এত বেশি যে কেউ কেউ কুবারনেটসকে "ডেটা সেন্টারের জন্য নতুন অপারেটিং সিস্টেম" বলে অভিহিত করেন। ধীরে ধীরে, Kubernetes (বা k8s) ব্যবসার একটি গুরুত্বপূর্ণ অংশ হিসাবে বিবেচিত হতে শুরু করেছে যার জন্য নেটওয়ার্ক নিরাপত্তা সহ পরিপক্ক ব্যবসায়িক প্রক্রিয়াগুলির সংগঠন প্রয়োজন।

নিরাপত্তা পেশাদারদের জন্য যারা কুবারনেটসের সাথে কাজ করে বিভ্রান্ত হয়েছেন, এই প্ল্যাটফর্মের ডিফল্ট নীতি একটি বাস্তব আবিষ্কার হতে পারে: সবকিছুর অনুমতি দিন।

এই নির্দেশিকা আপনাকে নেটওয়ার্ক নীতিগুলির অভ্যন্তরীণ কাজগুলি বুঝতে সাহায্য করবে; নিয়মিত ফায়ারওয়ালের নিয়ম থেকে তারা কীভাবে আলাদা তা বুঝতে পারেন। এটি কিছু অসুবিধা সম্পর্কেও কথা বলবে এবং সুপারিশ দেবে যা কুবারনেটে অ্যাপ্লিকেশনগুলিকে রক্ষা করতে সাহায্য করবে৷

Kubernetes নেটওয়ার্ক নীতি

Kubernetes নেটওয়ার্ক নীতি প্রক্রিয়া আপনাকে নেটওয়ার্ক স্তরে (OSI মডেলের তৃতীয়) প্ল্যাটফর্মে স্থাপন করা অ্যাপ্লিকেশনগুলির মিথস্ক্রিয়া পরিচালনা করতে দেয়। নেটওয়ার্ক নীতিগুলিতে আধুনিক ফায়ারওয়ালের কিছু উন্নত বৈশিষ্ট্যের অভাব রয়েছে, যেমন OSI স্তর 7 নিয়ন্ত্রণ এবং হুমকি সনাক্তকরণ, কিন্তু তারা নেটওয়ার্ক নিরাপত্তার একটি মৌলিক স্তর প্রদান করে যা একটি ভাল সূচনা বিন্দু।

নেটওয়ার্ক নীতিগুলি পডের মধ্যে যোগাযোগ নিয়ন্ত্রণ করে

Kubernetes-এ কাজের চাপগুলি পড জুড়ে বিতরণ করা হয়, যা এক বা একাধিক পাত্রে একত্রে স্থাপন করা হয়। কুবারনেটস প্রতিটি পডকে অন্য পড থেকে অ্যাক্সেসযোগ্য একটি আইপি ঠিকানা বরাদ্দ করে। 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

(বিঃদ্রঃ. অনুবাদ: এই স্ক্রিনশটটি, পরবর্তী সমস্ত অনুরূপ স্ক্রিনশটগুলির মতো, নেটিভ কুবারনেটস টুল ব্যবহার করে তৈরি করা হয়নি, তবে 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 পলিসিতে পলিসিটি যে নামস্থান থেকে পড নির্বাচন করবে (এটির অন্য নামস্থান থেকে পডগুলিতে অ্যাক্সেস নেই)।

একইভাবে, 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 নেটওয়ার্ক নীতি নির্বাচন করতে লেবেল ব্যবহার করে শুঁটিযার জন্য তারা প্রযোজ্য:

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 এই নীতিতে টার্গেট পডের জন্য ইনকামিং ট্রাফিক খোলে। অন্য কথায়, প্রবেশ হল উৎস এবং লক্ষ্য হল সংশ্লিষ্ট গন্তব্য। একইভাবে, প্রস্থান হল গন্তব্য, এবং লক্ষ্য তার উৎস।

এটি দুটি ফায়ারওয়াল নিয়মের সমতুল্য: ইনগ্রেস → টার্গেট; লক্ষ্য → প্রস্থান।

প্রস্থান এবং DNS (গুরুত্বপূর্ণ!)

বহির্গামী ট্রাফিক সীমিত DNS-এ বিশেষ মনোযোগ দিন - Kubernetes এই পরিষেবাটি আইপি ঠিকানাগুলিতে পরিষেবাগুলি ম্যাপ করতে ব্যবহার করে। উদাহরণস্বরূপ, নিম্নলিখিত নীতি কাজ করবে না কারণ আপনি আবেদনের অনুমতি দেননি৷ 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 উপযুক্ত Kubernetes পরিষেবাতে 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. প্যারানয়েডগুলি আরও এগিয়ে যেতে পারে এবং ডিএনএস অনুরোধগুলিকে একটি নির্দিষ্ট ডিএনএস পরিষেবাতে সীমাবদ্ধ করতে পারে৷ 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

দয়া করে মনে রাখবেন যে নেমস্পেসে পডগুলিতে ট্র্যাফিকের অনুমতি দেয় এমন কোনও অতিরিক্ত নীতি এই নিয়মের উপর অগ্রাধিকার পাবে (ফায়ারওয়াল কনফিগারেশনে অস্বীকার করার নিয়মের আগে একটি অনুমোদিত নিয়ম যোগ করার অনুরূপ)।

সকলকে অনুমতি দিন (যে কোনো-যে কোনো-অনুমতি দিন)

একটি "সমস্তকে অনুমতি দিন" নীতি তৈরি করতে, আপনাকে একটি খালি উপাদান সহ উপরের অস্বীকার নীতির পরিপূরক করতে হবে 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

নিম্নলিখিত নীতি ক্লাস্টারের বাইরে যেকোন আইপি অ্যাক্সেস সহ সমস্ত ইনকামিং (ইনগ্রেস) এবং বহির্গামী (প্রস্থান) ট্র্যাফিকের অনুমতি দেয়:

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

একাধিক লেবেল AND এর সাথে একত্রিত হয়

একাধিক সত্তা (হোস্ট, নেটওয়ার্ক, গ্রুপ) সহ ফায়ারওয়াল নিয়মগুলি একটি লজিক্যাল OR ব্যবহার করে একত্রিত করা হয়। প্যাকেটের উৎস মেলে নিচের নিয়মটি ফায়ার হবে Host_1 অথবা 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

একই যুক্তি সব ধরনের বিবৃতিতে প্রযোজ্য: নীতি লক্ষ্য নির্বাচক, পড নির্বাচক এবং নামস্থান নির্বাচক।

সাবনেট এবং আইপি ঠিকানা (IPBlocks)

ফায়ারওয়াল একটি নেটওয়ার্ককে ভাগ করার জন্য VLAN, 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 এ অ্যাক্সেসের অনুমতি দেয়; অন্য কোনো আইপি অ্যাক্সেস নিষিদ্ধ. সুতরাং, সংক্ষেপে, আপনি অভ্যন্তরীণ কুবারনেটস ডিএনএস পরিষেবাতে অ্যাক্সেস অবরুদ্ধ করেছেন। আপনি যদি এখনও এটি খুলতে চান তবে এটি স্পষ্টভাবে উল্লেখ করুন।

সাধারণত ipBlocks и podSelectors পারস্পরিক একচেটিয়া, যেহেতু পডের অভ্যন্তরীণ আইপি ঠিকানাগুলি ব্যবহার করা হয় না ipBlocks. ইশারা অভ্যন্তরীণ আইপি পড, আপনি আসলে সেই ঠিকানাগুলির সাথে পড থেকে/থেকে সংযোগের অনুমতি দেবেন। অনুশীলনে, কোন আইপি ঠিকানা ব্যবহার করতে হবে তা আপনি জানেন না, তাই পড নির্বাচন করতে আপনার সেগুলি ব্যবহার করা উচিত নয়।

একটি পাল্টা উদাহরণ হিসাবে, নিম্নলিখিত নীতিতে সমস্ত আইপি অন্তর্ভুক্ত রয়েছে এবং তাই অন্যান্য সমস্ত পডগুলিতে অ্যাক্সেসের অনুমতি দেয়:

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

আপনি পডের অভ্যন্তরীণ আইপি ঠিকানাগুলি বাদ দিয়ে শুধুমাত্র বাহ্যিক আইপিগুলিতে অ্যাক্সেস খুলতে পারেন। উদাহরণস্বরূপ, যদি আপনার পডের সাবনেট 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 সম্পর্কে দেখুন - প্রায় অনুবাদ।) আপনি এই সমস্যা মোকাবেলা করতে পারবেন.

Ingress এবং Egress উভয়ই লিখতে হবে?

সংক্ষিপ্ত উত্তর হল হ্যাঁ, পড এ পড বি এর সাথে যোগাযোগ করার জন্য, আপনাকে এটিকে একটি বহির্গামী সংযোগ তৈরি করার অনুমতি দিতে হবে (এর জন্য আপনাকে প্রস্থান নীতি কনফিগার করতে হবে), এবং পড বি অবশ্যই একটি ইনকামিং সংযোগ গ্রহণ করতে সক্ষম হবে। (এর জন্য, সেই অনুযায়ী, আপনার প্রবেশ-নীতি দরকার)।

যাইহোক, অনুশীলনে, আপনি এক বা উভয় দিকে সংযোগের অনুমতি দেওয়ার জন্য ডিফল্ট নীতির উপর নির্ভর করতে পারেন।

যদি কিছু পোদ-উৎস এক বা একাধিক দ্বারা নির্বাচিত হবে বহির্গমন-রাজনীতিবিদ, এর উপর আরোপিত বিধিনিষেধ নির্ধারিত হবে তাদের বিচ্ছিন্নতা দ্বারা। এই ক্ষেত্রে, আপনাকে স্পষ্টভাবে পডের সাথে সংযোগের অনুমতি দিতে হবেঠিকানা. যদি কোনো পড কোনো নীতি দ্বারা নির্বাচিত না হয়, তবে ডিফল্টরূপে এর বহির্গামী (প্রস্থান) ট্র্যাফিক অনুমোদিত হয়।

একইভাবে, পোদের ভাগ্য-ঠিকানাএক বা একাধিক দ্বারা নির্বাচিত প্রবেশ-নীতিগুলি তাদের বিচ্ছিন্নতার দ্বারা নির্ধারিত হবে। এই ক্ষেত্রে, আপনাকে অবশ্যই এটিকে সোর্স পড থেকে ট্র্যাফিক পাওয়ার অনুমতি দিতে হবে। যদি কোনো পড কোনো নীতি দ্বারা নির্বাচিত না হয়, তাহলে ডিফল্টরূপে এতে সমস্ত প্রবেশ ট্র্যাফিক অনুমোদিত হয়।

নীচে "রাষ্ট্রীয় বা রাষ্ট্রহীন" দেখুন।

লগ

Kubernetes নেটওয়ার্ক নীতিগুলি কীভাবে ট্র্যাফিক লগ করতে হয় তা জানে না। এটি একটি নীতি প্রত্যাশিত হিসাবে কাজ করছে কিনা তা নির্ধারণ করা কঠিন করে তোলে এবং নিরাপত্তা বিশ্লেষণকে খুব কঠিন করে তোলে।

বাহ্যিক পরিষেবাগুলিতে ট্রাফিক নিয়ন্ত্রণ

Kubernetes নেটওয়ার্ক নীতিগুলি আপনাকে বহির্গমন বিভাগে একটি সম্পূর্ণ যোগ্য ডোমেন নাম (DNS) নির্দিষ্ট করার অনুমতি দেয় না। এই তথ্যটি একটি উল্লেখযোগ্য অসুবিধার দিকে নিয়ে যায় যখন ট্রাফিককে সীমাবদ্ধ করার চেষ্টা করে বাইরের গন্তব্যে যেখানে একটি নির্দিষ্ট আইপি ঠিকানা নেই (যেমন aws.com)।

পলিসি চেক

ফায়ারওয়াল আপনাকে সতর্ক করবে বা এমনকি একটি ভুল নীতি গ্রহণ করতে অস্বীকার করবে। কুবারনেটস কিছু যাচাইকরণও করে। kubectl এর মাধ্যমে একটি নেটওয়ার্ক নীতি সেট করার সময়, Kubernetes ঘোষণা করতে পারে যে নীতিটি ভুল এবং এটি গ্রহণ করতে অস্বীকার করতে পারে। অন্যান্য ক্ষেত্রে, Kubernetes নীতিটি গ্রহণ করবে এবং অনুপস্থিত বিবরণ দিয়ে এটি পূরণ করবে। আপনি কমান্ড দিয়ে তাদের দেখতে পারেন:

kubernetes get networkpolicy <policy-name> -o yaml

মনে রাখবেন যে Kubernetes বৈধকরণ সিস্টেম ভুল নয় এবং কিছু ধরনের ত্রুটি মিস করতে পারে।

ফাঁসি

Kubernetes নিজে থেকে নেটওয়ার্ক নীতিগুলি প্রয়োগ করে না, তবে এটি শুধুমাত্র একটি API গেটওয়ে যা কন্টেইনার নেটওয়ার্কিং ইন্টারফেস (CNI) নামক একটি অন্তর্নিহিত সিস্টেমের উপর নিয়ন্ত্রণের বোঝা রাখে। একটি উপযুক্ত CNI বরাদ্দ না করে একটি Kubernetes ক্লাস্টারে নীতি নির্ধারণ করা ফায়ারওয়াল ম্যানেজমেন্ট সার্ভারে পরবর্তীতে ফায়ারওয়ালে সেট না করে নীতি নির্ধারণের অনুরূপ। আপনার কাছে একটি শালীন সিএনআই আছে কিনা তা নিশ্চিত করা বা কুবারনেট প্ল্যাটফর্মের ক্ষেত্রে, ক্লাউডে হোস্ট করা আপনার উপর নির্ভর করে (প্রদানকারীদের তালিকার জন্য দেখুন এখানে - প্রায়. ট্রান্স।), নেটওয়ার্ক নীতিগুলি সক্ষম করুন যা আপনার জন্য CNI সেট করবে৷

মনে রাখবেন যে আপনি উপযুক্ত সাহায্যকারী CNI ছাড়া নেটওয়ার্ক নীতি সেট করলে কুবারনেটস আপনাকে সতর্ক করবে না।

রাষ্ট্রীয় না রাষ্ট্রহীন?

আমি যে সমস্ত কুবারনেটস সিএনআইগুলি দেখেছি তা রাষ্ট্রীয় (উদাহরণস্বরূপ, ক্যালিকো লিনাক্স কনট্র্যাক ব্যবহার করে)। এটি পুনঃপ্রতিষ্ঠা না করেই শুরু করা TCP সংযোগে পডকে প্রতিক্রিয়া পেতে দেয়। যাইহোক, আমি একটি Kubernetes মান সম্পর্কে সচেতন নই যা রাষ্ট্রীয়তার গ্যারান্টি দেবে।

উন্নত নিরাপত্তা নীতি ব্যবস্থাপনা

কুবারনেটসে নিরাপত্তা নীতি প্রয়োগের দক্ষতা উন্নত করার কিছু উপায় এখানে দেওয়া হল:

1. সার্ভিস মেশ আর্কিটেকচারাল প্যাটার্ন সার্ভিস লেভেলে বিস্তারিত টেলিমেট্রি এবং ট্রাফিক কন্ট্রোল প্রদান করতে সাইডকার ব্যবহার করে। উদাহরণ হিসেবে কেউ নিতে পারেন ইসতিও.
2. কিছু CNI বিক্রেতা কুবারনেটস নেটওয়ার্ক নীতির বাইরে যাওয়ার জন্য তাদের সরঞ্জামগুলিকে প্রসারিত করেছে।
3. তুফিন ওরকা Kubernetes নেটওয়ার্ক নীতির স্বচ্ছতা এবং স্বয়ংক্রিয়তা প্রদান করে।

Tufin Orca প্যাকেজ Kubernetes নেটওয়ার্ক নীতিগুলি পরিচালনা করে (এবং উপরের স্ক্রিনশটের উৎস)।

অতিরিক্ত তথ্য

• GKE-এর আহমেত আল্প বলকান দ্বারা প্রস্তুত করা নেটওয়ার্ক নীতির উদাহরণ;
• অফিসিয়াল Kubernetes ওয়েবসাইট থেকে ডকুমেন্টেশন;
• কুবারনেটস নেটওয়ার্ক মডেল গাইড;
• নেটওয়ার্ক নীতি পরীক্ষা করার জন্য স্ক্রিপ্ট.

উপসংহার

কুবারনেটস নেটওয়ার্ক নীতিগুলি ক্লাস্টারগুলিকে ভাগ করার জন্য সরঞ্জামগুলির একটি ভাল সেট অফার করে, তবে সেগুলি স্বজ্ঞাত নয় এবং অনেক সূক্ষ্মতা রয়েছে৷ আমি বিশ্বাস করি যে এই জটিলতার কারণে, অনেকগুলি বিদ্যমান ক্লাস্টারের নীতিগুলি বগি। এই সমস্যার সম্ভাব্য সমাধান হল স্বয়ংক্রিয় নীতি সংজ্ঞা বা অন্যান্য বিভাজন সরঞ্জাম ব্যবহার করা।

আমি আশা করি এই নির্দেশিকাটি কিছু প্রশ্ন পরিষ্কার করতে এবং আপনার সম্মুখীন হতে পারে এমন সমস্যার সমাধান করতে সাহায্য করবে।

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• "ইসটিও সহ মাইক্রোসার্ভিসে ফিরে যান": অংশ 1 (প্রধান বৈশিষ্ট্যের ভূমিকা), পার্ট 2 (রাউটিং, ট্রাফিক নিয়ন্ত্রণ), অংশ 3 (নিরাপত্তা);
• "কুবারনেটসে নেটওয়ার্কিং এর একটি সচিত্র নির্দেশিকা": অংশ 1 এবং 2 (নেটওয়ার্ক মডেল, ওভারলে নেটওয়ার্ক), অংশ 3 (পরিষেবা এবং ট্রাফিক প্রক্রিয়াকরণ);
• «নিরাপত্তা-চাহিদার পরিবেশে ডকার এবং কুবারনেটস";
• «9 Kubernetes নিরাপত্তা সর্বোত্তম অভ্যাস";
• «কুবারনেটসে হ্যাক হওয়ার 11টি উপায় (না)».

উত্স: www.habr.com