2

we recently migrated our Spring Boot (2.2 & 2.4) services to a new Kubernetes cluster (EKS). We have Traefik running as a reverse proxy with a public facing load balancer attached to it.

Since our migration the Spring services don't accept the X-Forwarded headers anymore. We triple checked the headers which are received by those services coming from the reverse proxy but spring just seems to ignore them and marking the HTTPServletRequest as insecure which basically breaks our system.

The following headers are sent from the proxy (User Agent and Sec-Fetch headers stripped) and received by our spring services.

Header: host=test.example.intern
Header: authorization=Bearer xxx
Header: referer=https://test.example.intern/profile
Header: x-forwarded-for=172.32.11.128
Header: x-forwarded-host=test.example.intern
Header: x-forwarded-port=443
Header: x-forwarded-proto=https
Header: x-forwarded-server=traefik-84794d75b9-p2q7z
Header: x-real-ip=172.32.11.128

Another "funny" thing is that if we swap the services using tools like telepresence and run the service locally it works even if the headers are the same. Same if we simulate the reverse proxies call, setting the X-Forwarded headers identical to those coming from the proxy it works.

We compared the config and sent headers from the same services running on our other k8s clusters on Google Cloud and Azure which are identical (besides the source ip's obv.).

The IP ranges of the cluster service and pod CIDRs are also set in the server.tomcat.remoteip.internal-proxies setting. Another thing we tried without success is setting the server.forward-headers-strategy to NATIVE.

Does anyone know what we possibly overlooked or could point us in the right direction here?

Thanks in advance, Rob

Robert Keck
  • 167
  • 2
  • 14
  • Maybe the [`server.forward-headers-strategy`](https://stackoverflow.com/questions/68318269/spring-server-forward-headers-strategy-native-vs-framework) config? – Morfic Nov 24 '21 at 14:40
  • We tried that too, but didn't work. On our other systems this option isn't set as well so I think it internally defaults to NATIVE. – Robert Keck Nov 24 '21 at 14:42
  • 1
    Just to make sure, you also checked (eg in logs) what headers you are receiving in your app? – Morfic Nov 24 '21 at 14:52
  • Yes, we have. See in the output above. Those are logged from our services. – Robert Keck Nov 24 '21 at 14:55
  • Did you ever resolve this? I'm struggling with something eerily similar on Spring Boot 2.7.x within k8s. Spring Boot 2.6.x was working fine. – jdolan Mar 10 '23 at 13:56
  • @jdolan yes we did, but it was just some stupid, embarassing mistake on our side with the private ip address ranges. We "thought" (aka never checked) that the 172.32.0.0/16 subnet was still in the private class b space (which of course isn't ...). So all our efforts of whitelisting the private class b range (which spring does per default) obv. didn't work. – Robert Keck Mar 27 '23 at 12:16

0 Answers0