Cererea de manipulare bazată pe sursa ip cu traefik în k8s

Am un cluster k8s (trei vms pe propriul hardware, nu aws, Google cloud, ...) care utilizează traefik ( https://traefik.io/ ) ca proxy invers pentru a răspunde serviciilor/implementărilor în fundal.

For this I use the deployment-variant from this part of the documentation: https://docs.traefik.io/user-guide/kubernetes/#deploy-trfik-using-a-deployment-or-daemonset

Acum, am mai multe aplicații implementate în cluster, care au toate atribuite anumite intrări, care sunt citite de traefik-ingress-controller . Unele dintre aceste aplicații sunt interne, cum ar fi kibana sau traefik-web-ui , iar altele sunt externe, precum aplicațiile în sine. Disting aceste două prin introducerea de intrări diferite de DNS (de exemplu, https://dashboard.internal.mycoolapp.com și https://app1.external.mycoolapp.com ) și DNS-ul intern nu este rezolvat din lumea exterioară (= internetul), în timp ce cel extern este (ca de la Google dns).

Asta pentru configurare. Acum, hai să ajungem la problemă:

Cu câteva zile în urmă, m-am gândit: Ce se întâmplă dacă creez o intrare DNS wildcard pentru * intern.mycoolapp.com pe o mașină, adică în afara rețelei mele, și o rezolv același IP (e) intrarea externă DNS se rezolvă la. Et voila, serviciile mele interne sunt accesibile din exterior!

Deci, acesta este, desigur, un stat care nu este acceptabil. Aș căuta soluții în acest sens.

Ceea ce a venit în minte a fost să blocheze toate cererile de intrare privind regulile pentru serviciile interne, dacă ip-ul gazdă al solicitantului este în afara rețelei noastre:

...
kind: Ingress
metadata:
  name: app1
  namespace: default
  annotations:
    traefik.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/8"
    ingress.kubernetes.io/whitelist-x-forwarded-for: "true"
...

Teoretic, acest lucru ar trebui să funcționeze. Dar, după cum am aflat mai tîrziu, înainte de a ajunge la controlerul traefik-ingress , toate cererile sunt gestionate de kube-proxy iar adresele lor gazdă sunt traduse la adrese locale (< em> (S) NAT ), deci fiecare cerere are un set intern de adrese gazdă.

Deci, acesta este punctul pe care îl caut în prezent o soluție.

O soluție este de a implementa traefic-ingress-controller nu ca o implementare, ci ca set de daemon și să o legați direct pe porturile de pe gazdă (așa cum sa spus aici

2

Răspunsuri nu sunt

0