Kubernetes deployment of version 1.16.0-RC.1

laurent.michel

Hi,

I'm a new user of fusionauth with absolutely no XP with that piece of software.

On the one hand, I have a kubernetes cluster where I have installed fusionauth. I've written my own helm chart as there are currently no official chart supporting installation of version 1.16.0-RC.1 (as far as I know). Fusionauth works fine on that cluster: I can access the dashboard and then do my stuff.

I was, on the other hand, also able to install fusionauth on a dedicated server separate from my kubernetes cluster. It also works fine, I can do the same stuff as with the instance installed in the k8s cluster.

Yet I have a problem. The only way I can log into the admin console on my k8s cluster is with Microsoft Edge or Microsoft Internet Explorer. It works for some time with Chrome, Safari, and Firefox, but after a few logins / logouts, it doesn't work anymore. I get indeed a 403 access denied. With Edge and Explorer, it works all the time.

On my separate server, it works with all browsers all the time.

In front of my k8s cluster and my separate server, I've put both times an nginx load balancer, on which I installed the let's encrypt certificates and configured SSL the same way (same nginx.conf, same ssl.conf).

So, the only difference between the two environments is probably the additional nginx ingress controller on my k8s cluster. What can I do to further investigate that problem and find out its root cause? Does anyone have XP on k8s deployments of fusionauth? I'm running out of ideas ...

dan

@laurent-michel I'm unfamiliar with kubernetes, but are you using session affinity? https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/

dan

Also, what in particular doesn't work with the current charts? What doesn’t support 1.16.0-rc.1?

laurent.michel

@dan said in Kubernetes deployment of version 1.16.0-RC.1:

Also, what in particular doesn't work with the current charts? What doesn’t support 1.16.0-rc.1?

Exactly this. I am using version 1.16.0-RC.1 because I don't want elasticsearch. Currently, the official charts do not allow to install it without elasticsearch.

dan

Ah, makes sense about needing a new chart to avoid elastic search.

Can you let me know about session affinity? This issue looks like it might be helpful: https://github.com/FusionAuth/charts/issues/19 as does this Stack Overflow question: https://stackoverflow.com/questions/59272484/sticky-sessions-on-kubernetes-cluster

dan

Here's a PR from the maintainer of the FusionAuth helm charts allowing you to avoid using ES: https://github.com/FusionAuth/charts/pull/20

More comments from Taylor:

"other than the elasticsearch thing, this doesn't sound like a chart issue though. from the information provided it seems that they are only configuring a single fusionauth server, so they shouldn't need to much with sessionAffinity or anything like that. indeed, without affinity, i would expect them to need to log in constantly, not get a hard 403. odd that it works in edge or IE only as well. especially since new versions of edge are chromium"

dan

If this is still happening, can you file a bug on https://github.com/FusionAuth/fusionauth-containers with as many details as possible?

laurent.michel

@dan Yes, I will file a bug there if it is still happening. Thanks for your help.

laurent.michel

Interestingly, I installed version 1.16.0 today on its dedicated server, i.e. not on kubernetes, and there I have the very same problem as on kubernetes now: no way to connect with any browser than edge or explorer. Therefore, I think I was wrong, it's not a problem with my kubernetes settings. It seems to be an issue with either the fusionauth settings or the nginx load balancer. And with edge / explorer, even if I can login / logout as I wish, I cannot do anything with the software. I can't e.g. add an application, I get an Unauthorized access, even though I'm logged in with the admin account.

robotdan

If you get an unauthorized message in the UI when you submit a form it is due to your network configuration. This error is caused by our protective measures for cross site request forgery.

I would assume you are seeing an error on the admin page to indicate your proxy configuration is invalid. If not, ensure you have the correct X-Forwarded-Port, X-Forwarded-Host, X-Forwarded-Proto headers set when behind a proxy.

If these values are not set, or are invalid then when we compare the Origin header against the request we will fail our CSRF assertions and return a 401.