Dashboard: Helm Chart Issues with extraArgs

[sguidos]

Environment

Docker Desktop for Windows, Docker version 19.03.8, Kubernetes version 1.15.5, Helm version 2.16.3

Installation method:
helm install --name kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --set service.type=NodePort,enable-insecure-login=true,enable-skip-login=true

Steps to reproduce

Run the above installation command in Powershell, As an Administrator.

Observed result

1 - service kubernetes-dashboard has NodePort = 443:3xxxx/TCP

NOTE: Leaving off the service.type=NodePort creates a ClusterIP at port 443 as well

2A - Browsing to https://localhost:3xxxx in Chrome does not display a "security risk" warning, and does not display a login screen with the "Skip" options as expected, instead I am redirected to the Dashboard home page, where I am "Unauthorized(401)" on every screen and tab.

2B - Using Firefox I get the expected "security risk" warning, and I'm redirected to a Login page which does NOT have a "skip" button.

3 - setting 'disable-settings-authorizer=true' has no effect on the "Unauthiorized (401) error

Expected result

1 - The service should be using port 80, because of the enable-insecure-login option.

2 - I should be redirected to a login page with "Skip" button

3 - I should have full authority within the Dashboard , particularly if I use the disable-settings-authorizer=true flag

Comments

I expected that the correct syntax for the 'extraArgs' options to be:
helm install --name kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --set service.type=NodePort,extraArgs.enable-insecure-login=true,extarArgs.enable-skip-login=true

which matches the extraArgs pattern I have used with other Helm packages. However, using this syntax give me the following error:
Error: YAML parse error on kubernetes-dashboard/templates/deployment.yaml: error converting YAML to JSON: yaml: line 58: did not find expected '-' indicator

Leaving off the 'extraArgs.' prefix appears to install the Helm Chart correctly, but with the incorrect behavior.

[floreks]

I am not sure about the extraArgs issue. Maybe @desaintmartin can help with that. As for other issues, it seems that you are misunderstanding the concept of alternative deployment and what enable-insecure-login and disable-settings-authorizer flags actually do.

As per documentation:

• enable-insecure-login - When enabled, Dashboard login view will also be shown when Dashboard is not served over HTTPS.
  
  
  
  • disable-settings-authorizer - When enabled, Dashboard settings page will not require user to be logged in and authorized to access settings page.
  
  

They have nothing to do with Dashboard being served over HTTP/HTTPS. The alternative deployment is served over HTTP, because it does not have auto-generate-certificates flag, nor any other flag that provides certificates.

Alternative deployment is meant to be used by advanced users that want to use some kind of auth reverse proxy and their own IdP to inject bearer tokens into the authorization header. Everyone else should simply use the recommended deployment. Most deployments already have admin-user Service Account or at least Cluster Role. For the second one, you only prepare an extremely simple yaml file with SA and ClusterRoleBinding. Get the token once with kubectl and use it to log in. You can then edit deployment using Dashboard and set token-ttl flag to 0, so that our "session" token will never expire. That's basically it.

Regarding different behavior in browsers, I can only assume that you have a leftover skipLoginPage cookie set in your chrome browser and that is why you can't see the login view. Try to clear cookies and it should act the same as in Firefox.

[desaintmartin]

Regarding extraArgs, I recommend using a values.yaml file, which is _much_ easier to manage than passing list arguments to the Helm command line.
However, if you really want to use list as command line arguments, I suggest reading issues like https://github.com/helm/helm/issues/1987.

[sguidos]

Thank you both for your help and time.

@floreks you are correct that I was a bit confused about enable-insecure-login, I assumed that this switch was causing the alternative.yaml installation to use port 80. However now that I am a little less confused, and have the extraArgs apparently working, I would expect that the enable-insecure-login switch to have exposed a non-SSL port (by default port 9090) but that does not seem to be the case. What is the correct way to expose non-SSL port 9090 via a NodePort?

@desaintmartin thanks for the link on passing array parameters on the Helm command line. It was not obvious, but after a little experimenting I can now get the results I want with the command line:
helm install --name kubenetes-dashboard kubernetes-dashboard/kubernetes-dashboard --set service.type=NodePort,extraArgs="{--enable-insecure-login=true,--enable-skip-login=true,--disable-settings-authorizer=true}"

I was surprised that I needed to include the double dash in the array literal, but that was the only way I could get this to work. Leaving out the double dash before each arg will correctly parse by Helm v2 but the switches will not correctly be acted on by the container, and I get Unauthorized (401) errors in the Dashboard.

Hopefully the above command line will be useful for others who are looking to install the Dashboard without passwords on their development machine.

[floreks]

I would expect that the enable-insecure-login switch to have exposed a non-SSL port (by default port 9090) but that does not seem to be the case. What is the correct way to expose non-SSL port 9090 via a NodePort?

As per documentation:

• enable-insecure-login - When enabled, Dashboard login view will also be shown when Dashboard is not served over HTTPS.
• disable-settings-authorizer - When enabled, Dashboard settings page will not require user to be logged in and authorized to access settings page.

They have nothing to do with Dashboard being served over HTTP/HTTPS. The alternative deployment is served over HTTP, because it does not have auto-generate-certificates flag, nor any other flag that provides certificates.

Alternative deployment is meant to be used by advanced users that want to use some kind of auth reverse proxy and their own IdP to inject bearer tokens into the authorization header. ...

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.