Kubernetes and Shibboleth - Client IP Changing - Session Persistence not working

Mon Apr 1 09:22:03 EDT 2019

Ok I think I got it.

I’ve added this to my Tomcat Server.xml

        <Valve className="org.apache.catalina.valves.RemoteIpValve"
               remoteIpHeader="x-forwarded-for"
               trustedProxies="130\.211\.\d{1,3}\.\d{1,3}|35\.191\.\d{1,3}\.\d{1,3}"
               protocolHeaderHttpsValue="https" />

Those are the Google Load Balancers.

https://cloud.google.com/load-balancing/docs/https/#firewall_rules <https://cloud.google.com/load-balancing/docs/https/#firewall_rules>

"You must create a firewall rule that allows traffic from 130.211.0.0/22 and 35.191.0.0/16 to reach your instances. These are IP address ranges that the load balancer uses to connect to backend instances"

Of course, I have to do more testing, but as of right now, I think it’s working.

Mel

Melvin Lasky
Associate Director of Enterprise Architecture

Riverdale, NY 10471
Phone: 718-862-7410
melvin.lasky at manhattan.edu <mailto:melvin.lasky at manhattan.edu>
www.manhattan.edu <http://www.manhattan.edu/>

> On Mar 26, 2019, at 9:20 PM, Melvin Lasky <melvin.lasky at manhattan.edu> wrote:
> 
> Hey Jacob,
> 	I’m using a Ingress load balancer instead of type: loadbalancer, so when I tried to add that externalTrafficPolicy it threw an error:
> 
> meltbMBP:shib-auth-prod melman101$ kubectl apply -f  shib-auth-prod-ingress.yaml 
> service/shibauthweb-backend created
> error: error validating "shib-auth-prod-ingress.yaml": error validating data: ValidationError(Ingress.spec): unknown field "externalTrafficPolicy" in io.k8s.api.extensions.v1beta1.IngressSpec; if you choose to ignore these errors, turn validation off with --validate=false
> 
> ——
> 
> Hey Les,
> 	I set it to Client IP in the Session Affinity. However, didn’t seem to work… Still got the dreaded:
> 
> shib-idp;idp-process.log;dev;nothing;2019-03-27 01:20:02,877 - WARN [net.shibboleth.idp.session.AbstractIdPSession:374] - Client address is 10.100.8.135 but session fdfdf782f30382fa94db9927e745292eb15c039c816f312bebc484d5707181aa already bound to 10.12.1.1
> shib-idp;idp-warn.log;dev;nothing;2019-03-27 01:20:02,877 - WARN [net.shibboleth.idp.session.AbstractIdPSession:374] - Client address is 10.100.8.135 but session fdfdf782f30382fa94db9927e745292eb15c039c816f312bebc484d5707181aa already bound to 10.12.1.1
> shib-idp;idp-process.log;dev;nothing;2019-03-27 01:20:02,884 - WARN [net.shibboleth.idp.session.AbstractIdPSession:374] - Client address is 10.100.8.135 but session fdfdf782f30382fa94db9927e745292eb15c039c816f312bebc484d5707181aa already bound to 10.12.1.1
> shib-idp;idp-warn.log;dev;nothing;2019-03-27 01:20:02,884 - WARN [net.shibboleth.idp.session.AbstractIdPSession:374] - Client address is 10.100.8.135 but session fdfdf782f30382fa94db9927e745292eb15c039c816f312bebc484d5707181aa already bound to 10.12.1.1
> 
> 
> Thanks for any help!
> 
> Mel
> 
> Melvin Lasky
> Associate Director of Enterprise Architecture
> 
> <email_logo.jpg>
> 
> 
> 
> Riverdale, NY 10471
> Phone: 718-862-7410
> melvin.lasky at manhattan.edu <mailto:melvin.lasky at manhattan.edu>
> www.manhattan.edu <http://www.manhattan.edu/>
> 
> 
> 
> 
>> On Mar 26, 2019, at 7:54 PM, Melvin Lasky <melvin.lasky at manhattan.edu <mailto:melvin.lasky at manhattan.edu>> wrote:
>> 
>> Hey everyone,
>> 	We are very close to launching our SHIBBOLETH authentication on Google Kubernetes Engine. We are having a slight problem. Our session persistence is not working as it should.
>> 
>> You can go to a few services, and then try again, and eventually the login page will come up and you’ll have to login again. This happens in < 1 minute generally of just bouncing around. I set my time-outs to 8 hours, and a 2hour idle…
>> 
>> That didn’t fix it. I noticed this in the logs:
>> 
>> shib-idp;idp-process.log;dev;nothing;2019-03-26 23:48:59,282 - WARN [net.shibboleth.idp.session.AbstractIdPSession:374] - Client address is 10.100.x.x but session fdfdf782f30382fa94db9927e745292eb15c039c816f312bebc484d5707181aa already bound to 10.12.1.1
>> shib-idp;idp-warn.log;dev;nothing;2019-03-26 23:48:59,282 - WARN [net.shibboleth.idp.session.AbstractIdPSession:374] - Client address is 10.100.x.x but session fdfdf782f30382fa94db9927e745292eb15c039c816f312bebc484d5707181aa already bound to 10.12.1.1
>> shib-idp;idp-process.log;dev;nothing;2019-03-26 23:48:59,291 - WARN [net.shibboleth.idp.session.AbstractIdPSession:374] - Client address is 10.100.x.x but session fdfdf782f30382fa94db9927e745292eb15c039c816f312bebc484d5707181aa already bound to 10.12.1.1
>> shib-idp;idp-warn.log;dev;nothing;2019-03-26 23:48:59,291 - WARN [net.shibboleth.idp.session.AbstractIdPSession:374] - Client address is 10.100.x.x but session fdfdf782f30382fa94db9927e745292eb15c039c816f312bebc484d5707181aa already bound to 10.12.1.1
>> 
>> Now as mentioned, we are using Google Kubernetes Engine. The 10.100.x.x is an internal google IP for the compute engine that’s running the cluster.
>> 
>> The 10.12.1.1 address must be coming from the pod, but the pod’s IP is 10.12.1.x (with x being a higher number than 1)
>> 
>> Anyhow, does anyone have any suggestions on how we can resolve this issue? 
>> 
>> Thanks for all your help!
>>   
>> Melvin Lasky
>> Associate Director of Enterprise Architecture
>> 
>> <email_logo.jpg>
>> 
>> 
>> 
>> Riverdale, NY 10471
>> Phone: 718-862-7410
>> melvin.lasky at manhattan.edu <mailto:melvin.lasky at manhattan.edu>
>> www.manhattan.edu <http://www.manhattan.edu/>
>> 
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190401/8c496104/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email_logo.jpg
Type: image/jpeg
Size: 7478 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20190401/8c496104/attachment.jpg>