Kubernetes + iptables

Hálózatok általános

Sziasztok

 

Van egy kubernetes alapú csoda, és azt szeretnénk, hogy az egyik rajta futó oldal csak bizonyos ip-kről legyen elérhető. Sajnos jó megoldással nem találkoztunk eddig. Van olyan, ami "magasabb rétegbeli" megoldás (calico), de annyira, hogy az iptables megoldások töredékét sem tudja, valamint átveszi teljesen a iptables feletti uralmat. Amivel csak annyi gond, hogy az alap beállításokat, többi portot azon a gépen nem iptables-ben kellene hanem az adott alakalmazásban megoldani (amit a limitációk miatt nem tudunk és viszonylag kényelmetlen is lenne, ha van már kidolgozott megoldás a automatizáció/környezet managelésére).

 

Docker esetén van egy sima tábla (DOCKER-USER ?), amit nem piszkál a docker. Van valami hasonló megoldás kubernetes alapú cuccokra is?

 

Köszi.

  • 816 megtekintés

( _Franko_ v | 2024. 07. 17., sze – 09:03 )

Egyrészt erre jelenleg a Cilium az aktuális buzzword, pont erre való, hogy ingress és egress tudj akár pod szintű tűzfal szabályokat: https://cilium.io/

Másrészt ez Kubernetes cluster felett lévő load-balancer dolga lenne, lehet szögelni ezt a pod network szinten (Calico és/vagy Ciilium), csak felesleges és antipattern.

https://iotguru.cloud

( NevemTeve | 2024. 07. 17., sze – 09:40 )

Esetleg tegyél elé egy dedikált routert, mindenféle idealizmus nélkül, sima iptables-sel. (De gyorsan, mert lehet, hogy holnap már a `nftables`-t is átnevezik valami másra.)

( djsmiley v | 2024. 07. 17., sze – 11:25 )

Ahogy már írták többen, ennyiből nehéz megmondani h. mi a megoldás.

Kellene tudni h. mi a LoadBalancer-ed, mi az Ingress controllered. Mivel azt írtad h. 1 oldalnál akarsz IP szűrést, ha alap design patternt nézünk, akkor valszeg 1 IP címen több oldalad is van, innentől a firewall based (lb és ingress szinten) megközelítés nem lesz jó.

Alkalmazás szinten kell szűrni az SNI után. Ezt okosabb LB v. az ingress tudja megcsinálni neked. Ez persze Lehet nginx, traefik, istio, kutyafüle. Szóval én arra keresnék h. $ingress_controllerem IP based access control.

( arpad | 2024. 07. 17., sze – 11:40 )

Először is csatlakozva az előttem szólókhoz ezt nem itt kellene megoldani.

Az hogy mi történik az iptables-el a hoston az attól függ hogy milyen CNI-t használsz. Ez alapján lehet bármit is mondani hogy hova tudsz szabályokat beszúrni (ismétlem, nem ezen a szinten kellene).

Mi egy kissé patkolt aws-vpc-cni-t használunk hogy legyen dual-stack támogatás, alapból nem tud dual-stacket, így eléggé mélyen ismerjük hogy mit és hova irkál. Emiatt bátrak vagyunk és belenyúlunk a host oldalon a bootstrap során az iptables szabályokba, de csak azért hogy bizonyos forgalmakat mérni tudjunk, nem hozzáférés korlátozás okán. Ha valami eltörné ezeket a szabályokat akkor csak pár belső grafikonon nem lenne adat, minimális a kockázat.

Ha mégis erre akarsz elmenni akkor ....

* Az iptables szabályokat minden node-ra rakd ki vagy korlátozd le hogy hol futhat az alkalmazás.

* Fixáld le a pod-ok IP címeit (jól emlékszem hogy ezt meg lehet tenni a specben?). De ha nagyon el akarod bonyolítani akkor írhatsz olyan kódot ami a futás során kérdez be az API szerverre (vagy watch-olja a podok az adott namespaceben) és aszerint kalapálja a szabályokat.

* Tényleg ne csináld, ha HTTP/HTTPS alapú a cucc akkor inkább rakj mellé egy sidecar nginx-et és abban szűrj ha nem vihető ez fel a load balancer rétegig ahol a helye lenne.

( golgota | 2024. 07. 18., cs – 08:55 )

Szerkesztve: 2024. 07. 18., cs – 08:57

Azert ezt legtobbszor ugy oldjuk meg, hogy van egy LB amit hasznal az ingress (akar meghatarozott IP cimet is), es a tuzfalon mondjuk meg, hogy az adott (fix) LB-s cimhez honnan es hogyan fornek hozza. Ez igaz mind onprem mind pedig felhos kornyezetben. De ahogy elottem is irtak akar az ingress oldalon is meg lehet fogni legyen az nginx, traefik, Kong.

Ja es fuggetlen attol hogy "kubernetes csoda"-rol van e szo vagy sem (ertem a gunyt, csak itt forditva sult el)  :D

Hiaba na megnyilik a vilag ha az ember ert ahhoz amivel dolgozik :D

 

Ha ez segit, metallb, nem kell sok minden hozzá,kb ennyi a lényeg, a service1  fut mondjuk 5 példányban, öt ip-n (ez a valami.local.net oldal) , de kifelé a 192.168.1.220 -on érhető el. 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress-k8s
  labels:
    app: nginx-ingress-k8s
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/use-forwarded-headers: "true"
spec:
  rules:
  - host: valami.local.net 
    http:
     paths:
     - pathType: Prefix
       path: "/"
       backend:
         service:
            name: service1
            port:
             number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: ingress
  namespace: ingress
spec:
  selector:
    name: nginx-ingress-k8s
  type: LoadBalancer
  loadBalancerIP: 192.168.1.220
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443

 

illetve az annotations részbe:

nginx.ingress.kubernetes.io/whitelist-source-range: 49.36.X.X/32

ezt még nem próbáltam, elvileg mennie kell.

https://blog.claryel.hu

( Sixday v | 2024. 07. 18., cs – 14:02 )

Szerkesztve: 2024. 07. 18., cs – 22:44

Ha kubernetes worker node-okon akarjatok kezzel kalapalgatni az iptables-t akkor teljesen biztosra veheto hogy halvany lila fogalmatok sincs arrol hogy hogyan mukodik valojaban a kubernetes.

Ezt a feladatot a halozati belepesi ponton, vagyis a loadbalanceren vagy ingress controlleren kell megoldani, de sokkal jobb lenne valoszinuleg mindenkinek ha ezt a feladatot leadnatok egy valoban hozzaertonek.

( vasla_ | 2024. 07. 18., cs – 15:15 )

Van egy kubernetes alapú csoda

érezhető a kezdő mondatból hogy  a kérést nem a kuberntes fun klub elnöksége írta, de a lényeget szerintem  leirtuk, te is leírtad. Gondolom valami egyszerű , azonnali gyors megoldást keresnének. Illetve szinte semmit nem tudunk a részletekről csak hogy van k8s valahol, valamilyen, erre kellene valami. 

https://blog.claryel.hu