@Sudharmaは、私たちがよりよく支援できるように、あなたが参照しているドキュメントを共有できますか？

これですか？

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

@ MicahMcKittrick-MSFT私はこれを通り抜けており、正常に動作しています。 私はこれを参照しています
https://docs.microsoft.com/en-us/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これが遅れてすみません。 これを再現しようとしていますが、内部サブスクリプションを使用してRBACクラスターをセットアップする際に問題が発生しました。 私たちは皆見ていて、可能な限りすぐに更新します

@iainfouldsはお詫びしますが、これを正確にテストするための環境設定を取得できませんでした。 何らかの理由で、RBAC対応クラスターが個人サブスクリプションでも正しくプロビジョニングされていません。 私はこれを何日も運がないまま試してきました。 これも再現してみませんか？ 運が悪いだけです。

CC @ Karishma-Tiwari-MSFT @ jakaruna-再現も試すことができる場合はMSFT

@Sudharmaこれが遅れてすみません。 これを再現しようとしていますが、内部サブスクリプションを使用してRBACクラスターをセットアップする際に問題が発生しました。 私たちは皆見ていて、可能な限りすぐに更新します

問題ない。 しかし、私はこの解決策に熱心なので、私を最新の状態に保ってください

それは私にも同じ問題です。 ダッシュボードのログインプロンプトも、ログイン画面から発行されたトークンを渡さないようです。 それでも、サービスアカウントを介してダッシュボード接続要求を処理します。

また、サービスアカウントが作成する特権昇格のため、ダッシュボードにサービスアカウントへのアクセスを許可していません。

つまり、プロキシを介したダッシュボードアクセスは、サービスアカウントでは適切に機能しますが、OpenID接続アカウントトークンでは機能しません。

この問題は私たちにとっても問題のままです。 これが私の+1です

ここでも+1、

こんにちはチーム、

動作方法とネイティブKubernetesエンジンとの違いについて詳しく教えていただけますか。 同じことをサポートできるかどうか疑問に思っています。 また、プロキシサービスを介してAzureADを使用するようにダッシュボードを構成できるかどうか疑問に思っていますか？

誰かがこれに関する更新を持っていますか？ 「kubectlproxy」を実行した後、トークンをプルするかkube設定ファイルを使用するとアクセスできますが、az aks browserを実行すると、デバイスコードを使用してWeb経由でログインするように求められます（すでにazログインを実行しています） 、コードを入力すると、コマンド行「Oauthトークン：不明なエラー」でエラーが発生します。 Rbacを使用してクラスターをセットアップしました（クライアントとサーバーアプリの登録を使用し、（https://docs.microsoft.com/en-us/azure/aks/aad-integration）に従ってアクセス許可を設定しました。

よくわからないのは、クライアント、サーバー、サービスプリンシパルのアプリ登録を使用したため、合計3つのアプリ登録を使用したことだけです。 テラフォームを介してプロビジョニングされました。 ガイドドキュメントには、クライアントアプリとサーバーアプリの登録の権限についてのみ記載されています。

誰かが助けてくれることを願っています

まだ同じ問題に直面しています。 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またはダッシュボードには、クラスター管理者からのみアクセスできます。 もちろん、すべてのユーザーにクラスター管理者の資格情報を与えることはできません。

申し訳ありませんが、ここで問題が発生しています。

エンジニアリングチームは問題を特定し、これを解決するために取り組んでいます。 これは、AKSの特定の動作ではなく、根本的なKubernetesダッシュボードの変更のようです。 @ 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」のロールバインディングがありません。 クラスター管理者アカウントトークンを試してみました。 クラスタ管理者であり、適切なRBACが設定されているにもかかわらず、AADアカウントでログインをまったく機能させられないようです。以下のコマンドで生成されたトークンは、ベアラトークンログインに有効ですか？

• 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
Args：
--authentication-mode = token
--enable-insecure-login
状態：実行中
開始日：2019年4月25日木曜日12:04:43 +0100

このメッセージは、clusterAdminロールにその名前空間の構成マップを一覧表示する権限がないことを示しています。 それをユーザーの役割に追加して、それが解決するかどうかを確認してみてください。
それ以外の場合は、ClusterAdminロールyamlとダッシュボードデプロイメントyamlを送信してください。確認できます。

（デフォルトのダッシュボードではなく）サービスアカウントで再試行したところ、機能しているようです。これはすばらしいことです。 ただし、cluster-adminロールバインディングを持つAADユーザーのトークンを使用すると、ログインに失敗します。 正しいRBACでAADを使用すると、トークンを使用してダッシュボードにログインし、RBACバインディングで定義されているダッシュボードの特権レベルを受け取ることができますか？

はい、そうすべきです。 k8sダッシュボードへのトークンを取得しているユーザーのデフォルトNSに設定マップを一覧表示できますか？ ユーザーでそのアクションを実行できる場合は、それが期待されます。そうでない場合は、ダッシュボードに渡すトークンを確認してください。

解決されたように見えるこのスレッドのスパムを回避するには、jpalma [at] 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実際にタイムリーンを提供していただけませんか？
引用：

@ 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日に最初に発行されました。これは、このバグが公開されるまでに長い時間です。

この変更は、6月末頃に行う必要があります。

@ palma21 6月が過ぎましたが、この修正を展開するためのETAはありますか？

新しいドキュメント（上記で気付いた）を含めてロールアウトしましたが、新しいブラウザーの動作とバグのためにロールバックする必要がありました。

現在、今月末までに修正するための修正に取り組んでいます。

当面の間、この機能を有効にするための回避策があります。
で展開を編集する
args：["-authentication-mode = token"、 "--enable-insecure-login"]

上記のエラーは構文またはエディターの問題のようです。再テストしたところ、まだ機能しています。

このバグに関する更新はありますか？

同じ問題に直面して、これとそれが修正されるETAに関する更新はありますか？

おやおや、このようなバグがあることを見つけるために、AKSを使用してフルスタックソリューションを展開するのに数か月を費やしているMicrosoft製品に賭けるのは本当に残念です。

この問題をスパムとしても-それはマイクロソフト¹ @上で、私の雇用者のサポートスタッフが何を私に言ったものだと見て。

SSLをオフにする必要がないソリューションが非常に必要です。

1：_サポートエスカレーションエンジニア_から個人的かつ直接に指示を受けました。カスタマーサービスとサポート/ MicrosoftAzureテクニカルサポート/ Azureコンテナチーム-EMEA-

ここの透明性とMSからの素晴らしいコミュニケーションが大好きです。 🤦‍♂

@ palma21この問題に関する最新情報があれば、共有していただけますか？ ありがとう:)

これに関する最新情報を入手するとよいでしょう

これに対する修正はありますか、それともRBAC対応のAKSクラスターテナントはハックのみを実行する必要がありますか？

この問題を解決するために追跡できるバックログアイテム名は何ですか？

私が仕事を通じてマイクロソフトの専門家と話をする個人として共有できる最新のニュースは、ダッシュボードプラグインが本質的に安全ではないということです（名前のないマイクロソフトアーキテクトK8sアドバイザーエキスパートから-それはタイトルではなく、そのタイトルの説明です）使用しないでください。

私はその声明に同意します。この同じ質問をする将来のすべての人に、K8sで読み通し/能力を構築して、そのようなプラグインがもたらすセキュリティリスク/懸念を理解してもらいたいと思います。

（完全に機能するCLIツールを使用するのではなく、ノブとダイヤルを備えたWeb UIを使用するだけで、 kustomizeなどの標準としてK8に追加されるものが増えてい

これはhttps://github.com/pusher/oauth2_proxyで実行できます

@pierluigilenoci

これはhttps://github.com/pusher/oauth2_proxyで実行できます

こんにちは
ダッシュボード入力用のyaml、oauth2_proxy用のvalues.yaml、およびAzure ADアプリケーションに適用可能な設定を含む実行可能な例をリンクまたは共有していただけますか？
私はoauth2_proxyをAzureADで動作させるように数日間試みてきましたが、これを構成するための十分な詳細を説明する完全に実行可能な例を1つ見つけることができず、さまざまなフラグと設定を試してみると、これまでのところしか得られませんでした。十分ではありません。
本当にありがたいです！

@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;
• ヘルムhttps://github.com/helm/charts/blob/master/stable/oauth2-proxyで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プロキシをインストールしています

気にしないで。 どうやらDashboardv1.10.1は、私たちが持っているKubernetes1.16でも動作しません。
ありがとうございました

すぐに使用できるKubernetesダッシュボードをAKSで動作させることができませんでしたが、作業に多くの時間を費やしていなかったことを認めなければなりません。 動作しているように見える解決策（時間があれば問題が表示されます）は、 kubectl proxy標準ダッシュボードを使用し、ローカルユーザーkubeconfigをアップロードすることです。

これは複数のステップからなるプロセスであり、単純なURLほど簡単ではありませんが、ADユーザーのコンテキストで実行されているダッシュボードを使用するための最良の方法のようです。 ダッシュボード自体をあまりカスタマイズする必要がなく、Azure ADを使用する、よりクリーンなアプローチに引き続き目を光らせています。

@edemenもちろん、これはK8s <1.15でのみ機能します。 K8s 1.16の場合、新しいv2.0ダッシュボードが公式にリリースされるまで待つ必要があると思います。

ダッシュボードv2はhttps://github.com/kubernetes/dashboard/releases/tag/v2.0.0を起動しました。 ただし、k8s1.16は部分的にサポートされているようです

@SayakMukhopadhyayバージョンv2.0.0-rc3までは完全にサポートされていました。 私はバージョン1.15と1.16の最新のRCを使用し、かなりうまく機能しました。 どの操作を行う必要があるかはわかりませんが、通常の使用量の99,99％が確実にカバーされています。

フィードバックありがとうございます！

この記事は最近更新され、Kubernetesダッシュボードへのサインインの詳細が追加されました。

閉じてください