🥇 د امنیتي مسلکیانو لپاره د کوبرنیټس شبکې تګلارو پیژندنه

نوټ. ژباړه: د مقالې لیکوال، ریوین هریسن، د سافټویر په پراختیا کې د 20 کلونو تجربه لري، او نن د CTO او د توفین شریک بنسټ ایښودونکی دی، هغه شرکت چې د امنیت پالیسۍ مدیریت حلونه رامینځته کوي. پداسې حال کې چې هغه د Kubernetes شبکې تګلارې په کلستر کې د شبکې ویشلو لپاره د کافي ځواکمن وسیلې په توګه ګوري، هغه دا هم باور لري چې په عمل کې پلي کول دومره اسانه ندي. دا مواد (کافي پراخه) د دې مسلې په اړه د متخصصینو پوهاوی ته وده ورکولو او د دوی سره د اړینو تشکیلاتو په رامینځته کولو کې مرسته کول دي.

نن ورځ، ډیری شرکتونه په زیاتیدونکي توګه د خپلو غوښتنلیکونو چلولو لپاره Kubernetes غوره کوي. پدې سافټویر کې علاقه دومره لوړه ده چې ځینې یې کوبرنیټس "د ډیټا مرکز لپاره نوی عملیاتي سیسټم" بولي. په تدریج سره، Kubernetes (یا k8s) د سوداګرۍ د یوې مهمې برخې په توګه پیژندل کیږي، کوم چې د بالغ سوداګرۍ پروسې تنظیم کولو ته اړتیا لري، په شمول د شبکې امنیت.

د امنیتي متخصصینو لپاره چې د کوبرنیټس سره د کار کولو له امله حیران شوي، ریښتینې انکشاف ممکن د پلیټ فارم ډیفالټ پالیسي وي: هرڅه ته اجازه ورکړئ.

دا لارښود به تاسو سره د شبکې د پالیسیو داخلي جوړښت په پوهیدو کې مرسته وکړي؛ پوهیږئ چې دوی څنګه د منظم فایروالونو قواعدو څخه توپیر لري. دا به ځینې نیمګړتیاوې هم پوښي او په کبرنیټس کې د خوندي غوښتنلیکونو کې د مرستې لپاره وړاندیزونه چمتو کړي.

د Kubernetes شبکې تګلارې

د Kubernetes شبکې پالیسي میکانیزم تاسو ته اجازه درکوي د شبکې پرت کې په پلیټ فارم کې ځای پرځای شوي غوښتنلیکونو تعامل اداره کړئ (د OSI ماډل کې دریم). د شبکې پالیسي د عصري فایروالونو ځینې پرمختللي ځانګړتیاوې نلري، لکه د 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

(نوټ. ژباړه: دا سکرین شاټ، لکه د نورو ورته ورته نورو په څیر، د اصلي Kubernetes وسیلو په کارولو سره نه، بلکې د توفین اورکا وسیلې په کارولو سره رامینځته شوی، کوم چې د اصلي مقالې لیکوال شرکت لخوا رامینځته شوی او کوم چې د موادو په پای کې ذکر شوی.)

د خپلې شبکې پالیسي تعریف کولو لپاره ، تاسو به د YAML لومړني پوهه ته اړتیا ولرئ. دا ژبه د انډیټیشن پر بنسټ ده (د ټبونو پرځای د ځایونو لخوا مشخص شوې). یو نښه شوی عنصر د دې پورته نږدې نږدې عنصر پورې اړه لري. د نوي لیست عنصر د هایفین سره پیل کیږي، نور ټول عناصر بڼه لري کلیدي ارزښت.

په YAML کې د پالیسۍ تشریح کولو سره، کارول kubectlپه کلستر کې د جوړولو لپاره:

kubectl create -f policy.yaml

د شبکې د پالیسۍ مشخصات

د Kubernetes شبکې پالیسۍ مشخصات څلور عناصر لري:

podSelector: د دې پالیسۍ لخوا اغیزمن شوي پوډونه تعریفوي (هدفونه) - اړین دي؛
policyTypes: په ګوته کوي چې کوم ډول پالیسۍ پدې کې شامل دي: داخلیدل او/یا اخراج - اختیاري، مګر زه وړاندیز کوم چې دا په ټولو قضیو کې په واضح ډول مشخص کړئ؛
ingress: اجازه تعریفوي راتلونکی د هدف پوډونو ته ترافیک - اختیاري؛
egress: اجازه تعریفوي وتلی د هدف پوډونو څخه ترافیک اختیاري دی.

د کوبرنیټس ویب پاڼې څخه اخیستل شوی مثال (ما بدل کړ 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 اجزاوو په څیر، د شبکې پالیسۍ په ځانګړي نوم ځای کې ژوند کوي. په بلاک کې 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 شیانو سره ضمیمه کړئ، لکه پوډونه او د نوم ځایونه. لیبلونه (ليبلونه - tags) په بادل کې د ټاګونو سره مساوي دي. د 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 په دې پالیسۍ کې، د هدف پوډونو ته راتلونکی ټرافیک خلاصوي. په بل عبارت، داخلیدل سرچینه ده او هدف ورته منزل دی. په همدې توګه، وتلو منزل دی او هدف یې سرچینه ده.

دا د دوو فایروال قواعدو سره مساوي دی: ننوتل → هدف؛ هدف → وتل.

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

مهرباني وکړئ په یاد ولرئ چې کومې اضافي تګلارې چې په نوم ځای کې پوډونو ته ټرافیک ته اجازه ورکوي د دې قاعدې په پرتله لومړیتوب لري (د فایروال ترتیب کې د انکار قاعدې دمخه د اجازې قاعدې اضافه کولو سره ورته).

هرڅه ته اجازه ورکړئ (هرچا ته اجازه ورکړئ)

د ټولو ته اجازه ورکولو پالیسي رامینځته کولو لپاره ، تاسو اړتیا لرئ د خالي عنصر سره پورته د رد کولو پالیسي ضمیمه کړئ 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

د ډیری پالیسیو ترکیب

پالیسۍ په دریو کچو کې د منطقي OR په کارولو سره یوځای کیږي؛ د هر پوډ اجازې د ټولو پالیسیو د جلا کولو سره سم تنظیم شوي چې دا اغیزه کوي:

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 سره ټیم جوړ کړئ

د ډیری شیانو (میزبان، شبکې، ګروپونو) سره د فایروال لپاره قواعد د منطقي 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

ورته منطق په ټولو ډولونو آپریټرونو باندې تطبیق کیږي: د پالیسۍ هدف ټاکونکي، پوډ ټاکونکي، او د نوم ځای ټاکونکي.

سبنيټ او IP پتې (IPBlocks)

فایروالونه د شبکې برخې کولو لپاره VLANs، IP پتې، او فرعي نیټونه کاروي.

په Kubernetes کې، IP پتې په اوتومات ډول پوډونو ته ګمارل شوي او په مکرر ډول بدلیدلی شي ، نو لیبلونه د شبکې په پالیسیو کې د پوډونو او نوم ځایونو غوره کولو لپاره کارول کیږي.

سبنيټ (ipBlocks) کارول کیږي کله چې د راتلوونکي (انګریس) یا وتلو (ایګریس) خارجي (شمال - سویل) اتصال اداره کړي. د مثال په توګه، دا پالیسي د نوم ځای څخه ټولو پوډونو ته خلاصیږي default د ګوګل 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 مشخص کړئ.

دا ډول میکانیزم باید فرعي غوره وګڼل شي: که چیرې د خدماتو داخلي جوړښت (د هغه بندرونه چې پوډونه یې اوري) بدلون ومومي، د شبکې پالیسۍ باید تازه شي.

د خدمت میش په کارولو سره نوې معمارۍ تګلاره (د مثال په توګه، لاندې د اسټیو په اړه وګورئ - تقریبا. ژباړه.) تاسو ته اجازه درکوي د دې ستونزې سره مقابله وکړئ.

ایا دا اړینه ده چې د ننوتلو او وتلو دواړه راجستر کړئ؟

لنډ ځواب هو دی، د پوډ A لپاره د پوډ B سره د خبرو اترو لپاره، دا باید اجازه ورکړل شي چې د وتلو اړیکې رامینځته کړي (د دې لپاره تاسو اړتیا لرئ د وتلو پالیسي ترتیب کړئ)، او پوډ B باید د دې وړتیا ولري چې راتلونکی پیوستون ومني ( د دې لپاره، تاسو د ننوتلو پالیسۍ ته اړتیا لرئ. پالیسي).

په هرصورت، په عمل کې، تاسو کولی شئ په ډیفالټ پالیسۍ تکیه وکړئ ترڅو په یو یا دواړو لارښوونو کې اړیکو ته اجازه ورکړئ.

که یو څه پوډ-سرچینه د یو یا ډیرو لخوا به غوره شي د- سیاستوال، په دې باندې لګول شوي محدودیتونه به د دوی د ګوښه کولو له لارې ټاکل کیږي. په دې حالت کې، تاسو اړتیا لرئ چې په واضح ډول د پوډ سره پیوستون ته اجازه ورکړئ -مخاطب ته. که چیرې یو پوډ د کومې پالیسۍ لخوا نه وي ټاکل شوی، د هغې د وتلو (ایګریس) ټرافیک په ډیفالټ اجازه ورکول کیږي.

په ورته ډول، د پوزې برخلیک دیادرس، د یو یا ډیرو لخوا غوره شوی ننوتل- سیاستوال به د دوی د ګوښه کیدو په واسطه ټاکل کیږي. په دې حالت کې، تاسو باید په واضح ډول اجازه ورکړئ چې د سرچینې پوډ څخه ټرافيک ترلاسه کړي. که چیرې یو پوډ د کومې پالیسۍ لخوا نه وي ټاکل شوی، د هغې لپاره ټول ټرافیک د ډیفالټ لخوا اجازه ورکول کیږي.

لاندې ریاست یا بې ریاسته وګورئ.

لوګو

د Kubernetes شبکې تګلارې نشي کولی ترافیک ثبت کړي. دا ستونزمنه کوي چې معلومه کړي چې آیا پالیسي د هدف په توګه کار کوي او د امنیت تحلیل خورا پیچلي کوي.

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

د Kubernetes شبکې تګلارې تاسو ته اجازه نه ورکوي چې د وتلو برخو کې د بشپړ وړ ډومین نوم (DNS) مشخص کړئ. دا حقیقت د پام وړ تکلیف لامل کیږي کله چې بهرنۍ منزلونو ته د ترافیک محدودولو هڅه کوي کوم چې ثابت IP پته نلري (لکه aws.com).

د پالیسۍ چک

فایروال به تاسو ته خبرداری درکړي یا حتی د غلط پالیسۍ منلو څخه انکار وکړي. Kubernetes یو څه تایید هم کوي. کله چې د kubectl له لارې د شبکې پالیسي ترتیب کړئ، Kubernetes ممکن اعلان کړي چې دا غلط دی او د منلو څخه انکار کوي. په نورو قضیو کې، Kubernetes به پالیسي واخلي او د ورک شوي توضیحاتو سره ډک کړي. دوی د کمانډ په کارولو سره لیدل کیدی شي:

kubernetes get networkpolicy <policy-name> -o yaml

په یاد ولرئ چې د Kubernetes د اعتبار سیسټم بې ځایه نه دی او ممکن ځینې ډولونه له لاسه ورکړي.

اجرا کول

Kubernetes پخپله د شبکې پالیسي نه پلي کوي، مګر یوازې د API دروازه ده چې د کانټینر شبکې انټرفیس (CNI) په نوم یو بنسټیز سیسټم ته د کنټرول بار لیږدوي. د مناسب CNI له ټاکلو پرته په Kubernetes کلستر کې د پالیسیو ترتیب کول د فایروال مدیریت سرور کې د پالیسیو رامینځته کولو سره ورته دي پرته لدې چې په فایر والونو کې یې نصب کړي. دا تاسو پورې اړه لري چې ډاډ ترلاسه کړئ چې تاسو ښه CNI لرئ یا د کوبرنیټس پلیټ فارمونو په حالت کې ، په کلاوډ کې کوربه شوی (تاسو کولی شئ د چمتو کونکو لیست وګورئ دلته - نږدې انتقال.)د شبکې تګلارې فعال کړئ چې ستاسو لپاره به CNI ټاکي.

په یاد ولرئ چې کوبرنیټس به تاسو ته خبرداری ورنکړي که تاسو د مناسب مرستندویه CNI پرته د شبکې پالیسي جوړه کړئ.

دولتي یا بې دولته؟

ټول Kubernetes CNIs چې ما ورسره مخ شوي دي دولتي دي (د مثال په توګه، کیلیکو د لینکس کانټریک کاروي). دا پوډ ته اجازه ورکوي چې د TCP پیوستون په اړه ځوابونه ترلاسه کړي پرته له دې چې بیا تاسیس کړي. په هرصورت، زه د Kubernetes معیار څخه خبر نه یم چې د بیان حالت تضمین کړي.

د پرمختللي امنیتي پالیسۍ مدیریت

دلته په Kubernetes کې د امنیتي پالیسۍ پلي کولو ښه کولو لپاره ځینې لارې شتون لري:

د خدماتو میش معماري نمونه د خدماتو په کچه د مفصل ټیلی میټري او ترافیک کنټرول چمتو کولو لپاره د سایډ کار کانټینرونه کاروي. د مثال په توګه موږ کولی شو اسټیټو.
د CNI ځینې پلورونکي د کوبرنیټس شبکې پالیسیو څخه هاخوا د تګ لپاره خپل وسیلې پراخه کړې.
توفین اورکا د Kubernetes شبکې پالیسیو لید او اتومات چمتو کوي.

د Tufin Orca بسته د Kubernetes شبکې پالیسۍ اداره کوي (او د پورته سکرین شاټونو سرچینه ده).

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

پایلې

د Kubernetes شبکې تګلارې د کلسترونو د قطع کولو لپاره د وسیلو ښه سیټ وړاندې کوي، مګر دوی هوښیار ندي او ډیری فرعي ټکي لري. د دې پیچلتیا له امله، زه باور لرم چې د کلستر ډیری موجوده پالیسۍ خرابې دي. د دې ستونزې لپاره ممکنه حلونه د پالیسۍ تعریفونو اتومات کول یا د نورو قطع کولو وسیلو کارول شامل دي.

زه امید لرم چې دا لارښود د ځینې پوښتنو روښانه کولو او هغه مسلو حل کولو کې مرسته وکړي چې تاسو ورسره مخ شئ.

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

"د اسټیو سره مایکرو خدماتو ته بیرته": لومړۍ برخه (د اصلي ځانګړتیاوو پیژندنه), دویمه برخه (روټینګ، د ترافیک کنټرول), دریمه برخه (امنیت);
"کوبرنیټس کې د شبکې جوړولو لپاره یو انځور شوی لارښود": 1 او 2 برخې (د شبکې ماډل، پوښښ شبکې), دریمه برخه (خدمات او ترافیک پروسس کول);
«د امنیت غوښتنې چاپیریال کې ډاکر او کبرنیټس»
«د Kubernetes امنیت لپاره 9 غوره کړنې»
«د کبرنیټس هیک قرباني کیدو لپاره (نه) 11 لارې".

سرچینه: www.habr.com

د امنیتي مسلکیانو لپاره د کوبرنیټس شبکې پالیسیو پیژندنه