In vielen Fällen ist es für Anwendungen hilfreich, die Source-IP einer Anfrage zu kennen. Mit dieser Information kann deine Anwendung viele nützliche Dinge anstellen, z.B. anhand von GeoIP-Daten die für den Besucher passende Sprache auf einer Website ausspielen.
Nun ist es in der Cloud und besonders in Kubernetes leider nicht so, dass die Anfrage eines Nutzers ohne Umwege bei deiner Anwendung ankommen: Loadbalancer, Ingress-Controller oder Gateways leiten die Anfrage oft mehrmals weiter, bevor das eigentliche Ziel sie zu Gesicht bekommt. Um bei dieser Odyssee den eigentlichen Ursprung einer Anfrage nicht aus den Augen zu verlieren, gibt es zwei nützliche Hilfsmittel: Den HTTP-Header X-Forwarded-For (xff), und das Proxy-Protocol.
In der Vergangenheit haben wir bereits ein Tutorial erstellt, in dem wir die Einrichtung dieser Hilfsmittel für Ingress-Controller in Kubernetes besprechen. Da die Gateway API in Kubernetes mehr und mehr an Popularität gewinnt, schauen wir uns heute am Beispiel von kgateway an, wie du dieselben Einstellungen für Gateway APIs vornehmen kannst.
Du findest die in diesem Tutorial besprochenen Ressourcen inkl. Setup-Anleitung auf GitHub
Voraussetzungen
Voraussetzungen für dieses Tutorial sind ein Kubernetes-Cluster, Helm und kubectl. Die in diesem Tutorial gezeigten Ressourcen findest du auf GitHub.
Ein Kubernetes-Cluster kannst du entweder in MyNWS erstellen, oder ein bestehendes Cluster mit Loadbalancer-Support dafür nutzen.
Außerdem solltest du dir deine aktuelle IPv4-Adresse notieren, um die Funktionalität der verschiedenen Konfigurationen später testen zu können. Diese kannst du z.B. mit cURL und icanhazip.com einfach herausfinden:
curl ipv4.icanhazip.comDie Ausgangslage
Betrachtet man ein produktives Kubernetes-Cluster, so bietet dieses in Sachen Netzwerk oft die folgenden Möglichkeiten:
- automatische Provisionierung von externen Loadbalancern (durch Cloudprovider oder Projekte wie MetalLB oder Cilium)
- Routing von Netzwerkverkehr innerhalb des Clusters (durch CNIs, Ingress-Controller oder Gateway-Controller)
In der Praxis bedeutet das oftmals, dass externe Anfragen nach frühestens zwei „Hops“ die eigentliche Anwendung erreichen. In NETWAYS Managed Kubernetes®, das auf OpenStack aufbaut, kannst du dir das in etwa so vorstellen:
Bei diesen Weiterleitungen durch Loadbalancer und/oder Proxies im Cluster geht die ursprüngliche IP-Adresse der Anfrage verloren – sie wird durch die IPs des Loadbalancers oder des Proxies ersetzt. Möchtest du das vermeiden, kannst du je nach Art der eingehenden Anfragen X-Forwarded-For (xff) HTTP-Header oder das Proxy-Protocol konfigurieren.
Doch richten wir zunächst einmal die Umgebung für dieses Tutorial an und überprüfen unsere Ausgangslage.
Schritt 1: Setup und Standardverhalten von kgateway
Hast du ein Cluster erstellt, müssen zuerst die CustomResourceDefinitions (CRDs) der Gateway API und ein Gateway-Controller installiert werden. In diesem Tutorial nutzen wir als Gateway-Controller das CNCF-Projekt kgateway, das als Proxy wiederum auf Envoy setzt:
# Installation der Gateway API CRDs
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml
# Installation von kgateway CRDs und Controller
helm upgrade -i --create-namespace \
--namespace kgateway-system \
--version v2.2.1 kgateway-crds oci://cr.kgateway.dev/kgateway-dev/charts/kgateway-crds
helm upgrade -i -n kgateway-system kgateway oci://cr.kgateway.dev/kgateway-dev/charts/kgateway \
--version v2.2.1
Durch die Installation von kgateway mit Helm werden (zusätzlich zu CRDs) folgende Ressourcen im Cluster angelegt:
- ein Deployment
kgateway, das die von uns definierten Gateways managt und konfiguriert - eine GatewayClass
kgateway, die die Standardkonfiguration des Projekts für Gateways definiert
Für die folgenden Szenarien und die Überprüfung des Standardverhaltens von kgateway starten wir als nächstes eine kleine Anwendung namens http-https-echo im Namespace default unseres Clusters und machen sie über einen Service erreichbar:
kubectl run gw-test --image mendhak/http-https-echo
kubectl expose pod gw-test --port 80 --target-port 8080Diesen Service können wir nun über die Gateway API für externe Nutzer verfügbar machen. Hierzu benötigen wir ein Gateway, das die bestehende GatewayClass kgateway referenziert und einem Listener definiert, der nach HTTP-Anfragen auf Port 80 lauscht. Zusätzlich definieren wir eine HTTPRoute, die sämtliche von diesem Gateway empfangenen Anfragen an unseren Service weiterleitet.
Im GitHub-Repository zu diesem Tutorial findest du die entsprechenden Dateien unter default/{gateway,httproute}.yaml:
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
name: default-gateway
namespace: kgateway-system
spec:
gatewayClassName: kgateway
listeners:
- protocol: HTTP
port: 80
name: http
allowedRoutes:
namespaces:
from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: default-test-route
namespace: default
labels:
example: default-test
spec:
parentRefs:
- name: default-gateway
namespace: kgateway-system
rules:
- backendRefs:
- name: gw-test
port: 80Hast du diese CRDs in deinem Cluster erstellt (z.B. via kubectl apply), liest das kgateway Deployment sie ein und erstellt weitere Ressourcen:
- ein Deployment
default-gateway, das als Proxy für das erstellte Gateway fungiert - einen Service
kgatewayvom Typ LoadBalancer, der als Eingangspunkt für externe Anfragen an das erstellte Gateway fungiert
Die erstellten Ressourcen kannst du dir auch im Cluster anschauen:
kubectl get -n kgateway-system gateway,httproute,deployment,service,pod
NAME CLASS ADDRESS PROGRAMMED AGE
gateway.gateway.networking.k8s.io/default-gateway kgateway 91.198.2.73 True 6m12s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/default-gateway 1/1 1 1 6m12s
deployment.apps/kgateway 1/1 1 1 19m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/default-gateway LoadBalancer 10.8.173.70 91.198.2.73 80:31743/TCP 6m12s
service/kgateway ClusterIP 10.8.5.167 <none> 9977/TCP 19m
NAME READY STATUS RESTARTS AGE
pod/default-gateway-69d6477cfb-s8vlt 1/1 Running 0 6m12s
pod/kgateway-85f7f66854-x9l88 1/1 Running 0 19mDie Adresse des Gateways sollte der externen IP des zugehörigen Services entsprechen. Diesen kannst du mit cURL erreichen. Das Gateway sollte die Anfrage anhand der HTTPRoute-Konfiguration an unsere Testanwendung weiterleiten:
curl http://91.198.2.73
{
"path": "/",
"headers": {
"host": "91.198.2.73",
"user-agent": "curl/8.7.1",
"accept": "*/*",
"x-forwarded-for": "10.7.1.11",
"x-forwarded-proto": "http",
"x-envoy-external-address": "10.7.1.11",
"x-request-id": "65c828ab-7524-400e-a39a-616206d006fc",
"x-envoy-expected-rq-timeout-ms": "15000"
},
"method": "GET",
"body": "",
"fresh": false,
"hostname": "91.198.2.73",
"ip": "10.7.1.11",
"ips": [
"10.7.1.11"
],
"protocol": "http",
"query": {},
"subdomains": [],
"xhr": false,
"os": {
"hostname": "gw-test"
},
"connection": {}
}Der genaue Output in deiner Umgebung wird natürlich etwas anders aussehen. Für uns sind vor Allem die Einträge x-forwarded-for, x-forwarded-proto und ip interessant. kgateway bzw. Envoy scheint auch ohne explizite Konfiguration xff-Header zu setzen. Die im Header gesetzte Ursprungsadresse ist dann tatsächlich auch die, die unsere Testanwendung in ip angibt.
Da wir xff allerdings nicht für unsere gesamte Infrastruktur konfiguriert haben, entspricht die angegebene Adresse nicht unserer tatsächlichen – je nach Cluster-Konfiguration kann es sich hierbei um eine Node-, Pod-, Loadbalancer- oder CiliumNode-Adresse handeln.
Konfigurieren wir als nächstes also xff korrekt.
Schritt 2: Einrichten von X-Forwarded-For (xff)
In Schritt 1 haben wir gesehen, dass kgateway bzw. Envoy xff-Header von Haus aus setzen – eine Konfiguration auf Gateway-Ebene ist hierfür also anders als bei vielen Ingress-Controllern nicht mehr nötig. Damit unsere tatsächliche Ursprungsadresse ordentlich propagiert werden kann, müssen wir also am ersten Berührungspunkt unserer Anfrage mit unserer Kubernetes-Infrastruktur ansetzen: Dem Loadbalancer, der für jedes Gateway außerhalb unseres Clusters erstellt wird.
Im Falle von NETWAYS Managed Kubernetes® werden diese Loadbalancer von OpenStack erstellt und lassen sich mit einer Annotation in Kubernetes entsprechend konfigurieren: loadbalancer.openstack.org/x-forwarded-for: "true".
In vielen anderen Public Clouds unterstützten Loadbalancer xff entweder standardmäßig, oder lassen sich auf ähnliche Art konfigurieren.
Da der Loadbalancer bei Erstellung eines neuen Gateways automatisch durch dessen Service erstellt wird, müssen wir die entsprechende Annotation über die Konfiguration der GatewayClass angeben, die als Vorlage für unsere Gateways dient. kgateway stellt hierfür eine CustomResourceDefinition (CRD) GatewayParameters bereit.
Für dieses Szenario erstellen wir also:
- eine neue GatewayClass
xff-gateway - GatewayParameter
xff-gwpmit der Loadbalancer-Annotation - ein neues Gateway
xff-gateway - eine neue HTTPRoute
xff-test-route, die wieder auf unsere Testanwendung verweist.
Im GitHub-Repository zu diesem Tutorial findest du die entsprechenden Dateien unter xff/{gatewayclass,gwp,gateway,httproute}.yaml:
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: xff-gateway
spec:
controllerName: kgateway.dev/kgateway
parametersRef:
group: gateway.kgateway.dev
kind: GatewayParameters
name: xff-gwp
namespace: kgateway-system
---
apiVersion: gateway.kgateway.dev/v1alpha1
kind: GatewayParameters
metadata:
name: xff-gwp
namespace: kgateway-system
spec:
kube:
service:
extraAnnotations:
loadbalancer.openstack.org/x-forwarded-for: "true"
---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
name: xff-gateway
namespace: kgateway-system
spec:
gatewayClassName: xff-gateway
listeners:
- protocol: HTTP
port: 80
name: http
allowedRoutes:
namespaces:
from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: xff-test-route
namespace: default
labels:
example: xff-test
spec:
parentRefs:
- name: xff-gateway
namespace: kgateway-system
rules:
- backendRefs:
- name: gw-test
port: 80Wie im ersten Szenario dieses Tutorials werden durch diese CRDs wieder ein Gateway, LoadBalancer-Service und ein Deployment angelegt, um das Routing für unser neues Szenario zu übernehmen.
kubectl get -n kgateway-system gateway,httproute,deployment,service,pod
gateway.gateway.networking.k8s.io/default-gateway kgateway 91.198.2.73 True 22h
gateway.gateway.networking.k8s.io/xff-gateway xff-gateway 185.233.190.168 True 80s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/default-gateway 1/1 1 1 22h
deployment.apps/kgateway 1/1 1 1 22h
deployment.apps/xff-gateway 1/1 1 1 79s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/default-gateway LoadBalancer 10.8.173.70 91.198.2.73 80:31743/TCP 22h
service/kgateway ClusterIP 10.8.5.167 <none> 9977/TCP 22h
service/xff-gateway LoadBalancer 10.8.82.151 185.233.190.168 80:31548/TCP 79s
NAME READY STATUS RESTARTS AGE
pod/default-gateway-69d6477cfb-s8vlt 1/1 Running 0 22h
pod/kgateway-85f7f66854-x9l88 1/1 Running 0 22h
pod/xff-gateway-577b588c58-pbzvb 1/1 Running 0 79sDie Adresse des neu erstellten Gateways xff-gateway können wir im Anschluss erneut mit cURL adressieren, um unsere Testanwendung zu erreichen:
curl http://185.233.190.168
{
"path": "/",
"headers": {
"host": "185.233.190.168",
"user-agent": "curl/8.7.1",
"accept": "*/*",
"x-forwarded-for": "185.17.205.20,10.7.3.143",
"x-forwarded-proto": "http",
"x-envoy-external-address": "10.7.3.143",
"x-request-id": "a5255576-ec09-4f2b-bd7a-4b583eddf228",
"x-envoy-expected-rq-timeout-ms": "15000"
},
"method": "GET",
"body": "",
"fresh": false,
"hostname": "185.233.190.168",
"ip": "185.17.205.20",
"ips": [
"185.17.205.20",
"10.7.3.143"
],
"protocol": "http",
"query": {},
"subdomains": [],
"xhr": false,
"os": {
"hostname": "gw-test"
},
"connection": {}
}Die Einträge für x-forwarded-for sollten dieses Mal aus zwei Adressen bestehen: der Client-Adresse (die erste Adresse innerhalb der Auflistung), und Proxy-Adressen (alle weiteren Adressen), die zwischen dem Client und der Anwendung eingerichtet sind.
Die selben Adressen finden sich im Feld ips wieder; unter ip wird dieses Mal (hoffentlich) deine tatsächliche IP-Adresse angezeigt.
xff funktioniert jetzt durch unsere gesamte Kubernetes-Infrastruktur hindurch. Allerdings haben wir bisher nur mit HTTP getestet – wie würde es sich mit TLS-Anfragen verhalten?
Schritt 3: Einrichten des Proxy-Protocols
X-Forwarded-For funktioniert problemlos, wenn alle Komponenten auf dem Weg unserer Anfrage die entsprechenden HTTP-Header bearbeiten können. Doch wie verhält es sich, wenn ein Loadbalancer eine TLS-verschlüsselte Anfrage lediglich in unser Cluster weiterleitet, oder Anfragen nicht auf Layer 7 (HTTP/S), sondern auf Layer 4 (TCP) behandelt werden?
Für solche Anwendungsfälle gibt es das Proxy-Protocol. Mit diesem Protokoll können Proxies und Loadbalancer vor dem eigentlichen TCP-Stream einen sogenannten Header mit der Ursprungsadresse und evtl. Proxyadressen übermitteln, den der nächste Proxy oder die Anwendung dann interpretieren kann. Hierfür ist eine Konfiguration auf beiden Seiten der Verbindung notwendig, in unserem Fall für LoadBalancer und kgateway:
- der Loadbalancer muss wissen, dass er die Ursprungsadresse im Proxy-Protocol übermitteln soll
- kgateway muss wissen, dass es einen Header des Proxy-Protocols zu erwarten hat
Auf Seiten des Loadbalancers erfolgt diese Konfiguration in NETWAYS Managed Kubernetes® wieder über eine OpenStack-Annotation: loadbalancer.openstack.org/proxy-protocol: "true". In der Gateway API wird die entsprechende Konfiguration für einen oder mehrere Listener eines Gateways vorgenommen. kgateway stellt zu diesem Zweck die CustomResourceDefinition (CRD) ListenerPolicy bereit.
Die für dieses Szenario benötigten Ressourcen in unserem Kubernetes-Cluster sind:
- eine neue GatewayClass
proxy-gateway - GatewayParameter
proxy-gwpmit der Loadbalancer-Annotation - eine ListenerPolicy, die das Proxy-Protocol für den Listener des neuen Gateways konfiguriert
- ein neues Gateway
proxy-gateway - eine neue HTTPRoute
proxy-test-route, die wieder auf unsere Testanwendung verweist.
Im GitHub-Repository zu diesem Tutorial findest du die entsprechenden Dateien unter proxy/{gatewayclass,gwp,listenerpolicy,gateway,httproute}.yaml:
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: proxy-gateway
spec:
controllerName: kgateway.dev/kgateway
parametersRef:
group: gateway.kgateway.dev
kind: GatewayParameters
name: proxy-gwp
namespace: kgateway-system
---
apiVersion: gateway.kgateway.dev/v1alpha1
kind: GatewayParameters
metadata:
name: proxy-gwp
namespace: kgateway-system
spec:
kube:
service:
extraAnnotations:
loadbalancer.openstack.org/proxy-protocol: "true"
---
apiVersion: gateway.kgateway.dev/v1alpha1
kind: ListenerPolicy
metadata:
name: proxy-protocol
namespace: kgateway-system
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: proxy-gateway
default:
proxyProtocol: {}
---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
name: proxy-gateway
namespace: kgateway-system
spec:
gatewayClassName: proxy-gateway
listeners:
- protocol: HTTP
port: 80
name: http
allowedRoutes:
namespaces:
from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: proxy-test-route
namespace: default
labels:
example: proxy-test
spec:
parentRefs:
- name: proxy-gateway
namespace: kgateway-system
rules:
- backendRefs:
- name: gw-test
port: 80Ansonsten ändert sich im Vergleich zu den vorherigen Szenarien nicht viel: Sind die Ressourcen im Cluster erstellt, kümmert sich kgateway um die Bereitstellung eines neuen Gateways inklusive Loadbalancer und die Einrichtung des Routings. Für einen abschließenden Test benötigen wir lediglich die IP-Adresse, unter der das neue Gateway erreichbar ist:
kubectl get -n kgateway-system gateway proxy-gateway
NAME CLASS ADDRESS PROGRAMMED AGE
proxy-gateway proxy-gateway 185.233.191.176 True 5m45sEin weiterer cURL-Aufruf verrät uns, ob die Konfiguration für Proxy-Protocol funktioniert:
curl http://185.233.191.176
{
"path": "/",
"headers": {
"host": "185.233.191.176",
"user-agent": "curl/8.7.1",
"accept": "*/*",
"x-forwarded-for": "185.17.205.20",
"x-forwarded-proto": "http",
"x-envoy-external-address": "185.17.205.20",
"x-request-id": "5cbf270e-b907-4645-85ae-980f57755adb",
"x-envoy-expected-rq-timeout-ms": "15000"
},
"method": "GET",
"body": "",
"fresh": false,
"hostname": "185.233.191.176",
"ip": "185.17.205.20",
"ips": [
"185.17.205.20"
],
"protocol": "http",
"query": {},
"subdomains": [],
"xhr": false,
"os": {
"hostname": "gw-test"
},
"connection": {}
}Auch in diesem Szenario erkennt unsere Testanwendung unsere korrekte Ursprungsadresse. Auffällig ist, dass trotz Proxy-Protocol x-forwarded-for Header (xff) von kgateway bzw. Envoy gesetzt wurden. Das liegt daran, dass wir für unseren Test der Einfachheit halber HTTP und nicht „reines“ TCP genutzt haben.
In diesem Fall übernimmt Envoy die Informationen aus dem Proxy-Protocol und propagiert sie über xff an die Zielanwendungen. Ähnlich würde es sich verhalten, wenn wir TLS-verschlüsselten Netzwerkverkehr an unserem Gateway terminieren würden, ein gängiges Szenario in Kubernetes.
Grenzen von xff und Proxy-Protocol
Die beiden vorgestellten Ansätze decken die gängigsten Szenarien in Kubernetes-Clustern ab. Es gibt jedoch Situationen, in denen sie nicht ausreichen oder schlicht nicht anwendbar sind.
xff und Header-Spoofings
Ein oft übersehenes Sicherheitsproblem bei X-Forwarded-For ist, dass Clients den Header selbst setzen können. Sendet ein Client eine Anfrage mit einem vorausgefüllten x-forwarded-for-Header, übernimmt Envoy diesen Wert ohne weiteres in die Header-Kette – eine Anwendung, die dem ersten Eintrag im xff-Header blind vertraut, kann so über die tatsächliche Ursprungsadresse getäuscht werden.
Envoy bietet hierfür den Konfigurationsparameter xff_num_trusted_hops, mit dem angegeben wird, wie viele Proxies zwischen dem Client und Envoy als vertrauenswürdig einzustufen sind. Envoy zählt dann vom Ende der xff-Liste rückwärts und ermittelt so die tatsächliche Client-Adresse.
In kgateway lässt sich dieser Parameter über eine ListenerPolicy setzen:
apiVersion: gateway.kgateway.dev/v1alpha1
kind: ListenerPolicy
metadata:
name: xff-trusted-hops
namespace: kgateway-system
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: xff-gateway
default:
httpSettings:
xffNumTrustedHops: 1Passthrough-TLS: Wenn das Gateway nicht terminieren darf
Ein häufiges Szenario in sicherheitssensiblen Umgebungen ist TLS Passthrough: Das Gateway leitet TLS-verschlüsselten Traffic direkt an die Zielanwendung durch, ohne ihn zu terminieren. Das ist zum Beispiel dann der Fall, wenn eine Anwendung mTLS (mutual TLS) auf Anwendungsebene einsetzt und das Client-Zertifikat nicht am Gateway terminiert werden soll oder Service-Mesh-Lösungen im Cluster zum Einsatz kommen.
In diesem Fall kann kgateway als HTTP-Proxy die xff-Header weder lesen noch setzen. Der Traffic ist für den Proxy ein verschlüsselter TCP-Stream. Hier kommt das Proxy-Protocol wieder ins Spiel: Da es auf Layer 4 arbeitet und dem eigentlichen TCP-Stream vorangestellt wird, funktioniert es unabhängig von TLS-Verschlüsselung.
In der Gateway API wird ein TLS-Passthrough-Listener mit protocol: TLS und tls.mode: Passthrough konfiguriert:
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
name: passthrough-gateway
namespace: kgateway-system
spec:
gatewayClassName: proxy-gateway
listeners:
- protocol: TLS
port: 443
name: tls-passthrough
tls:
mode: Passthrough
allowedRoutes:
namespaces:
from: All
Der entscheidende Punkt ist dann, dass die Zielanwendung selbst das Proxy-Protocol interpretieren muss: Das Gateway reicht den Header durch, kann ihn aber nicht in xff umwandeln. Nicht jeder Anwendungsstack unterstützt das out-of-the-box; es ist also vorab zu prüfen, ob der verwendete TLS-Stack Proxy-Protocol-Support mitbringt.
Wenn auch Proxy-Protocol nicht hilft: Service Meshes und mTLS
Wird auf mTLS zwischen einzelnen Services gesetzt, beispielsweise durch einen Service Mesh wie Istio oder Cilium, ist die Quelladresse bereits dem Mesh selbst bekannt. In diesem Fall übernimmt der Mesh die Identitätsprüfung über X.509-Zertifikate (SPIFFE/SPIRE), und die Ursprungsadresse einer Anfrage ist anhand der Zertifikatsidentität des aufrufenden Services feststellbar.
Für solche Umgebungen ist xff oder Proxy-Protocol nur noch am äußersten Rand des Clusters relevant, also für den ersten Eintrittspunkt von externen Anfragen. Innerhalb des Meshes wird die Client-Identität typischerweise über andere Mechanismen propagiert und durchgesetzt.
Fazit
X-Forwarded-For (xff) und Proxy-Protocol sind zwei bewährte und sich ergänzende Werkzeuge, um die ursprüngliche Client-Adresse durch eine mehrstufige Proxy-Kette in Kubernetes hindurch zu propagieren. Die Gateway API und ihre Implementierungen, z.B. kgateway, biete flexible Stellschrauben, um beide Verfahren sauber zu konfigurieren. Welches Verfahren das richtige ist, hängt vom konkreten Anwendungsfall ab.
Die Kombination aus korrekt konfiguriertem xff und einer angemessenen xffNumTrustedHops-Einstellung ist dabei in den meisten Fällen ausreichend – und schützt gleichzeitig vor trivialem Header-Spoofing durch böswillige Clients.
0 Kommentare