จะเพิ่มทราฟฟิกขาออกที่อนุญาตพิเศษด้วย NetworkPolicy ที่ไม่ได้ป้องกัน Apache Ignite ไม่ให้เริ่มต้นได้อย่างไร

ฉันมีสถาปัตยกรรมไมโครเซอร์วิสที่ซับซ้อนไม่มากก็น้อย ซึ่ง Apache Ignite ถูกใช้เป็นฐานข้อมูล / แคชที่ไม่มีสถานะ จุดชนวน พ็อด เป็นสิ่งเดียวที่ พ็อด ในนั้น เนมสเปซ และสถาปัตยกรรมต้องผ่านการตรวจสอบความปลอดภัย ซึ่งจะไม่ผ่านถ้าฉันไม่ใช้มาตรการที่เข้มงวดที่สุด นโยบายเครือข่าย เป็นไปได้สำหรับ ทางออก การจราจร. ต้องจำกัดการรับส่งข้อมูลที่เป็นไปได้ทั้งหมดที่ Ignite ไม่ต้องการ

ตอนแรกฉันคิดว่า: ดีมาก Ignite ไม่ส่งทราฟฟิกไปที่อื่น พ็อดs (ไม่มีพ็อดอื่นอยู่ในนั้น เนมสเปซ) ดังนั้นการจำกัดทั้งหมดจะทำได้อย่างง่ายดาย ทางออก การจราจรใน เนมสเปซ ที่ Ignite เป็นที่เดียว พ็อด! ...

นั่นไม่ได้ผลดีจริง ๆ :
ใดๆ ทางออก แม้ว่าฉันจะอนุญาตการรับส่งข้อมูลไปยังพอร์ตทั้งหมดที่กล่าวถึงใน Ignite Documentation ก็จะทำให้การเริ่มต้นทำงานล้มเหลวด้วย IgniteSpiException ที่กล่าวว่า เรียกข้อมูลที่อยู่ IP ของ Ignite pods ไม่สำเร็จ, เกิดจาก: java.net.ConnectException: การทำงานหมดเวลา (การเชื่อมต่อหมดเวลา).

ปัญหาน่าจะอยู่ที่ TcpDiscoveryKubernetsIpFinderโดยเฉพาะอย่างยิ่งวิธีการ รับที่อยู่ลงทะเบียน(...) ซึ่งเห็นได้ชัดว่ามีการจราจรขาออกบางส่วนภายใน เนมสเปซ เพื่อลงทะเบียนที่อยู่ IP ของโหนด Ignite แน่นอนว่าอนุญาตให้ใช้พอร์ต disovery 47500 แต่นั่นไม่ได้เปลี่ยนสถานการณ์ การทำงานของ Ignite กับตัวอื่นๆ พ็อดจากที่อื่น เนมสเปซs กำลังทำงานโดยไม่มี ทางออก ใช้กฎซึ่งหมายความว่า (สำหรับฉัน) การกำหนดค่าที่เกี่ยวข้อง คลัสเตอร์บทบาท, ClusterRoleBinding, ก บริการ ใน เนมสเปซ และการกำหนดค่า xml ของ Ignite เอง ฯลฯ ดูเหมือนจะถูกต้อง สม่ำเสมอ ขาเข้า กฎที่จำกัดทราฟฟิกจากเนมสเปซอื่นกำลังทำงานตามที่คาดไว้ ทำให้สามารถทราฟฟิกที่ต้องการได้

นี่คือนโยบายที่ฉันใช้:

[ทำงาน บล็อกทราฟฟิกที่ไม่ต้องการเท่านั้น]:

## ปฏิเสธการรับส่งข้อมูลขาเข้าทั้งหมดไปยังพ็อดทั้งหมดในเนมสเปซ
รุ่น api: networking.k8s.io/v1
ชนิด: NetworkPolicy
ข้อมูลเมตา:
  ชื่อ: ปฏิเสธทุกขาเข้าในแคช ns
  เนมสเปซ: cache-ns
ข้อมูลจำเพาะ:
  # การไม่เลือกอะไรเลยที่นี่จะปฏิเสธการรับส่งข้อมูลทั้งหมดระหว่างพ็อดในเนมสเปซ
  ตัวเลือกพ็อด:
    ป้ายกำกับที่ตรงกัน: {}
  # เส้นทางการจราจรที่ต้องพิจารณาที่นี่: ขาเข้าเท่านั้น
  ประเภทนโยบาย:
    - ขาเข้า

## อนุญาตการรับส่งข้อมูลขาเข้าที่จำเป็น
รุ่น api: networking.k8s.io/v1
ชนิด: NetworkPolicy
ข้อมูลเมตา:
  ชื่อ: netpol-cache-ns
  เนมสเปซ: cache-ns
# กำหนดพ็อดที่นโยบายนี้กำหนดเป้าหมาย
ข้อมูลจำเพาะ:
  ประเภทนโยบาย:
    - ขาเข้า
  ตัวเลือกพ็อด:
    ป้ายกำกับการแข่งขัน:
      แอพ:จุดไฟ
  # <----การจราจรขาเข้า----
  ทางเข้า:
    - จาก:
      - เนมสเปซตัวเลือก:
          ป้ายกำกับการแข่งขัน:
            โซน: ที่อื่น
        ตัวเลือกพ็อด:
          การจับคู่นิพจน์:
            - คีย์: แอป
              ผู้ดำเนินการ: ใน
              ค่า: [some-pod, another-pod] # ชื่อจำลอง Pods เหล่านี้ไม่สำคัญเลย
      พอร์ต:
        - พอร์ต: 11211 # JDBC
          โปรโตคอล: TCP
        - พอร์ต: การสื่อสาร 47100 # SPI
          โปรโตคอล: TCP
        - พอร์ต: 47500 # การค้นพบ SPI (สำคัญ เป็นไปได้มากที่สุด...)
          โปรโตคอล: TCP
        - พอร์ต: 10800 # SQL
          โปรโตคอล: TCP
# ----การจราจรขาออก---->
# ไม่มีเลย

เมื่อใช้สองสิ่งนี้ ทุกอย่างทำงานได้ดี แต่การตรวจสอบความปลอดภัยจะพูดบางอย่างในทำนองเดียวกัน
ข้อจำกัดสำหรับ ทางออก? จะเกิดอะไรขึ้นหากโหนดนี้ถูกแฮ็กผ่านเส้นทางที่อนุญาต เนื่องจากหนึ่งในพ็อดที่ใช้เส้นทางเหล่านี้เคยถูกแฮ็กมาก่อน มันอาจจะเรียกเซิร์ฟเวอร์ C&C ก็ได้! การกำหนดค่านี้จะไม่ได้รับอนุญาต ทำให้สถาปัตยกรรมของคุณแข็งขึ้น!

[การบล็อกการรับส่งข้อมูลที่ต้องการ/จำเป็น]:

โดยทั่วไปจะปฏิเสธการเข้าชมทั้งหมด...

## ปฏิเสธการรับส่งข้อมูลทั้งหมดไปยังพ็อดทั้งหมดในเนมสเปซ
รุ่น api: networking.k8s.io/v1
ชนิด: NetworkPolicy
ข้อมูลเมตา:
  ชื่อ: ปฏิเสธการรับส่งข้อมูลทั้งหมดในแคช ns
  เนมสเปซ: cache-ns
ข้อมูลจำเพาะ:
  # การไม่เลือกอะไรเลยที่นี่จะปฏิเสธการรับส่งข้อมูลทั้งหมดระหว่างพ็อดในเนมสเปซ
  ตัวเลือกพ็อด:
    ป้ายกำกับที่ตรงกัน: {}
  # เส้นทางการจราจรที่ต้องพิจารณาที่นี่: ขาเข้าเท่านั้น
  ประเภทนโยบาย:
    - ขาเข้า
    - ทางออก # <------ นี่คือความแตกต่างของการทำงานข้างต้น

... และอนุญาตให้ใช้เส้นทางเฉพาะในภายหลัง

รุ่น api: networking.k8s.io/v1
ชนิด: NetworkPolicy
ข้อมูลเมตา:
  ชื่อ: netpol-cache-ns-egress
  เนมสเปซ: cache-ns
# กำหนดพ็อดที่นโยบายนี้กำหนดเป้าหมาย
ข้อมูลจำเพาะ:
  ประเภทนโยบาย:
    - ขาออก
  ตัวเลือกพ็อด:
    ป้ายกำกับการแข่งขัน:
      แอพ:จุดไฟ
  ----การจราจรขาออก---->
  ทางออก:
    # [ไม่เพียงพอ]
    # อนุญาตให้ออกไปยังเนมสเปซนี้ที่พอร์ตเฉพาะ
    - ถึง:
      - เนมสเปซตัวเลือก:
          ป้ายกำกับการแข่งขัน:
            โซน: แคชโซน
      พอร์ต:
        - โปรโตคอล: TCP
          พอร์ต: 10800
        - โปรโตคอล: TCP
          พอร์ต: 47100 # การสื่อสาร SPI
        - โปรโตคอล: TCP
          พอร์ต: 47500
    # [ไม่เพียงพอ]
    # อนุญาตการแก้ไข DNS โดยทั่วไป (ไม่มีข้อ จำกัด เนมสเปซหรือพ็อด)
    - พอร์ต:
      - โปรโตคอล: TCP
        ท่าเรือ: 53
      - โปรโตคอล: UDP
        ท่าเรือ: 53
    # [ไม่เพียงพอ]
    # อนุญาตให้ออกสู่ระบบ kube (มีป้ายกำกับอยู่!)
    - ถึง:
      - เนมสเปซตัวเลือก:
          ป้ายกำกับการแข่งขัน:
            โซน: ระบบ kube
    # [ไม่เพียงพอ]
    # อนุญาตให้ออกในเนมสเปซนี้และสำหรับพ็อดจุดไฟ
    - ถึง:
      - เนมสเปซตัวเลือก:
          ป้ายกำกับการแข่งขัน:
            โซน: แคชโซน
        ตัวเลือกพ็อด:
          ป้ายกำกับการแข่งขัน:
            แอพ:จุดไฟ
    # [ไม่เพียงพอ]
    # อนุญาตให้รับส่งข้อมูลไปยังที่อยู่ IP ของพ็อดจุดไฟ
    - ถึง:
      - ไอพีบล็อค:
          cidr: 172.21.70.49/32 # จะทำงานได้ไม่ดีเนื่องจากที่อยู่เหล่านั้นเป็นไดนามิก
      พอร์ต:
        - พอร์ต: 11211 # JDBC
          โปรโตคอล: TCP
        - พอร์ต: การสื่อสาร 47100 # SPI
          โปรโตคอล: TCP
        - พอร์ต: 47500 # การค้นพบ SPI (สำคัญ เป็นไปได้มากที่สุด...)
          โปรโตคอล: TCP
        - พอร์ต: 49112 # JMX
          โปรโตคอล: TCP
        - พอร์ต: 10800 # SQL
          โปรโตคอล: TCP
        - พอร์ต: 8080 # REST
          โปรโตคอล: TCP
        - พอร์ต: 10900 # ไคลเอนต์แบบบาง
          โปรโตคอล: TCP

เวอร์ชัน Apache Ignite ที่ใช้คือ 2.10.0

ตอนนี้คำถามสำหรับผู้อ่านทุกคนคือ:

ฉันจะ จำกัด ได้อย่างไร ขาออก ให้น้อยที่สุดภายใน เนมสเปซ เพื่อให้ Ignite เริ่มทำงานและทำงานได้อย่างถูกต้อง? แค่ปฏิเสธก็เพียงพอแล้วหรือ ขาออก นอกคลัสเตอร์?

หากคุณต้องการเพิ่มเติม ยาเมลสำหรับการเดาหรือคำใบ้ที่มีการศึกษา โปรดส่งคำขอในความคิดเห็น
และขออภัยสำหรับการแท็กหากเห็นว่าไม่เหมาะสม ฉันหาแท็กไม่พบ kubernetes-นโยบายเครือข่าย ตามที่ปรากฏใน stackoverflow

อัปเดต:

กำลังดำเนินการ nslookup -debug kubernetes.default.svc.cluster.local จากภายในฝักจุดไฟโดยไม่มีนโยบายจำกัด ทางออก แสดง

BusyBox v1.29.3 (2019-01-24 07:45:07 UTC) ไบนารีหลายสาย

การใช้งาน: nslookup โฮสต์ [DNS_SERVER]

สอบถาม DNS เกี่ยวกับ HOST

ทันทีที่ (มี) นโยบายเครือข่าย ถูกนำไปใช้ที่จำกัด ขาออก ไปยังพอร์ต พ็อด และเนมสเปซเฉพาะ Ignite pod ปฏิเสธที่จะเริ่มต้นและการค้นหาไม่ถึง kubernetes.default.svc.cluster.local อีกต่อไป.

ขาออก อนุญาตให้ใช้ DNS (UDP 53 ถึง k8s-app: kube-dns) â ยังไม่สามารถค้นหา ip ได้