Calico በ Kubernetes ውስጥ ለአውታረመረብ: መግቢያ እና ትንሽ ልምድ

የጽሁፉ አላማ አንባቢን በ Kubernetes ውስጥ ያሉትን የኔትወርክ ፖሊሲዎች እና የኔትወርክ ፖሊሲዎችን እንዲሁም የሶስተኛ ወገን Calico ፕለጊን መደበኛ አቅምን የሚያሰፋውን መሰረታዊ ነገሮች ማስተዋወቅ ነው። በመንገዳችን ላይ፣ የማዋቀር ቀላልነት እና አንዳንድ ባህሪያት ከአሰራር ልምዳችን እውነተኛ ምሳሌዎችን በመጠቀም ይታያሉ።

የኩበርኔትስ አውታረ መረብ መሳሪያ ፈጣን መግቢያ

የኩበርኔትስ ክላስተር ያለ አውታረ መረብ ሊታሰብ አይችልም። ቀደም ሲል በመሠረታቸው ላይ ቁሳቁሶችን አሳትመናል-“በ Kubernetes ውስጥ ለአውታረመረብ የተብራራ መመሪያ"እና"ለደህንነት ባለሙያዎች የኩበርኔትስ አውታረ መረብ ፖሊሲዎች መግቢያ».

በዚህ ጽሑፍ አውድ ውስጥ K8s በራሱ በመያዣዎች እና በአንጓዎች መካከል የአውታረ መረብ ግንኙነት ተጠያቂ እንዳልሆነ ልብ ሊባል የሚገባው ነው-ለዚህም, የተለያዩ. የ CNI ተሰኪዎች (የመያዣ አውታረመረብ በይነገጽ)። ስለዚህ ጽንሰ-ሐሳብ የበለጠ እኛ ብለው ነገሩኝ።.

ለምሳሌ, ከእነዚህ ተሰኪዎች ውስጥ በጣም የተለመደው Flannel - በእያንዳንዱ መስቀለኛ መንገድ ላይ ድልድዮችን በማሳደግ በሁሉም የክላስተር ኖዶች መካከል ሙሉ የአውታረ መረብ ግንኙነትን ይሰጣል፣ ንኡስ ኔትን ይመድባል። ይሁን እንጂ የተሟላ እና ቁጥጥር ያልተደረገበት ተደራሽነት ሁልጊዜ ጠቃሚ አይደለም. በክላስተር ውስጥ አንድ ዓይነት አነስተኛ ማግለል ለማቅረብ, በፋየርዎል ውቅር ውስጥ ጣልቃ መግባት አስፈላጊ ነው. በአጠቃላይ ሁኔታ, በተመሳሳዩ CNI ቁጥጥር ስር ነው የተቀመጠው, ለዚህም ነው በ iptables ውስጥ ማንኛውም የሶስተኛ ወገን ጣልቃገብነት በስህተት ሊተረጎም ወይም ሙሉ በሙሉ ችላ ሊባል የሚችለው.

እና በ Kubernetes ክላስተር ውስጥ የኔትወርክ ፖሊሲ አስተዳደርን ለማደራጀት "ከሳጥኑ ውጭ" ቀርቧል የአውታረ መረብ ፖሊሲ ​​ኤ.ፒ.አይ. ይህ ምንጭ፣ በተመረጡ የስም ቦታዎች ላይ የሚሰራጩ፣ ከአንድ መተግበሪያ ወደ ሌላው መዳረሻን ለመለየት ደንቦችን ሊይዝ ይችላል። እንዲሁም በተወሰኑ ፖዶች፣ አካባቢዎች (ስም ቦታዎች) ወይም የአይፒ አድራሻዎች ብሎኮች መካከል ተደራሽነትን እንዲያዋቅሩ ይፈቅድልዎታል።

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: 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

ይህ በጣም ጥንታዊው ምሳሌ አይደለም ኦፊሴላዊ ሰነዶች የአውታረ መረብ ፖሊሲዎች እንዴት እንደሚሠሩ አመክንዮ የመረዳት ፍላጎትን ለአንዴና ለመጨረሻ ጊዜ ተስፋ ሊያስቆርጥ ይችላል። ሆኖም ግን አሁንም የኔትወርክ ፖሊሲዎችን በመጠቀም የትራፊክ ፍሰቶችን የማቀናበር መሰረታዊ መርሆችን እና ዘዴዎችን ለመረዳት እንሞክራለን...

2 የትራፊክ ዓይነቶች መኖራቸው ምክንያታዊ ነው-ወደ ፖድ (ኢንግሬስ) እና ከእሱ መውጣት (ኢግረስ)።

በእውነቱ ፖለቲካ በእንቅስቃሴ አቅጣጫ ላይ በመመስረት በእነዚህ 2 ምድቦች ይከፈላል ።

የሚቀጥለው አስፈላጊ ባህሪ መራጭ ነው; ደንቡ የሚመለከተው. ይህ ፖድ (ወይም የቡድኖች ስብስብ) ወይም አካባቢ (ማለትም የስም ቦታ) ሊሆን ይችላል. ጠቃሚ ዝርዝር፡ ሁለቱም የነዚህ ነገሮች ዓይነቶች መለያ መያዝ አለባቸው (ምልክት በኩበርኔትስ ቃላቶች) - እነዚህ ፖለቲከኞች የሚሠሩት እነዚህ ናቸው.

በአንድ ዓይነት መለያ ከተዋሃዱ ውሱን የመራጮች ብዛት በተጨማሪ፣ እንደ “ሁሉንም ነገር ፍቀድ/መከልከል/ሁሉም ሰው” ያሉ ደንቦችን በተለያዩ ልዩነቶች መፃፍ ይቻላል። ለዚሁ ዓላማ, የቅጹ ግንባታዎች ጥቅም ላይ ይውላሉ:

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

- በዚህ ምሳሌ ፣ በአከባቢው ውስጥ ያሉ ሁሉም ፓዶች ከገቢ ትራፊክ ታግደዋል። ተቃራኒው ባህሪ በሚከተለው ግንባታ ሊከናወን ይችላል-

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

በተመሳሳይ መልኩ ለመውጣት፡-

  podSelector: {}
  policyTypes:
  - Egress

- ለማጥፋት. እና ምን ማካተት እንዳለበት እነሆ፡-

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

ወደ ክላስተር የ CNI ተሰኪ ምርጫ ስንመለስ ያንን ልብ ሊባል የሚገባው ጉዳይ ነው። እያንዳንዱ የአውታረ መረብ ፕለጊን የኔትወርክ ፖሊሲን አይደግፍም።. ለምሳሌ, ቀደም ሲል የተጠቀሰው Flannel የአውታረ መረብ ፖሊሲዎችን እንዴት ማዋቀር እንዳለበት አያውቅም የሚለው በቀጥታ ነው። በኦፊሴላዊው ማከማቻ ውስጥ. አንድ አማራጭ እዚያም ተጠቅሷል - ክፍት ምንጭ ፕሮጀክት ካሊኮ, ይህም የ Kubernetes ኤ ፒ አይዎችን ከአውታረ መረብ ፖሊሲዎች አንፃር በከፍተኛ ሁኔታ ያሰፋዋል.

ከ Calico ጋር መተዋወቅ: ቲዎሪ

የ Calico ፕለጊን ከ Flannel (ንዑስ ፕሮጀክት) ጋር በማጣመር ጥቅም ላይ ሊውል ይችላል። ቦይ) ወይም በተናጥል ሁለቱንም የአውታረ መረብ ግንኙነት እና የተገኝነት አስተዳደር ችሎታዎችን ይሸፍናል።

የ K8s "የቦክስ" መፍትሄ እና ከካሊኮ የተዘጋጀውን ኤፒአይ በመጠቀም ምን እድሎችን ይሰጣል?

በNetworkPolicy ውስጥ ምን እንደተገነባ እነሆ፡-

• ፖለቲከኞች በአካባቢው የተገደቡ ናቸው;
• ፖሊሲዎች በመለያዎች ምልክት በተደረገባቸው ፖድዎች ላይ ይተገበራሉ;
• ደንቦች በፖዳዎች, አከባቢዎች ወይም ንዑስ መረቦች ላይ ሊተገበሩ ይችላሉ;
• ደንቦች ፕሮቶኮሎችን፣ የተሰየሙ ወይም ምሳሌያዊ የወደብ ዝርዝሮችን ሊይዙ ይችላሉ።

ካሊኮ እነዚህን ተግባራት እንዴት እንደሚያሰፋ እነሆ፡-

• ፖሊሲዎች በማንኛውም ነገር ላይ ሊተገበሩ ይችላሉ: ፖድ, መያዣ, ምናባዊ ማሽን ወይም በይነገጽ;
• ደንቦች አንድ የተወሰነ እርምጃ ሊይዙ ይችላሉ (ክልከላ, ፍቃድ, መግባት);
• ዒላማው ወይም የሕጎች ምንጭ ወደብ፣ የተለያዩ ወደቦች፣ ፕሮቶኮሎች፣ HTTP ወይም ICMP ባህርያት፣ አይፒ ወይም ንዑስ መረብ (4ኛ ወይም 6ኛ ትውልድ)፣ ማንኛውም መራጮች (አንጓዎች፣ አስተናጋጆች፣ አካባቢዎች) ሊሆኑ ይችላሉ።
• በተጨማሪም፣ የDNAT ቅንብሮችን እና የትራፊክ ማስተላለፊያ ፖሊሲዎችን በመጠቀም የትራፊክ ምንባቡን መቆጣጠር ይችላሉ።

የመጀመሪያው በ GitHub በካሊኮ ማከማቻ ውስጥ በጁላይ 2016 ይፈፀማል, እና ከአንድ አመት በኋላ ፕሮጀክቱ Kubernetes አውታረ መረብ ግንኙነትን በማደራጀት ረገድ ግንባር ቀደም ቦታ ወሰደ - ይህ ለምሳሌ በዳሰሳ ጥናት ውጤቶች ተረጋግጧል. በኒው ቁልል የተካሄደ:

ከK8s ጋር ብዙ ትልቅ የሚተዳደሩ መፍትሄዎች፣እንደ Amazon EX, Azure AKS, ጉግል GKE እና ሌሎች ጥቅም ላይ እንዲውል ምክር መስጠት ጀመሩ.

እንደ አፈጻጸም, ሁሉም ነገር እዚህ ጥሩ ነው. ምርታቸውን በመፈተሽ የካሊኮ ልማት ቡድን በሴኮንድ 50000 ኮንቴይነሮች የመፍጠር ፍጥነት ከ500 በላይ ኮንቴይነሮችን በ20 ፊዚካል ኖዶች ላይ በመሮጥ የስነ ፈለክ አፈጻጸም አሳይቷል። በመጠን ላይ ምንም ችግሮች አልተለዩም. እንደዚህ ያሉ ውጤቶች ይፋ ተደረገ ቀድሞውኑ በመጀመሪያው ስሪት ማስታወቂያ ላይ. በግብአት እና በንብረት ፍጆታ ላይ ያተኮሩ ገለልተኛ ጥናቶች የካሊኮ አፈጻጸም የፍላኔል ያህል ጥሩ መሆኑን ያረጋግጣሉ። ለምሳሌ:

ፕሮጀክቱ በጣም በፍጥነት በማደግ ላይ ነው, በ K8s, OpenShift, OpenStack በሚተዳደሩ ታዋቂ መፍትሄዎች ውስጥ ስራን ይደግፋል, ክላስተር ሲጠቀም ካሊኮ መጠቀም ይቻላል. ኮፕስየአገልግሎት ሜሽ ኔትወርኮች ግንባታ (ማጣቀሻዎች) አሉ።አንድ ምሳሌ እዚህ አለ ከኢስቲዮ ጋር ተያይዞ ጥቅም ላይ የዋለ).

ከ Calico ጋር ይለማመዱ

በአጠቃላይ የቫኒላ ኩበርኔትስ አጠቃቀም CNI ን መጫን ፋይሉን ለመጠቀም ይወርዳል calico.yaml, ከኦፊሴላዊው ድር ጣቢያ ወርዷል, በመጠቀም kubectl apply -f.

እንደ ደንቡ ፣ የአሁኑ የፕለጊን ስሪት ከቅርብ ጊዜዎቹ 2-3 የ Kubernetes ስሪቶች ጋር ተኳሃኝ ነው-በአሮጌ ስሪቶች ውስጥ ያለው አሠራር አልተሞከረም እና ዋስትና የለውም። እንደ ገንቢዎቹ ከሆነ ካሊኮ ከ3.10 በላይ CentOS 7፣ኡቡንቱ 16 ወይም ዴቢያን 8ን በሚያሄዱ የሊኑክስ ከርነሎች ላይ ይሰራል፣በአይፓፕ ወይም አይፒቪኤስ ላይ።

በአከባቢው ውስጥ መገለል

ለአጠቃላይ ግንዛቤ፣ በካሊኮ ማስታወሻ ውስጥ ያሉት የአውታረ መረብ ፖሊሲዎች ከመደበኛ ደረጃዎች እንዴት እንደሚለያዩ እና ደንቦችን የመፍጠር አቀራረብ እንዴት ተነባቢነታቸውን እና ውቅር ተለዋጭነታቸውን እንደሚያቃልል ለመረዳት ቀላል ጉዳይን እንመልከት፡-

በክላስተር ውስጥ 2 ዌብ አፕሊኬሽኖች ተዘርግተዋል፡ በ Node.js እና PHP ውስጥ አንዱ Redis ይጠቀማል። ከNode.js ጋር ያለውን ግንኙነት በማስቀጠል የRedisን ከ PHP መዳረሻን ለማገድ የሚከተለውን መመሪያ ይተግብሩ።

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

በመሰረቱ ከ Node.js ወደ Redis ወደብ ገቢ ትራፊክ ፈቅደናል። እና በግልጽ ሌላ ምንም ነገር አልከለከሉም. የኔትዎርክ ፖሊሲ እንደወጣ፣ በውስጡ የተጠቀሱት ሁሉም መራጮች ካልተገለጹ በስተቀር ማግለል ይጀምራሉ። ነገር ግን የመገለል ደንቦቹ በመራጩ ያልተካተቱ ሌሎች ነገሮች ላይ አይተገበሩም።

ምሳሌው ይጠቀማል apiVersion ከሳጥኑ ውስጥ Kubernetes, ነገር ግን ምንም ነገር እንዳይጠቀሙበት የሚከለክልዎት ነገር የለም ተመሳሳይ ስም ያለው ምንጭ ከ Calico መላኪያ. እዚያ ያለው አገባብ የበለጠ ዝርዝር ነው፣ ስለዚህ ከላይ ላለው ጉዳይ ደንቡን በሚከተለው ቅጽ እንደገና መፃፍ ያስፈልግዎታል።

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

ከላይ የተገለጹት ግንባታዎች በመደበኛው የአውታረ መረብ ፖሊሲ ​​ኤፒአይ ሁሉንም ትራፊክ ለመፍቀድ ወይም ለመከልከል ለመረዳት እና ለማስታወስ አስቸጋሪ የሆኑ ቅንፍ ያላቸው ግንባታዎችን ይይዛሉ። በካሊኮ ሁኔታ, የፋየርዎል ህግን አመክንዮ ወደ ተቃራኒው ለመለወጥ, መለወጥ ብቻ ነው action: Allow ላይ action: Deny.

በአከባቢ ማግለል

አሁን አንድ መተግበሪያ በፕሮሜቲየስ ውስጥ ለመሰብሰብ የንግድ መለኪያዎችን የሚያመነጭበትን ሁኔታ እና ግራፋናን በመጠቀም ተጨማሪ ትንታኔን ያስቡ። ሰቀላው ሚስጥራዊነት ያለው ውሂብ ሊይዝ ይችላል፣ ይህም እንደገና በይፋ በነባሪነት የሚታይ ነው። ይህን ውሂብ ከሚታዩ ዓይኖች እንሰውረው፡-

ፕሮሜቴየስ እንደ አንድ ደንብ በተለየ የአገልግሎት አካባቢ ውስጥ ተቀምጧል - በምሳሌው ውስጥ እንደዚህ ያለ የስም ቦታ ይሆናል.

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

መስክ metadata.labels ይህ በአጋጣሚ አልነበረም። ከላይ እንደተጠቀሰው. namespaceSelector (እንዲሁም podSelector) ከስያሜዎች ጋር ይሰራል። ስለዚህ፣ መለኪያዎች በአንድ የተወሰነ ወደብ ላይ ካሉ ሁሉም ፖድዎች እንዲወሰዱ ለመፍቀድ አንድ ዓይነት መለያ ማከል አለብዎት (ወይም ካሉት ይውሰዱ) እና ከዚያ እንደዚህ ያለ ውቅር ይተግብሩ፡

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

እና የ Calico ፖሊሲዎችን ከተጠቀሙ ፣ አገባቡ እንደዚህ ይሆናል

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

በአጠቃላይ፣ ለተወሰኑ ፍላጎቶች እነዚህን አይነት ፖሊሲዎች በማከል በክላስተር ውስጥ ባሉ አፕሊኬሽኖች ስራ ላይ ከተንኮል ወይም ድንገተኛ ጣልቃገብነት መከላከል ይችላሉ።

እንደ ካሊኮ ፈጣሪዎች በጣም ጥሩው ልምምድ በ ውስጥ የተመዘገበው "ሁሉንም ነገር አግድ እና የሚፈልጉትን በግልጽ ይክፈቱ" የሚለው አካሄድ ነው። ኦፊሴላዊ ሰነዶች (ሌሎችም ተመሳሳይ አካሄድ ይከተላሉ - በተለይም በ ቀደም ሲል የተጠቀሰው ጽሑፍ).

ተጨማሪ የ Calico ነገሮችን መጠቀም

ላስታውስህ በተዘረጋው የ Calico ኤፒአይዎች ስብስብ በፖድ ብቻ ሳይሆን የኖዶች መገኘትን መቆጣጠር ትችላለህ። በሚከተለው ምሳሌ በመጠቀም GlobalNetworkPolicy በክላስተር ውስጥ የ ICMP ጥያቄዎችን የማለፍ ችሎታ ተዘግቷል (ለምሳሌ ፣ ፒንግ ከፖድ ወደ መስቀለኛ መንገድ ፣ በፖድ መካከል ፣ ወይም ከአንጓ ወደ IP ፖድ)

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

ከላይ በተጠቀሰው ሁኔታ፣ የክላስተር ኖዶች በ ICMP በኩል እርስ በርስ “ለመዳረስ” አሁንም ይቻላል። እና ይህ ጉዳይ በመሳሪያዎች መፍትሄ ያገኛል GlobalNetworkPolicy, ለአንድ አካል ተተግብሯል HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

የቪፒኤን ጉዳይ

በመጨረሻም፣ መደበኛ የፖሊሲዎች ስብስብ በቂ ካልሆነ የካሊኮ ተግባራትን ስለ ቅርብ ክላስተር መስተጋብር ለመጠቀም በጣም እውነተኛ ምሳሌ እሰጣለሁ። የድረ-ገጽ አፕሊኬሽኑን ለመድረስ ደንበኞቻቸው የቪፒኤን ዋሻ ይጠቀማሉ፣ እና ይህ መዳረሻ በጥብቅ ቁጥጥር የሚደረግበት እና ለአገልግሎት በተፈቀደ ልዩ የአገልግሎት ዝርዝር የተገደበ ነው።

ደንበኞች ከቪፒኤን ጋር በመደበኛ የUDP ወደብ 1194 ይገናኛሉ እና ሲገናኙ ወደ ክላስተር የፖድ እና አገልግሎቶች ንኡስ መረቦች ይቀበላሉ። እንደገና በሚጀመርበት ጊዜ እና በአድራሻ ለውጦች ወቅት አገልግሎቶችን ላለማጣት ሙሉ ንዑስ አውታረ መረቦች ይገፋሉ።

በማዋቀሩ ውስጥ ያለው ወደብ መደበኛ ነው, ይህም አፕሊኬሽኑን በማዋቀር እና ወደ ኩበርኔትስ ክላስተር በማስተላለፍ ሂደት ላይ አንዳንድ ልዩነቶችን ያስገድዳል. ለምሳሌ፣ በዚያው AWS LoadBalancer ለ UDP ውስጥ ባለፈው ዓመት መጨረሻ ላይ በተወሰኑ ክልሎች ዝርዝር ውስጥ ቃል በቃል ታየ፣ እና ኖድፖርት በሁሉም የክላስተር ኖዶች ላይ በማስተላለፉ ምክንያት ጥቅም ላይ ሊውል አይችልም እና የአገልጋይ ምሳሌዎችን ብዛት ለመለካት የማይቻል ነው። የስህተት መቻቻል ዓላማዎች። በተጨማሪም፣ ነባሪውን የወደብ ክልል መቀየር አለብህ...

ሊሆኑ የሚችሉ መፍትሄዎችን በመፈለግ ምክንያት, የሚከተለው ተመርጧል.

1. ቪፒኤን ያላቸው ፖዶች በአንድ መስቀለኛ መንገድ መርሐግብር ተይዞላቸዋል hostNetwork, ማለትም, ወደ ትክክለኛው አይፒ.
2. አገልግሎቱ በውጭ በኩል የተለጠፈ ነው። ClusterIP. በመስቀለኛ መንገድ ላይ አንድ ወደብ በአካል ተጭኗል፣ ይህም ከውጭው በጥቃቅን የተያዙ ቦታዎች (የእውነተኛ አይፒ አድራሻ መኖር) ተደራሽ ነው።
3. ፖድ ሮዝ ያለበትን መስቀለኛ መንገድ መወሰን ከታሪካችን ወሰን በላይ ነው። እኔ እላለሁ ፣ አገልግሎቱን በመስቀለኛ መንገድ ላይ በጥብቅ “ምስማር” ወይም ትንሽ የጎን መኪና አገልግሎት አሁን ያለውን የቪፒኤን አገልግሎት አይፒ አድራሻ የሚቆጣጠር እና በደንበኞች የተመዘገቡትን የዲ ኤን ኤስ መዝገቦችን የሚያስተካክል - በቂ ምናብ ያለው ማንም ይሁን።

ከማዘዋወር አንፃር፣ የቪፒኤን ደንበኛን በቪፒኤን አገልጋይ በሚሰጠው የአይፒ አድራሻው መለየት እንችላለን። ከዚህ በታች በተጠቀሰው ሬዲስ ላይ የተገለጸው የዚህ አይነት ደንበኛን የአገልግሎቶች መዳረሻ የመገደብ ቀዳሚ ምሳሌ አለ፡-

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

እዚህ ፣ ወደብ 6379 መገናኘት በጥብቅ የተከለከለ ነው ፣ ግን በተመሳሳይ ጊዜ የዲ ኤን ኤስ አገልግሎት ሥራ ተጠብቆ ይቆያል ፣ ይህም ሕጎችን ሲያወጣ ብዙ ጊዜ ይሠቃያል ። ምክንያቱም ቀደም ሲል እንደተገለፀው አንድ መራጭ ሲመጣ ነባሪው ውድቅ ፖሊሲ በሌላ መልኩ ካልተገለጸ በስተቀር በእሱ ላይ ይተገበራል።

ውጤቶች

ስለዚህ የCalico የላቀ ኤፒአይን በመጠቀም በክላስተር ውስጥ እና በዙሪያው ያለውን አቅጣጫ በተለዋዋጭ ማዋቀር እና በተለዋዋጭ መንገድ መቀየር ይችላሉ። በአጠቃላይ አጠቃቀሙ ድንቢጦችን በመድፍ መተኮስ ሊመስል ይችላል፣ እና የኤል 3 ኔትወርክን ከ BGP እና IP-IP ዋሻዎች ጋር መተግበሩ በጠፍጣፋ አውታረመረብ ላይ በቀላል የኩበርኔትስ ጭነት ውስጥ በጣም አስፈሪ ይመስላል ... ሆኖም ፣ ይህ ካልሆነ መሣሪያው በጣም ጠቃሚ እና ጠቃሚ ይመስላል። .

የደህንነት መስፈርቶችን ለማሟላት ክላስተርን ማግለል ሁልጊዜ የሚቻል ላይሆን ይችላል፣ እና እዚህ ላይ ካሊኮ (ወይም ተመሳሳይ መፍትሄ) ለማዳን የሚመጣው። በዚህ ጽሑፍ ውስጥ የተሰጡት ምሳሌዎች (በጥቃቅን ማሻሻያዎች) በAWS ውስጥ በበርካታ የደንበኞቻችን ጭነቶች ውስጥ ጥቅም ላይ ይውላሉ።

PS

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

• «ለደህንነት ባለሙያዎች የኩበርኔትስ አውታረ መረብ ፖሊሲዎች መግቢያ";
• "በኩበርኔትስ ውስጥ ለአውታረመረብ የተብራራ መመሪያ"፡- ክፍል 1 እና 2 (የኔትወርክ ሞዴል ፣ ተደራቢ አውታረ መረቦች), ክፍል 3 (አገልግሎት እና የትራፊክ ሂደት);
• «ኮንቴይነር አውታረመረብ በይነገጽ (ሲኤንአይ) - የአውታረ መረብ በይነገጽ እና ለሊኑክስ መያዣዎች መደበኛ».

ምንጭ: hab.com