dashboard: kubeconfig files cannot login the dashboard

Works as intended. Read our Access Control guide on wiki pages to find out how it works.

A few thoughts for those who might end up here from search. The reason why my ~/.kube/config yaml file did not work in dashboard 1.8 was because it did not contain a token or a username with password. Searching for Not enough data to create auth info structure in the dashboard’s source code clearly shows that this is what was expected in a file you upload. The same was in @txg1550759’s case.

The yaml file I was trying to authenticate with came from /etc/kubernetes/admin.conf, which was generated by kubeadm 1.7 back in July. I saw other admin files since then that were generated by kops – these did contain a password if I remember correctly. So perhaps the lack of a token or a password in kubeconfig is some kind of a legacy thing or a kubeadm-specific thing, not sure.

I ran kubectl get clusterRoles and kubectl get clusterRoleBindings and saw an item called cluster-admin in both. However unlike other role bindings (e.g. tiller-cluster-rule), the cluster-admin one referred to something called apiGroup instead of ServiceAccount (to which a token can belong). Check out the difference in the bottom of each output:

kubectl edit ClusterRoleBinding tiller-cluster-rule

↓

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: 2017-07-23T16:34:40Z
  name: tiller-cluster-rule
  resourceVersion: "2328"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/tiller-cluster-rule
  uid: d3249b5d-6fc4-1227-8920-5250000643887
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:                              # ← here
- kind: ServiceAccount
  name: tiller
  namespace: kube-system

kubectl edit ClusterRoleBinding cluster-admin

↓

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2017-07-23T16:08:15Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "118"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin
  uid: 2224ba97-6fc4-1227-8920-5250000643887
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:                              # ← here
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

This suggests that my cluster probably does not have a dedicated ‘root’ service account per se. That’s why ~/.kube/config works for kubectl without having a token or a username and password in it, but does not work for the dashboard.

Nevertheless, I could get into the dashboard by authenticating myself as other ServiceAccounts and this worked well. Depending on the privileges of a service account I picked, the dashboard was giving me access to different resources, which is great! Here’s an example of getting a token for the service account called tiller to authenticate (you’ll have it if you use helm):

kubectl describe serviceaccount tiller -n kube-system

↓

Name:         tiller
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>

Image pull secrets:  <none>

Mountable secrets:   tiller-token-854dx

Tokens:              tiller-token-854dx

kubectl describe secret tiller-token-854dx -n kube-system

↓

...
Data
====
ca.crt:     1025 bytes
namespace:  11 bytes
token: ×××

Copy token ××× and paste it into the dashboard’s login screen.

The useful thing about the tiller service account in my case is that it’s bound to cluster-admin cluster role (see the yaml above). This is because tiller needs to be able to launch pods, set up ingress rules, edit secrets, etc. Such a role binding is not the case for any cluster, but it may be a default thing in the simple setups. If that’s the case, using tiller’s token in the dashboard makes you the ‘root‘ user, because this implies that you have the cluster-admin cluster role.

Finally, my upgrade from dashboard 1.6 to 1.8 can be considered as finished! 😄

---

All this RBAC stuff is way too advanced for me to be honest, so it can be that I‘ve done something wrong. I guess that a proper solution would be to create a new service account and a new role binding from scratch and then use that token in the dashboard instead of the tiller’s one. However I’ll probably stay with my tiller’s token for some time until I get energy for switching to a proper solution. Could anyone please confirm or correct my thoughts?

Not really sure why no one is posting this in the docs… Use the ‘clusterrole-aggregation-controller’ token to access your dashboard as ‘root’:

kubectl -n kube-system describe secrets \
   `kubectl -n kube-system get secrets | awk '/clusterrole-aggregation-controller/ {print $1}'` \
       | awk '/token:/ {print $2}'

Just kind of silly to not include a root account as a part of the dashboard deployment.

Hi everyone, thanks for the discussion , I got spent four days, after that I found the solution for the same: Issue :

Solution 👍

• open file at : vim ~/.kube/config
• Search for access-token: copy the token and past in the kube dashboard console . It worked for me.

If you con contact me in person : linux.kartik@gmail.com

I get that there are a lot of different ways to connect, it’s just unintuitive. I think the quickstart docs should call out at least one example of how to connect with a ‘root’ account. Taking hours of searching to find one login method makes people want to quit.

@floreks Thanks… this is a much better way of authenticating but I think the reason people have been ending up here has to do with the wiki docs for authentication for dashboard. It goes through the different methods of authentication but probably should at least provide a basic “Usage” section for (if you are new to kubernetes and you just installed dashboard, do the following steps in order to run dashboard 1. create service-account 2. get token 3. put token in your ~/.kube/config in this section of the yaml).

@kachkaev I’m really glad that you actually took time to try and find a solution on your own 😃 I can help you fill out the gaps.

A few thoughts for those who might end up here from search. The reason why my ~/.kube/config yaml file did not work in dashboard 1.8 was because it did not contain a token or a username with password. Searching for Not enough data to create auth info structure in the dashboard’s source code clearly shows that this is what was expected in a file you upload. The same was in @txg1550759’s case.

The yaml file I was trying to authenticate with came from /etc/kubernetes/admin.conf, which was generated by kubeadm 1.7 back in July. I saw other admin files since then that were generated by kops – these did contain a password if I remember correctly. So perhaps the lack of a token or a password in kubeconfig is some kind of a legacy thing or a kubeadm-specific thing, not sure.

Usually cluster provisioners like kubeadm or kops configure kubeconfig file to use certificate-based authentication. This is ok for binary such as kubectl because it can establish secure connection with API server and be authenticated based on your certificates. This way, however, will not work for web application as your private key should never leave your computer and web app cannot establish such connection as kubectl.

That is why we have to rely on other methods of authenticating user offered by kubernetes, such as token-based authentication or basic auth (login and password). Second one only works when authorization mode ABAC is enabled and you have some additional arguments passed to apiserver. None of these methods is deprecated. These are just different ways to authenticate user and all of them can be specified in kubeconfig file.

There are even more authentication options. That is why it is highly recommended to read our documentation first, before using Dashboard. In Introduction section of our Access control guide, we provide links that should help users get rid of any doubts how Dashboard works. Especially link to Authenticating in Kubernetes.

https://github.com/kubernetes/dashboard/wiki/Access-control#introduction

All this RBAC stuff is way too advanced for me to be honest, so it can be that I‘ve done something wrong. I guess that a proper solution would be to create a new service account and a new role binding from scratch and then use that token in the dashboard instead of the tiller’s one. However I’ll probably stay with my tiller’s token for some time until I get energy for switching to a proper solution. Could anyone please confirm or correct my thoughts?

RBAC is generally quite a big topic in kubernetes. I’d recommend reading Using RBAC Authorization guide to find out how to create and configure “user” with required permissions. We are really trying to keep our documentation clear for users and provide all necessary links so they can find out how everything works and how to work with not only Dashboard, but also Kubernetes.

In case you have some more doubts or questions you can ask me. I’ll try to help if I can.

I dont see the correct answer from the internet nor from the official document. here is my research. may this could help you.

First, you need to have a account(ideally you could use the build-in account, kubectl get clusterroles to get all build-in account, very recommend to use edit rather than admin)

Then, type this command to get the token which would be used in kubeconfig kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep edit | awk '{print $1}')

Finally, the structure for the kubeconfig should be like this

current-context: [account-name]
contexts:
- context:
    user: [account-name]
  name: [account-name]
users:
- name: [account-name]
  user:
    token: [token value which you get at step2]

those works for me and here is my dashboard versionkubernetes-dashboard-amd64:v1.10.0

I used https://github.com/kubernetes/dashboard/wiki/Creating-sample-user but edit the ClusterRoleBinding to:

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system
EOF

This gave kubernetes-dashboard the admin permissions. Then I took its token with:

kubectl -n kube-system describe secrets \
   `kubectl -n kube-system get secrets | awk '/kubernetes-dashboard/ {print $1}'` \
       | awk '/token:/ {print $2}'

And used it. It looks like it stuck on the login, after 20 seconds I pressed “skip” and then I have the permissions.

To run on the dashboard I used:

kubectl proxy --address=0.0.0.0 --accept-hosts='.*'
Starting to serve on [::]:8001

Which is really not recommended because everyone can access it. And then used: http://<master_ip>:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login

Can we print a more clear error message about Certificate Auth not being supported?

"Not enough data to create auth info structure" implies to the user that the kube config is deficient.

Additionally, it might be useful to state upfront that certificate auth is not supported before the user selects a kubeconfig.

It would be cool if when using kubectl proxy, the API server would pass on the information about the logged in user; and the kubernetes dashboard could use this 😃

All the best, Sebastian

https://github.com/kubernetes/dashboard/wiki/Access-control#kubeconfig

@floreks Thanks for the pointers. We’ve used https://github.com/kubernetes/dashboard/wiki/Access-control#getting-token-with-kubectl.

I would like to kindly point out that the workflow is not quite obvious. Repurposing a token randomly picked from a list of service seems rather arbitrary. Would there a chance to package this as a feature of kubectl. Something like kubectl config get-bearer-token.

@txg1550759 were you able to find what the problem was? I also have a admin.conf that was generated for me by kubeadm, but it does not work. I can do kubectl get pods etc. with it though.

@cdennen creating sample user and getting token is also described in the docs.

https://github.com/kubernetes/dashboard/wiki/Creating-sample-user

Wiki describes few ways of accessing Dashboard (kubectl proxy, NodePort, directly through api server). We will not provide ingress method as it is very custom and user has to decide what tools to use and how to configure them to expose an application.

It was already explained many times why certificate-based authentication is not supported. It will not be added for security reasons as the private key should never leave user’s computer.

@floreks - that’s great documentation!

A lot of individual’s workflows look like:

• Google ‘kubernetes dashboard’
• Hit the Kubernetes Dashboard GitHub README.md
• Click ‘installation’ under Documentation
• Installation with kubectl create -f ...
• Wonder how to connect to the dashboard

Could you please include information and link on that page? https://github.com/kubernetes/dashboard/wiki/Installation

From reading the abovementioned documentation

kubectl create serviceaccount jdanek
kubectl get serviceaccount jdanek -o yaml
kubectl describe secret jdanek-token-zbt5x
kubectl create rolebinding jdanek-admin --clusterrole=cluster-admin --serviceaccount=default:jdanek

I am the one who has the power over the cluster now ))

edit: no, not really, I needed clusterrolebinding there

@abrahamrhoffman’s solution no longer worked for me in k8s 1.19.2, probably because clusterrole-aggregation-controller is no longer an admin (I’m not an expert in k8s, so this is just a speculation).

What helped was the creation of a special service account with admin privileges and then printing its token:

kubectl --namespace=kube-system create serviceaccount cluster-admin-dashboard-sa

kubectl --namespace=kube-system create clusterrolebinding cluster-admin-dashboard-sa \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:cluster-admin-dashboard-sa

kubectl --namespace=kube-system describe secrets \
  $(kubectl --namespace=kube-system get secrets | awk '/cluster-admin-dashboard-sa-token/ {print $1}') \
  | awk '/token:/ {print $2}'

---

UPD: Turns out that the Dashboard docs also include a recipe for creating the service account:
https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md

Yes I am abke to access but issue is , need to provide token value everytime, when token expired. It has resolved the issue temporary, I’ll work on it for permanent solution.

On Tue 20 Feb, 2018, 18:12 Sebastian Florek, notifications@github.com wrote:

Accessing Dashboard is a different topic and is available on the right side menu under Accessing Dashboard section. [image: zrzut ekranu z 2018-02-20 13-37-54] https://user-images.githubusercontent.com/2285385/36424511-cdc76800-1643-11e8-99ca-fbfff434fe20.png

Direct link is alaso available right next to Installation link under Documentation section in our README.md. [image: zrzut ekranu z 2018-02-20 13-40-28] https://user-images.githubusercontent.com/2285385/36424530-e07a9b16-1643-11e8-8a52-66881737a6a3.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kubernetes/dashboard/issues/2474#issuecomment-366965797, or mute the thread https://github.com/notifications/unsubscribe-auth/Ag9upJKRJiXQnu7iT6iVME5CMBN_rU6cks5tWr3OgaJpZM4P4vI7 .

Maybe makes sense to also provide sample dashboard proxy setup since /ui no longer works?

Something like kubectl config get-bearer-token.

That sounds like a good idea to me; the issued tokens could have a relatively small time limit.

Otherwise, I think the “right” way of doing this would be with OpenID. It would be nice if the dashboard itself would redirect to your openid provider, where you could authenticate, and redirect back; but AFAIK you currently need something like kubelogin.

@VampireDaniel That command prints tons of tokens, but which is the correct one?

@VampireDaniel This is probably the answer everyone is looking for. The documentation doesn’t explain how to add the token to the kube config.

username and password are indicatif, not functional

https://github.com/kubernetes/dashboard/wiki/Access-control#basic

most important is the structure and the token. I figured out that sample kubeconfig file looks like following:

https://github.com/kubernetes/dashboard/wiki/Access-control#kubeconfig

Structure of kubeconfig file can be seen in official documentation: https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

I think it is not recommended to configure multiple auth option for a single user…

@abrahamrhoffman You mean being able to access Dashboard as root like described in here? https://github.com/kubernetes/dashboard/wiki/Access-control#admin-privileges

Only authenticated token bearers will be able to get the details about the existing resources and change them (as long as a token represents a ServiceAccount with enough privileges). Am a right about this?

Token does not have to be necessarily tied to the Service Account. It can be generated by OIDC or any external identity provider. As long as API server accepts it, then it is ok. There are more ways of configuring and getting “correct” token to log in.

I understand that the best option is to keep https://dashboard.example.com/ available only behind a firewall, but am still curious if exposing this resource publicly is OK for simple clusters with non-critical personal projects. A friend of mine has got an opposite opinion, we need to stop our dispute once and for all.

By default Dashboard has now very little permissions that do not impose any security risks anymore (https://github.com/kubernetes/dashboard/wiki/Access-control#v18). I do not see any security threats in exposing Dashboard publicly if everything is configured properly. There is no way to escalate privileges right now, so exposing Dashboard should be no different than exposing API server (secured, with RBAC enabled).

Thank you for replies @maciaszczykm and @floreks! RBAC’s getting slightly clearer over time, thanks to the docs that are constantly improving. I really like the fact that, if installed correctly, the dashboard no longer has admin privileges and so it is possible to give different team members varying permissions. Totally agree that if everyone has kube-admin role, things can go wrong pretty quickly!

When I ran dashboard 1.6 at https://dashboard.example.com/, I was adding basic auth to the ingress rule to protect the dashboard from strangers – anyone could become an admin of my cluster otherwise. After upgrading to 1.8 with your official yaml, it seems that running https://dashboard.example.com/ is now safe even without any basic auth in ingress. If a hacker gets to that domain, they’ll only be able to know about the existence of the k8s cluster, but not perform any read/write operations on it. Only authenticated token bearers will be able to get the details about the existing resources and change them (as long as a token represents a ServiceAccount with enough privileges). Am a right about this?

I understand that the best option is to keep https://dashboard.example.com/ available only behind a firewall, but am still curious if exposing this resource publicly is OK for simple clusters with non-critical personal projects. A friend of mine has got an opposite opinion, we need to stop our dispute once and for all 😄

I guess that a proper solution would be to create a new service account and a new role binding from scratch and then use that token in the dashboard instead of the tiller’s one.

Correct. It is recommended way of handling it.

However I’ll probably stay with my tiller’s token for some time until I get energy for switching to a proper solution. Could anyone please confirm or correct my thoughts?

If it works for you it is fine. You should be aware, that everyone with cluster-admin role is able to perform critical changes within cluster. That’s why it should be accessible only to small group of people.