@Sudharma可以分享您引用的文档，以便我们提供更好的帮助吗？

是这个吗？

https://docs.microsoft.com/zh-CN/azure/aks/aad-integration

@ MicahMcKittrick-MSFT我已经通过了，它工作正常。 我指的是这个
https://docs.microsoft.com/zh-cn/azure/aks/kubernetes-dashboard#for -rbac-enabled-clusters
恰好与RBAC一起用于仪表板。

You can also integrate Azure Active Directory authentication to provide a more granular level of access.对如何执行此操作更感兴趣。

@Sudharma对此表示感谢！

@iainfoulds @seanmck你们中的任何一个都可以对此问题发表进一步的评论吗？

@Sudharma对您的延迟

@iainfoulds表示歉意，但是我无法获得环境设置以进行准确的测试。 由于某些原因，即使启用了我的个人订阅，启用RBAC的群集也无法正确配置。 我已经尝试了好几天没有运气了。 您也可以尝试复制吗？ 我只是没有运气。

CC @ Karishma-Tiwari-MSFT @ jakaruna-MSFT（如果他们也可以尝试复制）

@Sudharma对您的延迟

没问题。 但是，请紧跟我，因为我急于解决此问题

我也是同样的问题。 我看到仪表板登录提示也没有传递通过登录屏幕发出的令牌。 它仍然通过服务帐户处理仪表板连接请求。

另外，由于它创建了特权升级，因此我没有授予仪表板访问服务帐户的权限。

简而言之，通过代理访问仪表板可以很好地与服务帐户一起使用，但不能与OpenID Connect帐户令牌一起使用。

这个问题对我们也是一个问题。 所以这是我的+1

这里也+1

嗨，团队，

您是否能够提供有关其运行方式以及与本地Kubernetes引擎有何不同的更多详细信息。 我想知道我们是否可以为此提供一些支持。 还想知道是否可以将仪表板配置为通过代理服务使用Azure AD？

有人对此有更新吗？ 运行“ kubectl代理”后，我可以访问是否提取令牌或使用kube配置文件，但是如果运行az aks浏览，系统会要求我使用设备代码通过网络登录（即使我已经进行过az登录） ，输入代码会使我在cmd行“ Oauth令牌：未知错误”上出错。 我已经使用Rbac设置了群集（具有客户端和服务器应用程序注册，并根据（https://docs.microsoft.com/zh-cn/azure/aks/aad-integration）设置了权限。

我唯一不确定的是，我已经为客户端，服务器和服务主体使用了应用程序注册，因此总共进行了3个应用程序注册。 它是通过terraform设置的。 指南文档仅提及客户端和服务器应用程序注册的权限。

希望有人能帮忙

仍然面临着同样的问题。 无法使用AD帐户访问仪表板，API或kubectl

下面的命令起作用，这将创建k8s管理员凭据到/home/user/.kube/config
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev --admin

添加与AD用户或组的群集角色绑定后，通常，用户可以通过以下方式登录
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev

这将提示您输入设备令牌，并且用户可以登录。 但是现在这始终失败。
Kubectl或仪表板只能通过集群管理员访问。 显然，我们无法为所有用户提供集群管理员资格。

抱歉，这里遇到了很多问题。

工程团队已发现问题，并正在努力解决。 这似乎是潜在的Kubernetes仪表板更改，而不是AKS中的特定行为。 @ palma21可以在时间轴上提供其他上下文以供解决。

@spbreed问题似乎有所不同，因为他还提到无法通过kubectl进行访问（检查您的机密是否尚未过期，并打开支持记录，以便我们可以检查您的群集和帮助）。

对于其余的完全是仪表板问题的仪表板，较新版本的仪表板需要https或不安全的登录标志，否则它们将落入服务帐户登录。

要强制执行此操作，您可以编辑仪表板部署
例如。
kubectl edit deploy -n kube-system kubernetes-dashboard

并添加到您的容器规范中。

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

展望未来，我们将强制执行令牌身份验证，将端口9090更改为8443，将方案更改为HTTPS并使用自签名证书。 它将很快发布，并将在我们的发行说明中宣布。
https://github.com/Azure/aks/releases

面对同样的问题。 无法使用AD帐户访问仪表板，API或kubectl。

我的错误：无法使用AD帐户访问K8S仪表板。

您要遵循什么流程才能访问仪表板？ 您是否尝试过以上我的评论？

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

@ palma21我刚刚尝试了您的建议，但登录到仪表板时仍然遇到错误列表的相同问题，例如

• kubectl代理
• http：// localhost ：8001 / api / v1 / namespaces / kube-system / services / kubernetes-dashboard / proxy /＃！/ login

禁止使用configmaps：用户“ clusterAdmin”无法在名称空间“ default”中列出configmaps

我没有为服务帐户“ kubernetes-dashboard”绑定角色。 我尝试使用群集管理员帐户令牌。 尽管我是AAD帐户，但似乎是无法使用我的AAD帐户登录的，尽管它是集群管理员，并且我们有适当的RBAC，使用以下命令生成的令牌对承载令牌登录有效吗？

• az帐户get-access-token --query accessToken -o tsv

广告连播详细信息摘要：

容器：
主要：
容器ID： docker：// 610c6b258cde01196c03c918c3acca6c3c6ba531153ad1b7e0f034e032065319
图片：k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
图片ID：docker- pullable：//k8s.gcr.io/kubernetes-dashboard-amd64@sha256 ：0ae6b69432e78069c5ce2bcde0fe409c5c4d6f0f4d9cd50a17974fea38898747
端口：9090 / TCP
主机端口：0 / TCP
精氨酸：
--authentication-mode =令牌
-启用不安全的登录
状态：运行中
开始时间：2019年4月25日，星期四12:04:43 +0100

该消息表明您的clusterAdmin角色无权列出该名称空间上的配置映射。 您可以尝试将其添加到用户角色中，看看是否可以解决该问题？
否则，请发送您的ClusterAdmin角色yaml和仪表板部署yaml，我可以看看。

只需使用服务帐户（不是默认的仪表板）再次尝试，它似乎可以正常工作。 但是，使用具有群集管理员角色绑定的AAD用户令牌无法登录。 使用正确的RBAC的AAD是否应该能够使用令牌登录到仪表板并按照其RBAC绑定中的定义接收仪表板中的特权级别？

是的，应该。 您能否与将令牌添加到k8s仪表板的用户一起列出默认NS上的配置映射？ 如果您可以与用户一起执行该操作，那是可以预期的，否则我会说要检查您将哪个令牌传递给仪表板。

为避免向此似乎已解决的线程发送垃圾邮件，请给我发邮件到jpalma [microsoft.com]

要强制执行此操作，您可以编辑仪表板部署
例如。
kubectl edit deploy -n kube-system kubernetes-dashboard

并添加到您的容器规范中。

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

展望未来，我们将强制执行令牌身份验证，将端口9090更改为8443，将方案更改为HTTPS并使用自签名证书。 它将很快发布，并将在我们的发行说明中宣布。
https://github.com/Azure/aks/releases

你们承诺了时间表，目前没有解决方案，我们将恢复使用这种不安全的解决方案。 这个问题已经开放了很长的时间，同时还有其他事情在进行。 你能给我们真实的时间表吗？

@iainfoulds能否请您实际提供timelienes？
引用：

@ palma21可以在时间轴上提供其他上下文以供解决。

@ palma21目前，该解决方案远非理想之选，由于某种原因，代码行不起作用，
错误：部署“ kubernetes-dashboard”无效

展望未来，我们将强制执行令牌身份验证，将端口9090更改为8443，将方案更改为HTTPS
什么时候？？？

如果部署清单无效，则可能是语法或缩进问题。 我又做了一次，就可以了。
尝试内联
args: ["--authentication-mode=token", "--enable-insecure-login"]

我们应该在6月底左右的时间范围内进行此更改。

这是我根据@ palma21注释所做的：
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.

我尝试了这个：
kubectl edit deploy -n kube-system kubernetes-dashboard
截至2019-09-12部署了最新的AKS。
记事本打开时填充了yaml文件，但是当我保存并关闭时，收到错误消息：

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

有任何想法吗？

这似乎是一个重大错误。 据我了解，您不能使用AAD登录来访问Kubernetes仪表板。

更糟糕的是，文档是错误的，因为它暗示您可以：

为Kubernetes仪表板设置身份验证时，建议您在默认仪表板服务帐户上使用令牌。 令牌允许每个用户使用自己的权限。 使用默认的仪表板服务帐户可能允许用户绕过其自己的权限，而是使用该服务帐户。

通过阅读此线程，这是坏的。 是否可以修复此错误，或者至少可以更新文档以使其清楚目前尚无法解决？

这张票是在1月30日首次提出的，这对于打开这个bug很长时间了。

我们应该在6月底左右的时间范围内进行此更改。

@ palma21 6月已经过去了，是否有部署此修复程序的ETA？

我们推出了它，包括新文档（您在上面注意到了），但是由于新的浏览器行为和错误，不得不将其回滚。

我们目前正在努力解决该问题，以便在本月底之前解决此问题。

在此期间，有一种变通方法来启用此功能，这涉及
使用编辑编辑部署
args：[“ --authentication-mode = token”，“ --enable-insecure-login”]

您上面的错误似乎是语法或编辑器问题，我刚刚对其进行了重新测试，但仍然可以使用。

关于此错误是否有任何更新？

面对相同的问题，是否对此进行了任何更新，以及是否可以通过ETA进行修复？

天哪，赌微软的产品花了几个月的时间来使用他们的AKS部署全栈解决方案来发现那里有一个bug真是令人失望。

垃圾邮件这个问题，以及-看到，因为这就是在@微软¹我的雇主的支持人员告诉我这样做。

非常类似于不关闭SSL的解决方案。

1：直接从_Support Escalation Engineer_收到指示，这些指示来自：客户服务和支持/ Microsoft Azure技术支持/ Azure容器团队-EMEA-

我喜欢这里的透明性以及MS的出色沟通。 ‍♂

@ palma21如果您对此问题有任何更新，可以请分享一下吗？ 谢谢 ：）

最好对此进行更新

我们是否对此有任何解决方案，或者仅启用了RBAC的AKS集群租户仅需要进行黑客攻击？

我们可以跟踪以解决此问题的积压项目名称是什么？

作为个人，我可以通过工作与一些Microsoft专家交谈的最新消息（来自一位未具名的Microsoft Architect K8s Advisor Expert-不是标题，是对标题的描述）， Dashboard Plugin本质上是不安全的并且不应该使用。

我同意这一说法，我想请所有未来来这里问同样问题的人通读/构建K8的能力，以了解此类插件带来的安全风险/问题。

（仅获得具有旋钮和转盘的Web UI的好处，而不仅仅是使用完美可行的CLI工具-其中，越来越多的K8作为标准添加到K8中，例如kustomize ）。

这可以通过https://github.com/pusher/oauth2_proxy来完成

@pierluigilenoci

这可以通过https://github.com/pusher/oauth2_proxy来完成

你好
您能否链接或共享一个可行的示例，其中包括用于仪表板入口的yaml，用于oauth2_proxy的values.yaml以及用于Azure AD应用程序的任何适用设置？
我一直在尝试让oauth2_proxy与Azure AD一起使用几天，但是找不到一个完整的可行示例来详细说明如何配置它，而尝试各种标志和设置仅此而已，但是还不够。
非常感谢！

@edemen我的提示：

• 不要使用默认的AKS仪表板，请使用头盔单独安装（v1.10.1）
  掌舵价值观
  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;
• 使用头盔安装oauth2_proxy https://github.com/helm/charts/blob/master/stable/oauth2-proxy
• 掌舵价值观
  extraArgs: provider: "azure" azure-tenant: "yourvalues" whitelist-domain: "yourvalues" cookie-domain: "yourvalues" set-authorization-header: "true"
  和
  ingress: enabled: true path: /oauth2

这应该足够了。

@pierluigilenoci
感谢您的回复。
我已经设法使Azure AD和oauth2代理今天开始工作，但是我发现许多设置最终都因由login.live.com返回的错误400而导致的错误500导致（更多详细信息请参见https://github.com/oauth2- proxy / oauth2-proxy / issues / 458）
本质上，如果我使用set-authorization-header: "true" ，则使用oauth2代理进行身份验证将完全停止与Azure合作。 试图找出原因，但到目前为止没有。
以防万一，我正在用helm install oauth2-proxy stable/oauth2-proxy -n oauth2-proxy --values oauth2-proxy-values.yaml安装oauth2代理

没关系。 显然，Dashboard v1.10.1甚至无法在我们拥有的Kubernetes 1.16上运行。
谢谢

我无法让开箱即用的Kubernetes仪表板与AKS配合使用，但我没有运气，但我必须承认，我并没有花很多时间在上面。 似乎有效的解决方案（时间将显示所有问题）是将标准仪表板与kubectl proxy并上传本地用户kubeconfig。

这是一个多步骤的过程，不像简单的URL一样容易/很好，但是似乎是使用在AD用户上下文下运行的仪表板的最佳方法。 我仍在关注更清洁的方法，该方法不需要对仪表板本身进行大量自定义，但仍使用Azure AD。

@edemen当然仅适用于<1.15的K8。 我认为，对于K8s 1.16，您需要等到新v2.0仪表板的正式发布。

Dashboard v2已启动https://github.com/kubernetes/dashboard/releases/tag/v2.0.0 。 但是它似乎对k8s 1.16有部分支持。

@SayakMukhopadhyay完全支持

感谢您的反馈！

该文章最近已更新，其中包含有关登录Kubernetes仪表板的详细信息。

请关闭