Azure-docs: AKS with RBAC unable to view Dashboard with Azure AD

Created on 30 Jan 2019  ·  48Comments  ·  Source: MicrosoftDocs/azure-docs

I have RBAC enabled AKS cluster with proper Azure AD integration. The things are working fine at control plane. However to access dashboard, I create an access token az account get-access-token --query accessToken -o tsv and I start kubectl-proxy.

Expected behaviour : The members of Azure AD group should be able to have full permission on the dashboard with the token. This was working fine before( Cluster was almost a month old). Now I have a new cluster.

Actual Behaviour : The dashboard is forbidding access to the cluster admins.

Actually I would like to know that when the cluster is RBAC enabled with proper Azure AD integration, does granting a cluster-admin access to kubernetes-dashboard service account makes its unsecure? Or I understand from documents that the with the dashboard URL anyone could access the Cluster.

Clarifications

  1. I have proper ClusterRoleBinding for the AzureAD group.( with cluster-admin Role)
  2. When I elevate the ClusterRoleBinding kubernetes-dashboard service account to cluster-admin the dashboard works.(This is quite obvious but making it explicit)

Document Details

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

Pri1 assigned-to-author container-servicsvc doc-bug triaged

Most helpful comment

@MicahMcKittrick-MSFT I am through this and it works fine. I am referring this one
https://docs.microsoft.com/en-us/azure/aks/kubernetes-dashboard#for-rbac-enabled-clusters
precisely with the RBAC for dashboard.

You can also integrate Azure Active Directory authentication to provide a more granular level of access. More interested on how to do this.!

All 48 comments

@Sudharma can you share the doc you are referring to so we can better assist?

Is it this one?

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

@MicahMcKittrick-MSFT I am through this and it works fine. I am referring this one
https://docs.microsoft.com/en-us/azure/aks/kubernetes-dashboard#for-rbac-enabled-clusters
precisely with the RBAC for dashboard.

You can also integrate Azure Active Directory authentication to provide a more granular level of access. More interested on how to do this.!

@Sudharma thanks for that!

@iainfoulds @seanmck could either of you comment further on this ask?

@Sudharma sorry for the delay on this. I have been trying to repro this but have had issues getting an RBAC cluster setup using my internal subscription. We are all taking a look and will update as soon as possinble

@iainfoulds aplogies but I have not been able to get my environment setup to accurately test this. For some reason my RBAC enabled cluster is not provisioning correctly even on my personal subscription. I have been trying this for days without any luck. Could you try to repro this as well? I am just not having any luck.

CC @Karishma-Tiwari-MSFT @jakaruna-MSFT if they can try a repro as well

@Sudharma sorry for the delay on this. I have been trying to repro this but have had issues getting an RBAC cluster setup using my internal subscription. We are all taking a look and will update as soon as possinble

No problem. However please keep me updated since I am eager on this solution

It is the same issue with me as well. I see that the dashboard login prompt as well does not pass the token issued via the login screen. It still treats the dashboard connection requests via the service account.

Also, I have not given dashboard access to the service account, because of privilege escalation it creates.

In short, dashboard access via proxy works well with the service account, but not with OpenID connect account token.

This issue remains a problem for us as well. So here's my +1

+1 here as well,

Hi Team,

Would you be able to provide more details about how it operates and what is different from native Kubernetes engine. I am wondering if we could provide some support for the same. Also wondering, if dashboard can be configured to use the Azure AD via a proxy service?

Anyone have an update on this? I can access if I pull the token or use the kube config file after running "kubectl proxy", but if I run az aks browse I get asked to login via the web (even though I have done az login already) with a device code, entering the code leads me to an error on the cmd line "Oauth token: Unknown Error". I have setup the cluster with Rbac (with client and server app registrations and set the permissions as per (https://docs.microsoft.com/en-us/azure/aks/aad-integration).

The only thing im not sure about is that I have used an app registration for the client, server and the service principal so 3 app registrations in total. It was provisioned via terraform. The guide doc only mentions the permissions for the client and server app registrations.

Hope someone can help

Still facing the same issue. Cannot access dashboard, API or kubectl using AD accounts

Below command works, this creates k8s admin credentials to /home/user/.kube/config
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev --admin

After adding the cluster role binding with AD user or group, usually, users can login with below
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev

This will prompt for device token and users can login. But now this fails consistently.
Kubectl or dashboard is accessible only via cluster admin. Obviously, we can't give cluster admin creds to all the users.

Sorry people are running into issues here.

The engineering team has identified an issue and is working to resolve this. It seems to be an underlying Kubernetes dashboard change rather than specific behavior in AKS. @palma21 can provide additional context on timelines for resolution.

@spbreed problem seems different as he mentions inaccessible via kubectl as well (check if your secrets haven't expired and do open a support ticket so we can check you cluster and help).

For the rest that are having issues exclusively with dashboard, the newer versions of the dashboard require https or the insecure login flag or they will fall to Service Account login.

To force this you can edit you dashboard deployment
eg.
kubectl edit deploy -n kube-system kubernetes-dashboard

And add to your container spec.

containers:
- args:
  - --authentication-mode=token
  - --enable-insecure-login

Moving forward we will be enforcing token auth, changing port 9090 to 8443, scheme to HTTPS and using self-signed certificates. This will come out soon and will be announced on our Release notes.
https://github.com/Azure/aks/releases

Facing the same issue. Cannot access dashboard, API or kubectl using AD accounts.

My mistake : cannot access K8S dashboard using AD Accounts.

What process are you following to access the dashboard? Have you tried my comment above?

https://github.com/MicrosoftDocs/azure-docs/issues/23789#issuecomment-485010803

@palma21 I've just tried your suggestion and still getting same issue with list of errors when logging in to dashboard e.g.

  • kubectl proxy
  • http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/login

configmaps is forbidden: User "clusterAdmin" cannot list configmaps in the namespace "default"

I have no role binding for the service account 'kubernetes-dashboard'. I have tried with the cluster admin account token. I cant seem to get login with my AAD account to work at all although it is cluster admin and we have appropriate RBAC in place, is the token generated with command below valid for bearer token login?

  • az account get-access-token --query accessToken -o tsv

snippet of pod details:

Containers:
main:
Container ID: docker://610c6b258cde01196c03c918c3acca6c3c6ba531153ad1b7e0f034e032065319
Image: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
Image ID: docker-pullable://k8s.gcr.io/kubernetes-dashboard-amd64@sha256:0ae6b69432e78069c5ce2bcde0fe409c5c4d6f0f4d9cd50a17974fea38898747
Port: 9090/TCP
Host Port: 0/TCP
Args:
--authentication-mode=token
--enable-insecure-login
State: Running
Started: Thu, 25 Apr 2019 12:04:43 +0100

That message indicates that you clusterAdmin role does not have permissions to list config maps on that namespace. Could you try adding that to your User's role and see if that solves it?
Otherwise please send your ClusterAdmin role yaml and dashboard deployment yaml and I can take a look.

Just tried again with a service account (not the default dashboard) and it seems to be working which is great. However using a token of an AAD user with cluster-admin role binding is failing to login. Should an AAD use with correct RBAC be able to login to the dashboard with token and receive the level of privilege in dashboard as defined in their RBAC binding?

Yes it should. Can you list config maps on the default NS with the user you are getting the token to k8s dashboard? If you can do that action with the user then it's expected, otherwise I'd say check which token your are passing to the Dashboard.

To avoid spamming this thread that appears resolved please drop me a mail at jpalma [at] microsoft.com

To force this you can edit you dashboard deployment
eg.
kubectl edit deploy -n kube-system kubernetes-dashboard

And add to your container spec.

containers:
- args:
  - --authentication-mode=token
  - --enable-insecure-login

Moving forward we will be enforcing token auth, changing port 9090 to 8443, scheme to HTTPS and using self-signed certificates. This will come out soon and will be announced on our Release notes.
https://github.com/Azure/aks/releases

You guys promised timelines, at the moment there is no solution and we revert to using this insecure solution. The issue has been open for a long time while at the same time there are other things being attended. Can you give us real timelines??

@iainfoulds Can you please actually provide timelienes??
quoting :

@palma21 can provide additional context on timelines for resolution.

@palma21 At the moment the solution is far from ideal, for some reason the lines of code do not work,
error: deployments "kubernetes-dashboard" is invalid

Moving forward we will be enforcing token auth, changing port 9090 to 8443, scheme to HTTPS
When???

If the deployment manifest is invalid it's likely a syntax or indentation issue. I just did it again and it works.
Try with an inline
args: ["--authentication-mode=token", "--enable-insecure-login"]

We should have this change around end of June timeframe.

This is what I did based on @palma21 notes:
aks-dashboard.sh

# As a workaround accessing the dashboard using a token without enforcing https secure communication (tunnel is exposed ver http), you can edit the dashboard deployment with adding the following argument
# It is an issue currently being discussed here https://github.com/MicrosoftDocs/azure-docs/issues/23789
# args: ["--authentication-mode=token", "--enable-insecure-login"] under spec: containers
# spec:
#   containers:
#   - name: *****
#     image: *****
#     args: ["--authentication-mode=token", "--enable-insecure-login"]
kubectl edit deploy -n kube-system kubernetes-dashboard

# Get AAD token for the signed in user (given that user has the approperiate access). Use (az login) if you are not signed in
SIGNED_USER_TOKEN=$(az account get-access-token --query accessToken -o tsv)
echo $SIGNED_USER_TOKEN

# establish a tunnel and login via token above
# If AAD enabled, you should see the AAD sign in experience with a link and a code to https://microsoft.com/devicelogin
az aks browse --resource-group $RG --name $CLUSTER_NAME

# You can also use kubectl proxy to establish the tunnel as well
# kubectl proxy
# Then you can navigate to sign in is located http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/login

# Note: you can also use the same process but with generated kubeconfig file for a Service Account that is bound to a specific namespace to login to the dashboad.

I tried this:
kubectl edit deploy -n kube-system kubernetes-dashboard
with the latest AKS deployed as of 2019-09-12.
Notepad opened populated with a yaml file, but when I saved and closed I received the error:

error: deployments.extensions "kubernetes-dashboard" is invalid
error: Edit cancelled, no valid changes were saved.

Any ideas?

This seems like quite a major bug. As I understand it, you can't use AAD logins to access the Kubernetes dashboard.

Even worse, the documentation is wrong, as it implies you can:

When setting up authentication for the Kubernetes dashboard, it is recommended that you use a token over the default dashboard service account. A token allows each user to use their own permissions. Using the default dashboard service account may allow a user to bypass their own permissions and use the service account instead.

From reading this thread, this is broken. Can this bug either be fixed, or at least the documentation updated to make it clear this is currently not possible?

This ticket was first raised on 30th Jan, that is a long time for this bug to be open.

We should have this change around end of June timeframe.

@palma21 June has gone, is there an ETA for this fix to be deployed?

We rolled it out, including new docs (which you noticed above) but had to roll it back due to new browser behavior and a bug.

We are currently working on a fix to have it by the end of this month.

There is a workaround to enable this functionality in the meantime which involves
editing the deployment with
args: ["--authentication-mode=token", "--enable-insecure-login"]

Your error above appears to be a syntax or editor issue, I just retested and it still works.

Is there any updates regarding this bug?

Facing the same issue, is there any update on this and an ETA by which it will be fixed?

Gosh, it's really dissapointing to bet for Microsoft products spending a couple of months deploying a full stack solution using their AKS to find out there's a bug like this....

Spamming this issue as well - seeing as that's what my employer's support staff over @ Microsoft1 told me to do.

Would very much like a solution which does _not_ involve turning off SSL.

1: Received instructions personally and directly from a _Support Escalation Engineer_, coming from: Customer Service and Support / Microsoft Azure Technical Support / Azure Containers Team - EMEA -

I love the transparency here and the great communication from MS. 🤦‍♂

@palma21 Can you please share if you have any update on this issue? Thanks :)

It would be good to get an update on this

Do we have any fix for this or its just RBAC enabled AKS cluster tenant need to go through hacks only ?

what's the backlog item name we can track to see this issue to resolution?

Latest news - that I as a private person whom through work speak with some Microsoft experts - can share is (from an unnamed Microsoft Architect K8s Advisor Expert - that's not the title, it's a description of said title) that the Dashboard Plugin is inherently unsafe and should not be used.

I agree with that statement, and I would ask all future people who come here asking this same question read through / build competence in K8s to understand the security risks/concerns such a plugin introduces.

(For the mere gain of having a Web UI with knobs and dials instead of just using the perfectly workable CLI tools - among which there are more and more added to K8s as a standard, such as kustomize).

@pierluigilenoci

This is doable with https://github.com/pusher/oauth2_proxy

Hi
Could you please link or share a workable example that includes a yaml for a dashboard ingress, values.yaml for oauth2_proxy and any applicable settings for an Azure AD application?
I've been trying to get oauth2_proxy to work with Azure AD for several days but can't find a single full workable example that would go into sufficient detail on configuring this, and experimenting with various flags and settings only got me so far, but not far enough.
Would really appreciate it!

@edemen my tips:

  • don't use the default AKS dashboard, install it separately (v1.10.1) with helm
    Values for helm
    nginx.ingress.kubernetes.io/auth-url: "https://yourvalue/oauth2/auth" nginx.ingress.kubernetes.io/auth-signin: "https://yourvalue/oauth2/start?rd=$escaped_request_uri" nginx.ingress.kubernetes.io/configuration-snippet: | auth_request_set $token $upstream_http_authorization; proxy_set_header Authorization $token;
  • install oauth2_proxy with helm https://github.com/helm/charts/blob/master/stable/oauth2-proxy
  • Values for helm
    extraArgs: provider: "azure" azure-tenant: "yourvalues" whitelist-domain: "yourvalues" cookie-domain: "yourvalues" set-authorization-header: "true"
    and
    ingress: enabled: true path: /oauth2

This should be enough.

@pierluigilenoci
Thank you for replying.
I have managed to get Azure AD and oauth2 proxy working today, but I am finding that many settings end up in error 500 caused by error 400 returned by login.live.com (more details in https://github.com/oauth2-proxy/oauth2-proxy/issues/458 )
Essentially, if I use set-authorization-header: "true", authentication with oauth2 proxy stops working at all with Azure. Trying to figure out why, but nothing so far.
Just in case, I am installing oauth2 proxy with helm install oauth2-proxy stable/oauth2-proxy -n oauth2-proxy --values oauth2-proxy-values.yaml

Never mind. Apparently Dashboard v1.10.1 does not even work on Kubernetes 1.16 that we have.
Thank you

I didn't have any luck with getting the out-of-the-box Kubernetes dashboard working with AKS, but I must admit I didn't spend a lot of time working on it. The solution that appears to be working (time will show any issues) is to use the standard dashboard with kubectl proxy and uploading the local users kubeconfig.

It's a multi-step process which isn't as easy/nice as a simple URL, but appears to be the best way to use the dashboard running under the AD users context. I'm still keeping my eye out for a cleaner approach that doesn't require a lot of customization of the dashboard itself and yet uses Azure AD.

@edemen of course this works only for K8s < 1.15. For K8s 1.16 you need to wait until the official release of the new v2.0 dashboard, I presume.

Dashboard v2 has launched https://github.com/kubernetes/dashboard/releases/tag/v2.0.0 . But it seems to have partial support for k8s 1.16

@SayakMukhopadhyay up to version v2.0.0-rc3 it was fully supported. I used the latest RC with version 1.15 and 1.16 and worked pretty well. I don't know which operation you need to do but for sure 99,99% of normal usage is covered.

Thank you for the feedback!

The article has been recently updated with details on signing in to the Kubernetes dashboard.

please-close

Was this page helpful?
0 / 5 - 0 ratings

Related issues

varma31 picture varma31  ·  3Comments

paulmarshall picture paulmarshall  ·  3Comments

Ponant picture Ponant  ·  3Comments

Favna picture Favna  ·  3Comments

spottedmahn picture spottedmahn  ·  3Comments