Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unsuccessfull login with keycloak oidc over k8s dashboard #5114

Closed
samsja opened this issue May 10, 2020 · 2 comments · Fixed by #5124
Closed

Unsuccessfull login with keycloak oidc over k8s dashboard #5114

samsja opened this issue May 10, 2020 · 2 comments · Fixed by #5124
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@samsja
Copy link

samsja commented May 10, 2020

Environment
Installation method: via helm with this chart https://github.com/funkypenguin/helm-kubernetes-dashboard
Kubernetes version: v1.14.10-gke.27
Dashboard version: 2.0.0

Steps to reproduce

helm install --namespace monitoring k8s-dashboard funkypenguin-kubernetes-dashboard/kubernetes-dashboard -f k8s/monitoring/staging/k8s-dashboard/values.yaml

protocolHttp: True
extraArgs:
--enable-insecure-login

I got a Https redirection that is why protocol http is allowed.

Then I add a open id connect gateway : keycloak , via a kong ingress plugin.

Observed result

When I connect via the Kong ( based on nginx) loadbalancer and with the keycloak protection, when I hit sign in nothing happened, no errors in the logs, and I can't pass the login pages ...

Expected result

When I do a portforward of the dashboard service, I am able to connect with the kubeconfig, so I am assuming the issue come from a incompatibility with the oidc protocol somewhere.

Comments

It looks like it is a frontend protection and that the button does not work in this case.

Any idea on what could stop me from login in ?

Thanks in advance.

Samsja

@samsja samsja added the kind/bug Categorizes issue or PR as related to a bug. label May 10, 2020
@samsja
Copy link
Author

samsja commented May 10, 2020

turns out that with the same config it worked on google chrome, but not on firefox. I am suspected a bug.

Any idea ?

@floreks
Copy link
Member

floreks commented May 10, 2020

If you want to access Dashboard via HTTP it is only possible if domain/ip is localhost/127.0.0.1. URL in the browser is the on that matters. In every other case, you have to use HTTPS. You can also skip login view if your proxy forwards an Authorization header to the Dashboard. I don't think browser matters here. I have tested such setups both in Firefox and in Chrome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants