Azure-docs: How do we make the dashboard available in RBAC enabled cluster using az aks browse?

[badalk]

It is given that we cannot grant cluster role binding with cluster-admin role to kubernetes-dashboard service account. Any guidance around this would be greatly appreciated either using az aks OR with kubectl command.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 2ba1dad2-9792-2a7b-cdb6-68da0524cff3
• Version Independent ID: 42736112-f6db-d241-e89b-48fd2c35ceb7
• Content: Manage Azure Kubernetes cluster with web UI
• Content Source: articles/aks/kubernetes-dashboard.md
• Service: container-service
• GitHub Login: @iainfoulds
• Microsoft Alias: iainfou

[mimckitt]

Thanks for the question! We are investigating and will update you shortly.

[mimckitt]

@badalk based on the doc it appears to provide a work around

https://docs.microsoft.com/en-us/azure/aks/kubernetes-dashboard#for-rbac-enabled-clusters

For RBAC-enabled clusters
If your AKS cluster uses RBAC, a ClusterRoleBinding must be created before you can correctly access the dashboard. By default, the Kubernetes dashboard is deployed with minimal read access and displays RBAC access errors. The Kubernetes dashboard does not currently support user-provided credentials to determine the level of access, rather it uses the roles granted to the service account. A cluster administrator can choose to grant additional access to the kubernetes-dashboard service account, however this can be a vector for privilege escalation. You can also integrate Azure Active Directory authentication to provide a more granular level of access.

Does this not address the issue? If not please clarify so I can better assist :)

[badalk]

Below highlighted sections sounds contradicting to me

From: Micah [e-mail]
Sent: Friday, September 14, 2018 10:04 PM
To: MicrosoftDocs/azure-docs [e-mail]
Cc: Badal Kotecha [e-mail]; Mention [e-mail]
Subject: Re: [MicrosoftDocs/azure-docs] How do we make the dashboard available in RBAC enabled cluster using az aks browse? (#14983)

• This e-mail originated outside of Mindtree. Exercise caution before clicking links or opening attachments *

@badalkhttps://github.com/badalk based on the doc it appears to provide a work around

https://docs.microsoft.com/en-us/azure/aks/kubernetes-dashboard#for-rbac-enabled-clusters

For RBAC-enabled clusters
If your AKS cluster uses RBAC, a ClusterRoleBinding must be created before you can correctly access the dashboard. By default, the Kubernetes dashboard is deployed with minimal read access and displays RBAC access errors. The Kubernetes dashboard does not currently support user-provided credentials to determine the level of access, rather it uses the roles granted to the service account. A cluster administrator can choose to grant additional access to the kubernetes-dashboard service account, however this can be a vector for privilege escalation. You can also integrate Azure Active Directory authentication to provide a more granular level of access.

Does this not address the issue? If not please clarify so I can better assist :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/14983#issuecomment-421523003, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AOYOqnE3-8IKlBpKcFpRJWk6AWbpX2dcks5ubGAogaJpZM4Woduu.

---

http://www.mindtree.com/email/disclaimer.html

[mimckitt]

@badalk sorry but I am not seeing any highlighted sections. If you reply from email you often lose the formatting. Could you reply from a PC and clarify which part is confusing?

[badalk]

Between these two statements:

The Kubernetes dashboard does not currently support user-provided credentials to determine the level of access, rather it uses the roles granted to the service account

You can also integrate Azure Active Directory authentication to provide a more granular level of access

How do we integrate dashboard with Azure AD auth, and in that case wouldn't it ask user to provide credentials?

Regards
Badal

[mimckitt]

We have a doc on how to integrate AKS with AAD

https://docs.microsoft.com/en-us/azure/aks/aad-integration

If you integrate with AAD it would prompt the user for credentials if they are not already logged into the account.

Is that not what you are looking for?

[badalk]

Not really. I am looking for access to dashboard based on the context of the user. For example if a user has access to a particular namespace in the cluster, will he have the similar permissions on the dashboard to deal with that specific namespace

[mimckitt]

@iainfoulds would you be able to comment further on this?

[iainfoulds]

Rather than creating a role binding that is tied to a service account, a role binding can be created that points to the object of an Azure AD user or group. That's the only difference. It's still all controlled by that Kubernetes role and role binding in terms of which namespaces the Azure AD user or group can access, and what permissions they then have to perform actions.

There's doc update already in progress that shows how to apply these changes, but it's not really anything specific to AKS or Azure AD. The following example would grant read-only permissions for the kube-system namespace to the Azure AD group with an ID of d092bfb0-0000-0000-0000-19241f0e4e84:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: kube-system
  name: proxy-dashboard
rules:
  - apiGroups: [""]
    resources:
      - services
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources:
      - services/proxy
    verbs: ["get", "list", "watch", "create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: kube-system
  name: user-binding-dashboard
roleRef:
  kind: Role
  name: proxy-dashboard
  apiGroup: ""
subjects:
- kind: Group
  name: "d092bfb0-0000-0000-0000-19241f0e4e84"
  apiGroup: ""

[badalk]

Thanks @iainfoulds , i created the role and role binding as you stated above but does this work with az aks browse? because I get a message post login with the user which is part of this new group i created in AD, saying that the logged in user does not have permissions to list pods in kube-system

az aks browse --resource-group rg-aks-arm --name myfirstakscluster Merged "myfirstakscluster" as current context in /tmp/tmpswmadxns To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code SOMECODE to authenticate. Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list pods in the namespace "kube-system" Could not find dashboard pod: Command '['kubectl', 'get', 'pods', '--kubeconfig', '/tmp/tmpswmadxns', '--namespace', 'kube-system', '--output', 'name', '--selector', 'k8s-app=kubernetes-dashboard']' returned non-zero exit status 1.

[iainfoulds]

I haven't tested this from az aks browse. It's possible that since it tunnels the connection for the Kubernetes dashboard it first checks for the running dashboard pod and the port that it's running on. If that's the blocking behavior, would need to open an issue against the Azure CLI.

Try az account get-access-token --query accessToken -o tsv to get an access token for your user, then start the connection with kubectl proxy. You can then browse to the Kubernetes dashboard at http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/login and enter the access token for your user.

[mimckitt]

@badalk any update on this?

[badalk]

its not working for me either ways. I will spend some time over the weekend.

[mimckitt]

@badalk any luck over the weekend?

[mimckitt]

@badalk I will close for now. When ready let me know and we can reopen and continue.

[Sudharma]

Surprisingly it works for me if I use the access token but If I use the normal secret token I cannot access the k8s dashboard. I have created a seperate service account that has clusterrolebindings to my Azure AD group

[Sudharma]

I install a new cluster and now with the access token I get logged in Dashboard but get these kind of errors. Any changes on azure aks side?
configmaps is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list configmaps in the namespace "default"

[love2dishtech]

Hi @Karishma-Tiwari-MSFT,

I am following this issue from various closed issues and it appears that there is no solution available for this. Any idea if a fix has been proposed for this? Appreciate your help.

[Karishma-Tiwari-MSFT]

@love2dishtech This is the open issue: https://github.com/MicrosoftDocs/azure-docs/issues/23789
Further updates will be shared on that thread.
Please take a look there and let me know if you are seeing the same issue on your end.

[love2dishtech]

@love2dishtech This is the open issue: #23789
Further updates will be shared on that thread.
Please take a look there and let me know if you are seeing the same issue on your end.

Thanks a lot for quick reply. Appreciate it.

[CloudA2Z-Code]

I haven't tested this from az aks browse. It's possible that since it tunnels the connection for the Kubernetes dashboard it first checks for the running dashboard pod and the port that it's running on. If that's the blocking behavior, would need to open an issue against the Azure CLI.

Try az account get-access-token --query accessToken -o tsv to get an access token for your user, then start the connection with kubectl proxy. You can then browse to the Kubernetes dashboard at http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/login and enter the access token for your user.

That did not work i still cannot access dashboard at 127.0.0.1:8001 and the proxy stays in starting state. Any other solution for this issue in accessing dashboard , where i am giving access to user on a seprate namespace but should be able to access AKS dashboard which is running in kube-system namespaces ?

[CloudA2Z-Code]

Rather than creating a role binding that is tied to a service account, a role binding can be created that points to the object of an Azure AD user or group. That's the only difference. It's still all controlled by that Kubernetes role and role binding in terms of which namespaces the Azure AD user or group can access, and what permissions they then have to perform actions.

There's doc update already in progress that shows how to apply these changes, but it's not really anything specific to AKS or Azure AD. The following example would grant read-only permissions for the kube-system namespace to the Azure AD group with an ID of d092bfb0-0000-0000-0000-19241f0e4e84:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: kube-system
  name: proxy-dashboard
rules:
  - apiGroups: [""]
    resources:
      - services
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources:
      - services/proxy
    verbs: ["get", "list", "watch", "create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: kube-system
  name: user-binding-dashboard
roleRef:
  kind: Role
  name: proxy-dashboard
  apiGroup: ""
subjects:
- kind: Group
  name: "d092bfb0-0000-0000-0000-19241f0e4e84"
  apiGroup: ""

If someone is trying to setup 'Kuberntes Multitenancy' on the namespace, why one would give access to 'kube-system' by role and role-binding. All we want to give acccess to only one namepsace to specific applicaion user ?

Do i sound right or not ?