ለደህንነት ባለሙያዎች የኩበርኔትስ አውታረ መረብ ፖሊሲዎች መግቢያ

ማስታወሻ. ትርጉምየጽሁፉ ደራሲ - ሬውቨን ሃሪሰን - በሶፍትዌር ልማት ውስጥ ከ 20 ዓመታት በላይ ልምድ ያለው ሲሆን ዛሬ CTO እና የቱፊን የደህንነት ፖሊሲ አስተዳደር መፍትሄዎች ኩባንያ መስራች ነው። የኩበርኔትስ የኔትወርክ ፖሊሲዎች ኔትወርኩን በክላስተር ውስጥ ለመከፋፈል ሃይለኛ እንደሆኑ ቢቆጥርም፣ በተግባር ግን ተግባራዊ ለማድረግ ቀላል እንዳልሆኑ ያምናል። ይህ ቁሳቁስ (ይልቁን ጥራዝ) በዚህ ጉዳይ ላይ የልዩ ባለሙያዎችን ግንዛቤ ለማሻሻል እና አስፈላጊውን ውቅረት ለመፍጠር እንዲረዳቸው የታሰበ ነው።

ዛሬ ብዙ ኩባንያዎች መተግበሪያዎቻቸውን ለማካሄድ Kubernetes እየመረጡ ነው። የዚህ ሶፍትዌር ፍላጎት በጣም ከፍተኛ ከመሆኑ የተነሳ አንዳንዶች Kubernetes "አዲሱ ስርዓተ ክወና ለዳታ ማእከሎች" ብለው ይጠሩታል. ቀስ በቀስ ኩበርኔትስ (ወይም k8s) የኔትወርክ ደህንነትን ጨምሮ የጎለመሱ የንግድ ሂደቶችን ማደራጀት የሚያስፈልገው የንግድ ሥራ ወሳኝ አካል እንደሆነ መታወቅ ይጀምራል።

ከኩበርኔትስ ጋር በመሥራት ግራ የገባቸው የደህንነት ባለሙያዎች የዚህ መድረክ ነባሪ ፖሊሲ እውነተኛ ግኝት ሊሆን ይችላል፡ ሁሉንም ነገር ፍቀድ።

ይህ መመሪያ የኔትወርክ ፖሊሲዎችን ውስጣዊ አሠራር ለመረዳት ይረዳዎታል; ከመደበኛ ፋየርዎል ደንቦች እንዴት እንደሚለያዩ ይረዱ። እንዲሁም ስለ አንዳንድ ወጥመዶች ይናገራል እና በ Kubernetes ውስጥ መተግበሪያዎችን ለመጠበቅ የሚረዱ ምክሮችን ይሰጣል።

Kubernetes አውታረ መረብ ፖሊሲዎች

የ Kubernetes አውታረ መረብ ፖሊሲ ​​ዘዴ በአውታረ መረቡ ንብርብር (በ OSI ሞዴል ውስጥ ሦስተኛው) በመድረኩ ላይ የተዘረጉትን የመተግበሪያዎች መስተጋብር እንዲያስተዳድሩ ይፈቅድልዎታል። የአውታረ መረብ ፖሊሲዎች እንደ OSI Layer 7 ቁጥጥር እና ስጋትን መለየት ያሉ አንዳንድ የዘመናዊ ፋየርዎል ባህሪያት የላቸውም ነገር ግን ጥሩ መነሻ የሆነ መሰረታዊ የአውታረ መረብ ደህንነት ሽፋን ይሰጣሉ።

የአውታረ መረብ ፖሊሲዎች በፖድ መካከል ግንኙነቶችን ይቆጣጠራሉ።

በኩበርኔትስ ውስጥ ያሉ የሥራ ጫናዎች በአንድ ላይ ተዘርግተው አንድ ወይም ከዚያ በላይ ኮንቴይነሮችን ያቀፈ በፖዳዎች ላይ ይሰራጫሉ። ኩበርኔትስ ለእያንዳንዱ ፖድ ከሌላ ፖድ የሚገኝ IP አድራሻ ይመድባል። የኩበርኔትስ አውታረ መረብ ፖሊሲዎች በደመና ውስጥ ያሉ የደህንነት ቡድኖች የቨርቹዋል ማሽን አጋጣሚዎችን ለመቆጣጠር በሚጠቀሙበት መንገድ ለፖድ ቡድኖች የመዳረሻ ፍቃዶችን ያዘጋጃሉ።

የአውታረ መረብ ፖሊሲዎችን መግለጽ

ልክ እንደሌሎች የኩበርኔትስ ምንጮች፣ የአውታረ መረብ ፖሊሲዎች በ 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በክላስተር ውስጥ ለመፍጠር፡-

kubectl create -f policy.yaml

የአውታረ መረብ ፖሊሲ ​​ዝርዝር

የኩበርኔትስ አውታረ መረብ ፖሊሲ ​​ዝርዝር አራት አካላትን ያካትታል፡-

1. podSelectorበዚህ ፖሊሲ (ዒላማዎች) የተጎዱትን ፖድዎች ይገልጻል - ያስፈልጋል;
2. policyTypesበዚህ ውስጥ ምን ዓይነት የፖሊሲ ዓይነቶች እንደሚካተቱ ይጠቁማል፡ መግባት እና/ወይም መውጣት - አማራጭ ነው፣ ግን በሁሉም ጉዳዮች ላይ በግልፅ እንዲገለጽ እመክራለሁ።
3. ingress: የሚፈቀደው ይገልጻል ገቢ ትራፊክ ወደ ዒላማ ፓዶች - አማራጭ;
4. 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 ተትቷል፣ መመሪያው ሁሉንም ትራፊክ ይከለክላል (ከዚህ በታች ያለውን "የጥረግ ህግ" ይመልከቱ)።

ነባሪ ፖሊሲ - ፍቀድ

ምንም ፖሊሲዎች ካልተገለጹ ኩበርኔትስ ሁሉንም ትራፊክ በነባሪነት ይፈቅዳል። ሁሉም ፖድዎች በነፃነት እርስ በርስ መረጃ መለዋወጥ ይችላሉ. ከደህንነት እይታ አንጻር ይህ ተቃራኒ ሊመስል ይችላል፣ ነገር ግን ኩበርኔትስ በመጀመሪያ የተፈጠረው አፕሊኬሽኖችን እርስበርስ እንዲሰሩ ለማድረግ በማቀድ በገንቢዎች እንደተፈጠረ ያስታውሱ። የአውታረ መረብ መመሪያዎች በኋላ ላይ ታክለዋል።

የስም ቦታዎች

የስም ቦታዎች የኩበርኔትስ የትብብር ዘዴ ናቸው። በነባሪነት በክፍተቶች መካከል ግንኙነት እንዲኖር ሲፈቅዱ አመክንዮአዊ አካባቢዎችን እርስ በእርስ ለመነጠል የተነደፉ ናቸው።

ልክ እንደ አብዛኛዎቹ የኩበርኔትስ አካላት፣ የአውታረ መረብ ፖሊሲዎች በአንድ የተወሰነ የስም ቦታ ውስጥ ይኖራሉ። በብሎክ ውስጥ 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

መለያዎች

ብጁ መለያዎች እንደ ፖድ እና የስም ቦታዎች ካሉ ከኩበርኔትስ ነገሮች ጋር ማያያዝ ይችላሉ። መለያዎች (መለያዎች መለያዎች) በደመና ውስጥ ካሉ መለያዎች ጋር እኩል ናቸው። የኩበርኔትስ አውታረ መረብ ፖሊሲዎች ለመምረጥ መለያዎችን ይጠቀማሉ እንክብሎችየሚያመለክቱበት፡-

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:
...

ምንጭ እና መድረሻ

የፋየርዎል ፖሊሲዎች የምንጭ እና መድረሻ ደንቦችን ያቀፉ ናቸው። የኩበርኔትስ አውታረ መረብ ፖሊሲዎች በአንድ ዒላማ ይገለፃሉ፣ የሚተገበሩባቸው የፖድ ስብስብ እና ከዚያ የመግቢያ እና/ወይም መውጫ ትራፊክ ህጎችን ያዘጋጃሉ። በእኛ ምሳሌ፣ የመመሪያው ኢላማ በስም ቦታ ውስጥ ያሉ ሁሉም ፖዶች ይሆናሉ 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 ልዩ ትኩረት ይስጡ - ኩበርኔትስ አገልግሎቶችን ወደ አይፒ አድራሻዎች ለመቅረጽ ይህንን አገልግሎት ይጠቀማል። ለምሳሌ፣ ማመልከቻውን ስላልፈቀዱ የሚከተለው ፖሊሲ አይሰራም balance የዲ ኤን ኤስ መዳረሻ

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

የዲ ኤን ኤስ አገልግሎት መዳረሻን በመክፈት ማስተካከል ይችላሉ፡-

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 አገልግሎት ይላኩ (ብዙውን ጊዜ በቦታ ውስጥ ይሰራል kube-system).

ይህ አካሄድ ግን ይሰራል ከመጠን በላይ ፍቃደኛ እና አስተማማኝ ያልሆነየዲ ኤን ኤስ መጠይቆችን ከጥቅሉ ውጭ እንዲመሩ ስለሚያደርግ ነው።

በሶስት ተከታታይ ደረጃዎች ማሻሻል ይችላሉ.

1. የዲኤንኤስ ጥያቄዎችን ብቻ ፍቀድ ውስጥ በማከል ክላስተር 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. የዲኤንኤስ መጠይቆችን በስም ቦታ ብቻ ፍቀድ 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. "በስም ቦታ እና በፖድ አጣራ" ክፍል ይህንን እንዴት ማሳካት እንደሚችሉ ያሳየዎታል።

ሌላው አማራጭ ዲ ኤን ኤስ በስም ቦታ ደረጃ መፍታት ነው። በዚህ አጋጣሚ ለእያንዳንዱ አገልግሎት መክፈት አያስፈልግም፡-

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 በስም ቦታ ውስጥ ያሉትን ሁሉንም ፖዶች ይመርጣል.

የመጀመሪያ ግጥሚያ እና ደንብ ቅደም ተከተል

በተለመደው ፋየርዎል ውስጥ, በፓኬት ላይ ያለው እርምጃ (ፍቀድ ወይም ውድቅ) የሚወሰነው በሚያረካው የመጀመሪያው ህግ ነው. በኩበርኔትስ፣ የፖሊሲዎች ቅደም ተከተል ለውጥ የለውም።

በነባሪነት ምንም አይነት ፖሊሲ ካልተዋቀረ በፖድ መካከል መግባባት ይፈቀዳል እና መረጃን በነፃ መለዋወጥ ይችላሉ። ፖሊሲዎችን መቅረጽ እንደጀመሩ፣ ቢያንስ በአንዱ የተጎዳው እያንዳንዱ ፖድ በመረጡት ፖሊሲዎች ልዩነት (ሎጂክ 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

መዳረሻን ይሰጣል ሁሉም ፖድዎች በሁሉም የስም ቦታዎች (እና ሁሉም አይፒዎች) በስም ቦታ ውስጥ ወዳለ ማንኛውም ፖድ 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 አመክንዮአዊ እና ይህን ይመስላል።

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

ለምንድነው ከተለመደው ወይም እንደ 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

በርካታ መለያዎች ከ AND ጋር ይጣመራሉ።

ከበርካታ አካላት (አስተናጋጆች፣ ኔትወርኮች፣ ቡድኖች) ጋር የፋየርዎል ህጎች አመክንዮአዊ OR በመጠቀም ይጣመራሉ። የፓኬቱ ምንጭ ከተዛመደ የሚከተለው ህግ ይቃጠላል። Host_1 ወይም Host_2:

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

በተቃራኒው፣ በኩበርኔትስ ውስጥ የተለያዩ መለያዎች በ ውስጥ podSelector ወይም namespaceSelector ከአመክንዮአዊ እና ጋር ይጣመራሉ ለምሳሌ፣ የሚከተለው ህግ ሁለቱም መለያዎች ያላቸውን ፖድ ይመርጣል። role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

ተመሳሳይ አመክንዮ በሁሉም አይነት መግለጫዎች ላይ ተግባራዊ ይሆናል፡ የፖሊሲ ኢላማ መራጮች፣ ፖድ መራጮች እና የስም ቦታ መራጮች።

ንዑስ አውታረ መረቦች እና አይፒ አድራሻዎች (IPBlocks)

ፋየርዎል ኔትወርክን ለመከፋፈል VLANsን፣ IP አድራሻዎችን እና ንዑስ መረቦችን ይጠቀማሉ።

በ Kubernetes ውስጥ የአይፒ አድራሻዎች በራስ ሰር ወደ ፖድ ይመደባሉ እና ብዙ ጊዜ ሊለወጡ ይችላሉ, ስለዚህ መለያዎች በኔትወርክ ፖሊሲዎች ውስጥ ፖድ እና የስም ቦታዎችን ለመምረጥ ያገለግላሉ.

ንዑስ መረቦች (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 መዳረሻ ብቻ ይፈቅዳል; ወደ ሌላ አይፒ መድረስ የተከለከለ ነው። ስለዚህ፣ በመሠረቱ፣ የውስጣዊውን የኩበርኔትስ ዲ ኤን ኤስ አገልግሎት መዳረሻን አግደዋል። አሁንም መክፈት ከፈለጉ በግልጽ ይግለጹ።

አብዛኛውን ጊዜ 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), ይህም ማለት ሁሉም ወደቦች ማለት ነው.

ምርጥ ልምምድ፡ በነባሪ እሴቶች ላይ አትተማመኑ፣ የሚፈልጉትን በግልፅ ይግለጹ።

አገልግሎቶችን ሳይሆን የፖድ ወደቦችን መጠቀም እንደሚያስፈልግዎ ልብ ይበሉ (በሚቀጥለው አንቀጽ በዚህ ላይ ተጨማሪ)።

ለፖድ ወይም አገልግሎቶች የተገለጹ መመሪያዎች?

አብዛኛውን ጊዜ በኩበርኔትስ ውስጥ ያሉ ፖድዎች በአገልግሎት በኩል እርስ በርስ ይገናኛሉ - አገልግሎቱን ወደሚተገበሩ ፖድዶች የሚመራ ምናባዊ ጭነት ሚዛን። የአውታረ መረብ ፖሊሲዎች የአገልግሎቶችን ተደራሽነት ይቆጣጠራሉ ብለው ሊያስቡ ይችላሉ፣ ግን እንደዛ አይደለም። የኩበርኔትስ የአውታረ መረብ ፖሊሲዎች ከአገልግሎቶች ጋር ሳይሆን ከፖድ ወደቦች ጋር ይሰራሉ።

ለምሳሌ አንድ አገልግሎት በፖርት 80 ላይ የሚያዳምጥ ከሆነ ነገር ግን ትራፊክን ወደ 8080 ፖድዶች ካዘዋወረ በኔትወርክ ፖሊሲ ውስጥ 8080 ን መግለጽ አለብዎት።

እንዲህ ዓይነቱ ዘዴ ንዑስ-ምርጥ እንደሆነ መታወቅ አለበት-የአገልግሎቱ ውስጣዊ መሣሪያ (ፖድ የሚያዳምጡ ወደቦች) ከተቀየረ የአውታረ መረብ ፖሊሲዎች መዘመን አለባቸው።

የአገልግሎት ሜሽን በመጠቀም አዲስ የስነ-ህንፃ አቀራረብ (ለምሳሌ፣ ስለ ኢስቲዮ ከታች ይመልከቱ - approx. transl.) ይህንን ችግር ለመቋቋም ያስችልዎታል.

ሁለቱንም Ingress እና Egress መጻፍ አስፈላጊ ነው?

አጭር መልሱ አዎ ነው፣ፖድ A ከፖድ ቢ ጋር ለመገናኘት የወጪ ግንኙነት እንዲፈጥር መፍቀድ አለቦት (ለዚህም የኢግረስ ፖሊሲን ማዋቀር ያስፈልግዎታል) እና ፖድ B ገቢ ግንኙነትን መቀበል መቻል አለበት። (ለዚህ, በዚህ መሠረት, የመግቢያ ፖሊሲ ያስፈልግዎታል).

ነገር ግን፣ በተግባር፣ ግንኙነቶችን በአንድ ወይም በሁለቱም አቅጣጫዎች ለመፍቀድ በነባሪ ፖሊሲ ላይ መተማመን ይችላሉ።

አንዳንድ ፖድ ከሆነ -ምንጩ በአንድ ወይም በብዙ ይመረጣል ለምሳሌ- ፖለቲከኞች, በእሱ ላይ የተጣሉት እገዳዎች የሚወሰኑት በእነሱ ልዩነት ነው. በዚህ ሁኔታ ከፖድ ጋር ያለውን ግንኙነት በግልፅ መፍቀድ ያስፈልግዎታልaddressee. ፖድ በማናቸውም ፖሊሲ ካልተመረጠ፣ የወጪ (መውጣት) ትራፊክ በነባሪነት ይፈቀዳል።

በተመሳሳይም የፖዳው ዕጣ ፈንታአድራሻ ተቀባይበአንድ ወይም ከዚያ በላይ የተመረጠ እድገት- ፖሊሲዎች በአቋራጭነታቸው ይወሰናሉ። በዚህ አጋጣሚ ከምንጩ ፖድ ትራፊክ እንዲቀበል በግልፅ መፍቀድ አለብዎት። ፖድ በማንኛውም ፖሊሲ ካልተመረጠ፣ ወደ እሱ የሚገቡት ሁሉም ትራፊክ በነባሪነት ይፈቀዳሉ።

ከታች ያለውን "መንግስታዊ ወይም ሀገር የለሽ" ይመልከቱ።

መዝገቦች

የኩበርኔትስ ኔትወርክ ፖሊሲዎች ትራፊክ እንዴት እንደሚገቡ አያውቁም። ይህ ፖሊሲ እንደተጠበቀው እየሰራ መሆኑን ለመወሰን አስቸጋሪ ያደርገዋል እና የደህንነት ትንተና በጣም አስቸጋሪ ያደርገዋል.

የትራፊክ ቁጥጥር ወደ ውጫዊ አገልግሎቶች

የ Kubernetes አውታረ መረብ ፖሊሲዎች በመውጣት ክፍሎች ውስጥ ሙሉ ብቃት ያለው የጎራ ስም (ዲ ኤን ኤስ) እንዲገልጹ አይፈቅዱም። ይህ እውነታ ቋሚ የአይፒ አድራሻ ወደሌላቸው ውጫዊ መዳረሻዎች (እንደ aws.com) ትራፊክን ለመገደብ በሚሞከርበት ጊዜ ወደ ከፍተኛ ችግር ያመራል።

የፖሊሲ ማረጋገጫ

ፋየርዎል ያስጠነቅቀዎታል ወይም የተሳሳተ ፖሊሲን ለመቀበል አሻፈረኝ ይላል። ኩበርኔትስ አንዳንድ ማረጋገጫዎችን ያደርጋል። የኔትዎርክ ፖሊሲን በkubectl ሲያቀናብሩ ኩበርኔትስ ፖሊሲው ትክክል እንዳልሆነ ሊያውጅ እና ሊቀበለው ሊቃወመው ይችላል። በሌሎች ሁኔታዎች, Kubernetes ፖሊሲውን ወስዶ የጎደሉትን ዝርዝሮች ይሞላል. በትእዛዙ ልታያቸው ትችላለህ፡-

kubernetes get networkpolicy <policy-name> -o yaml

ያስታውሱ የኩበርኔትስ ማረጋገጫ ስርዓት የማይሳሳት እና አንዳንድ አይነት ስህተቶችን ሊያመልጥ ይችላል።

አፈፃፀም

ኩበርኔትስ የኔትወርክ ፖሊሲዎችን በራሱ አያስፈጽምም ነገር ግን የቁጥጥር ሸክሙን ኮንቴይነር ኔትወርክ ኢንተርፌስ (ሲኤንአይ) በሚባለው ስር ስርዓት ላይ የሚያስቀምጥ የኤፒአይ መግቢያ በር ብቻ ነው። ተገቢውን CNI ሳይመድቡ በኩበርኔትስ ክላስተር ላይ ፖሊሲዎችን ማቀናበር በፋየርዎል አስተዳደር አገልጋይ ላይ ፖሊሲዎችን ከማዘጋጀት ጋር ተመሳሳይ ነው። ጥሩ CNI እንዳለዎት ማረጋገጥ ወይም በ Kubernetes መድረኮች ላይ በደመና ውስጥ መስተናገዱን ማረጋገጥ የእርስዎ ምርጫ ነው። (ለአቅራቢዎች ዝርዝር ይመልከቱ እዚህ - በግምት. ትራንስ.)፣ CNI ን ለእርስዎ የሚያዘጋጁ የአውታረ መረብ ፖሊሲዎችን ያንቁ።

ያለ ተገቢው ረዳት CNI የአውታረ መረብ ፖሊሲ ​​ካዘጋጁ Kubernetes እንደማያስጠነቅቅ ልብ ይበሉ።

አገር ያለው ወይስ አገር አልባ?

ያጋጠሙኝ ሁሉም የኩበርኔትስ ሲኤንአይኤዎች ሁኔታዊ ናቸው (ለምሳሌ ካሊኮ የሊኑክስ ኮንትራክተር ይጠቀማል)። ይህ ፖድ እንደገና ማቋቋም ሳያስፈልገው በጀመረው የTCP ግንኙነት ላይ ምላሾችን እንዲቀበል ያስችለዋል። ሆኖም፣ ለግዛትነት ዋስትና የሚሰጥ የኩበርኔትስ መስፈርት አላውቅም።

የላቀ የደህንነት ፖሊሲ አስተዳደር

በ Kubernetes ውስጥ የደህንነት ፖሊሲ ማስፈጸሚያ ቅልጥፍናን ለማሻሻል አንዳንድ መንገዶች እዚህ አሉ።

1. የሰርቪስ ሜሽ አርክቴክቸር ጥለት በአገልግሎት ሽፋን ላይ ዝርዝር ቴሌሜትሪ እና የትራፊክ ቁጥጥርን ለማቅረብ የጎን መኪናዎችን ይጠቀማል። እንደ ምሳሌ, አንድ ሰው መውሰድ ይችላል Istio.
2. አንዳንድ የCNI አቅራቢዎች ከኩበርኔትስ አውታረ መረብ ፖሊሲዎች በላይ ለመሄድ መሳሪያቸውን አራዝመዋል።
3. ቱፊን ኦርካ የ Kubernetes አውታረ መረብ ፖሊሲዎችን ግልፅነት እና አውቶማቲክን ይሰጣል።

የ Tufin Orca ጥቅል የኩበርኔትስ አውታረ መረብ ፖሊሲዎችን ያስተዳድራል (እና ከላይ ያሉት የቅጽበታዊ ገጽ እይታዎች ምንጭ ነው)።

ተጨማሪ መረጃ

• በአህሜት አልፕ ባልካን በ GKE የተዘጋጀ የአውታረ መረብ ፖሊሲ ​​ምሳሌዎች;
• ከኦፊሴላዊው የኩበርኔትስ ድህረ ገጽ የተገኘ ሰነድ;
• Kubernetes አውታረ መረብ ሞዴል መመሪያ;
• የአውታረ መረብ መመሪያዎችን ለመፈተሽ ስክሪፕት.

መደምደሚያ

የኩበርኔትስ አውታረ መረብ ፖሊሲዎች ዘለላዎችን ለመከፋፈል ጥሩ የመሳሪያዎች ስብስብ ይሰጣሉ፣ነገር ግን ሊታወቁ የሚችሉ አይደሉም እና ብዙ ስውር ዘዴዎች አሏቸው። በዚህ ውስብስብነት ምክንያት የብዙ ነባር ዘለላዎች ፖሊሲዎች አስቸጋሪ ናቸው ብዬ አምናለሁ። ለዚህ ችግር ሊሆኑ የሚችሉ መፍትሄዎች የፖሊሲ ትርጓሜዎችን በራስ-ሰር ማድረግ ወይም ሌሎች የመከፋፈያ መሳሪያዎችን መጠቀም ናቸው።

ይህ መመሪያ አንዳንድ ጥያቄዎችን ለማጥራት እና ሊያጋጥሙ የሚችሉ ችግሮችን ለመፍታት እንደሚረዳ ተስፋ አደርጋለሁ።

PS ከተርጓሚ

በብሎጋችን ላይ ያንብቡ፡-

• "ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ"፡- ክፍል 1 (የዋና ዋና ባህሪያት መግቢያ), ክፍል 2 (ማዘዋወር ፣ የትራፊክ ቁጥጥር), ክፍል 3 (ደህንነት);
• "በኩበርኔትስ ውስጥ ለአውታረመረብ የተብራራ መመሪያ"፡- ክፍል 1 እና 2 (የኔትወርክ ሞዴል ፣ ተደራቢ አውታረ መረቦች), ክፍል 3 (አገልግሎት እና የትራፊክ ሂደት);
• «ዶከር እና ኩበርኔትስ በደህንነት-ጠያቂ አካባቢዎች";
• «9 Kubernetes ደህንነት ምርጥ ልምዶች";
• «በኩበርኔትስ ውስጥ ለመጥለፍ (አይደለም) 11 መንገዶች».

ምንጭ: hab.com