@Sudharma Können Sie das Dokument, auf das Sie sich beziehen,

Ist es dieses?

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

@ MicahMcKittrick-MSFT Ich bin durch und es funktioniert gut. Ich beziehe mich auf diesen
https://docs.microsoft.com/en-us/azure/aks/kubernetes-dashboard#for -rbac-enabled-cluster
genau mit dem RBAC für Dashboard.

You can also integrate Azure Active Directory authentication to provide a more granular level of access. Mehr interessiert, wie das geht.!

@ Sudharma danke dafür!

@iainfoulds @seanmck könnte einer von euch diese Frage weiter kommentieren?

@ Sudharma Entschuldigung für die Verzögerung. Ich habe versucht, dies zu wiederholen, hatte jedoch Probleme beim Abrufen eines RBAC-Cluster-Setups mit meinem internen Abonnement. Wir alle schauen uns das an und werden es aktualisieren, sobald es möglich ist

@iainfoulds aplogies, aber ich konnte meine Umgebung nicht einrichten, um dies genau zu testen. Aus irgendeinem Grund wird mein RBAC-fähiger Cluster selbst in meinem persönlichen Abonnement nicht ordnungsgemäß bereitgestellt. Ich habe das seit Tagen ohne Glück versucht. Könnten Sie versuchen, dies auch zu wiederholen? Ich habe einfach kein Glück.

CC @ Karishma-Tiwari-MSFT @ jakaruna-MSFT, wenn sie auch einen Repro versuchen können

@ Sudharma Entschuldigung für die Verzögerung. Ich habe versucht, dies zu wiederholen, hatte jedoch Probleme beim Abrufen eines RBAC-Cluster-Setups mit meinem internen Abonnement. Wir alle schauen uns das an und werden es aktualisieren, sobald es möglich ist

Kein Problem. Bitte halten Sie mich jedoch auf dem Laufenden, da ich auf diese Lösung gespannt bin

Das ist auch bei mir so. Ich sehe, dass auch die Dashboard-Anmeldeaufforderung das über den Anmeldebildschirm ausgegebene Token nicht weitergibt. Die Dashboard-Verbindungsanforderungen werden weiterhin über das Dienstkonto behandelt.

Außerdem habe ich dem Dashboard keinen Zugriff auf das Dienstkonto gewährt, da dadurch eine Berechtigungseskalation erstellt wird.

Kurz gesagt, der Dashboard-Zugriff über einen Proxy funktioniert gut mit dem Dienstkonto, jedoch nicht mit dem OpenID Connect-Kontotoken.

Dieses Problem bleibt auch für uns ein Problem. Also hier ist meine +1

+1 auch hier,

Hallo Team,

Könnten Sie mehr Details darüber liefern, wie es funktioniert und was sich von der nativen Kubernetes-Engine unterscheidet? Ich frage mich, ob wir das auch unterstützen könnten. Sie fragen sich auch, ob das Dashboard für die Verwendung von Azure AD über einen Proxy-Dienst konfiguriert werden kann?

Hat jemand ein Update dazu? Ich kann zugreifen, wenn ich das Token ziehe oder die kube-Konfigurationsdatei verwende, nachdem ich "kubectl proxy" ausgeführt habe. Wenn ich jedoch az aks browse ausführe, werde ich aufgefordert, mich über das Web mit einem Gerätecode anzumelden (obwohl ich mich bereits angemeldet habe) Die Eingabe des Codes führt mich zu einem Fehler in der cmd-Zeile "Oauth-Token: Unbekannter Fehler". Ich habe den Cluster mit Rbac eingerichtet (mit Client- und Server-App-Registrierungen und den Berechtigungen gemäß (https://docs.microsoft.com/en-us/azure/aks/aad-integration).

Das einzige, bei dem ich mir nicht sicher bin, ist, dass ich eine App-Registrierung für den Client, den Server und den Service-Principal verwendet habe, also insgesamt 3 App-Registrierungen. Es wurde über Terraform bereitgestellt. In der Anleitung werden nur die Berechtigungen für die Client- und Server-App-Registrierungen erwähnt.

Hoffe jemand kann helfen

Immer noch vor dem gleichen Problem. Zugriff auf Dashboard, API oder Kubectl über AD-Konten nicht möglich

Der folgende Befehl funktioniert. Dadurch werden k8s-Administratoranmeldeinformationen für /home/user/.kube/config erstellt
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev --admin

Nach dem Hinzufügen der Clusterrollenbindung mit AD-Benutzer oder -Gruppe können sich Benutzer normalerweise mit unten anmelden
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev

Dadurch werden Sie zum Gerätetoken aufgefordert, und Benutzer können sich anmelden. Aber jetzt scheitert dies konsequent.
Auf Kubectl oder Dashboard kann nur über den Cluster-Administrator zugegriffen werden. Offensichtlich können wir nicht allen Benutzern Cluster-Administrator-Creds geben.

Tut mir leid, dass hier Leute auf Probleme stoßen.

Das Engineering-Team hat ein Problem identifiziert und arbeitet daran, dieses zu beheben. Es scheint sich eher um eine zugrunde liegende Änderung des Kubernetes-Dashboards als um ein spezifisches Verhalten in AKS zu handeln. @ palma21 kann zusätzlichen Kontext auf Zeitleisten für die Auflösung bereitstellen.

Das @ spbreed- Problem scheint anders zu sein, da er erwähnt, dass auch über kubectl kein Zugriff möglich ist (überprüfen Sie, ob Ihre Geheimnisse nicht abgelaufen sind, und öffnen Sie ein Support-Ticket, damit wir Ihren Cluster und Ihre Hilfe überprüfen können).

Für den Rest, der ausschließlich Probleme mit dem Dashboard hat, erfordern die neueren Versionen des Dashboards https oder das unsichere Anmeldeflag, oder sie fallen unter die Anmeldung des Dienstkontos.

Um dies zu erzwingen, können Sie Ihre Dashboard-Bereitstellung bearbeiten
z.B.
kubectl edit deploy -n kube-system kubernetes-dashboard

Und ergänzen Sie Ihre Containerspezifikation.

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

In Zukunft werden wir die Tokenauthentifizierung erzwingen, Port 9090 in 8443 ändern, das Schema in HTTPS umwandeln und selbstsignierte Zertifikate verwenden. Dies wird in Kürze veröffentlicht und in unseren Versionshinweisen bekannt gegeben.
https://github.com/Azure/aks/releases

Vor dem gleichen Problem. Zugriff auf Dashboard, API oder Kubectl über AD-Konten nicht möglich.

Mein Fehler: Ich kann nicht über AD-Konten auf das K8S-Dashboard zugreifen.

Welchen Prozess verfolgen Sie, um auf das Dashboard zuzugreifen? Hast du meinen Kommentar oben ausprobiert?

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

@ palma21 Ich habe gerade Ihren Vorschlag ausprobiert und Fehlerliste, wenn ich mich beim Dashboard

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

configmaps ist verboten: Benutzer "clusterAdmin" kann configmaps nicht im Namespace "default" auflisten.

Ich habe keine Rollenbindung für das Dienstkonto 'kubernetes-dashboard'. Ich habe es mit dem Cluster-Administratorkonto-Token versucht. Ich kann nicht scheinen, dass die Anmeldung mit meinem AAD-Konto überhaupt funktioniert, obwohl es sich um einen Cluster-Administrator handelt und wir über einen entsprechenden RBAC verfügen. Ist das mit dem folgenden Befehl generierte Token für die Anmeldung des Inhaber-Tokens gültig?

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

Ausschnitt aus Pod-Details:

Behälter:
Main:
Container-ID: Docker: // 610c6b258cde01196c03c918c3acca6c3c6ba531153ad1b7e0f034e032065319
Bild: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
Bild-ID: Docker-Pullable : //k8s.gcr.io/kubernetes-dashboard-amd64@sha256 : 0ae6b69432e78069c5ce2bcde0fe409c5c4d6f0f4d9cd50a17974fea38898747
Port: 9090 / TCP
Host-Port: 0 / TCP
Argumente:
--authentication-mode = Token
--enable-unsicher-Login
Status: Laufen
Gestartet: Do, 25. April 2019, 12:04:43 +0100

Diese Nachricht gibt an, dass Ihre ClusterAdmin-Rolle nicht über Berechtigungen zum Auflisten von Konfigurationszuordnungen in diesem Namespace verfügt. Könnten Sie versuchen, dies zur Rolle Ihres Benutzers hinzuzufügen und zu prüfen, ob dies das Problem löst?
Andernfalls senden Sie bitte Ihre ClusterAdmin-Rolle yaml und Dashboard Deployment yaml und ich kann einen Blick darauf werfen.

Ich habe es gerade noch einmal mit einem Dienstkonto versucht (nicht mit dem Standard-Dashboard) und es scheint zu funktionieren, was großartig ist. Die Verwendung eines Tokens eines AAD-Benutzers mit Cluster-Administrator-Rollenbindung schlägt jedoch fehl. Sollte eine AAD-Verwendung mit korrektem RBAC in der Lage sein, sich mit einem Token beim Dashboard anzumelden und die in ihrer RBAC-Bindung definierte Berechtigungsstufe im Dashboard zu erhalten?

Ja sollte es. Können Sie Konfigurationszuordnungen auf dem Standard-NS mit dem Benutzer auflisten, für den Sie das Token für das k8s-Dashboard erhalten? Wenn Sie diese Aktion mit dem Benutzer ausführen können, wird dies erwartet. Andernfalls würde ich sagen, überprüfen Sie, welches Token Sie an das Dashboard übergeben.

Um zu vermeiden, dass dieser Thread, der behoben erscheint, als Spam versendet wird, senden Sie mir bitte eine E-Mail an jpalma [at] microsoft.com

Um dies zu erzwingen, können Sie Ihre Dashboard-Bereitstellung bearbeiten
z.B.
kubectl edit deploy -n kube-system kubernetes-dashboard

Und ergänzen Sie Ihre Containerspezifikation.

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

In Zukunft werden wir die Tokenauthentifizierung erzwingen, Port 9090 in 8443 ändern, das Schema in HTTPS umwandeln und selbstsignierte Zertifikate verwenden. Dies wird in Kürze veröffentlicht und in unseren Versionshinweisen bekannt gegeben.
https://github.com/Azure/aks/releases

Ihr habt Zeitpläne versprochen, im Moment gibt es keine Lösung und wir verwenden wieder diese unsichere Lösung. Die Ausgabe ist seit langem offen, während gleichzeitig andere Dinge behandelt werden . Können Sie uns echte Zeitpläne geben?

@iainfoulds Kannst du bitte tatsächlich Zeitangaben machen?
Zitat:

@ palma21 kann zusätzlichen Kontext auf Zeitleisten für die Auflösung bereitstellen.

@ palma21 Im Moment ist die Lösung
Fehler: Bereitstellungen "kubernetes-dashboard" ist ungültig

In Zukunft werden wir die Tokenauthentifizierung erzwingen und Port 9090 in 8443 ändern, Schema in HTTPS
Wann???

Wenn das Bereitstellungsmanifest ungültig ist, liegt wahrscheinlich ein Syntax- oder Einrückungsproblem vor. Ich habe es einfach wieder gemacht und es funktioniert.
Versuchen Sie es mit einer Inline
args: ["--authentication-mode=token", "--enable-insecure-login"]

Wir sollten diese Änderung gegen Ende Juni haben.

Dies ist, was ich basierend auf @ palma21- Notizen
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.

Ich habe es versucht:
kubectl edit deploy -n kube-system kubernetes-dashboard
mit dem neuesten AKS, der am 12.09.2019 bereitgestellt wurde.
Der geöffnete Editor wurde mit einer Yaml-Datei gefüllt, aber beim Speichern und Schließen wurde folgende Fehlermeldung angezeigt:

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

Irgendwelche Ideen?

Dies scheint ein ziemlich großer Fehler zu sein. Soweit ich weiß, können Sie keine AAD-Anmeldungen verwenden, um auf das Kubernetes-Dashboard zuzugreifen.

Schlimmer noch, die Dokumentation ist falsch, da dies impliziert, dass Sie:

Beim Einrichten der Authentifizierung für das Kubernetes-Dashboard wird empfohlen, ein Token über dem Standard-Dashboard-Dienstkonto zu verwenden. Mit einem Token kann jeder Benutzer seine eigenen Berechtigungen verwenden. Durch die Verwendung des Standard-Dashboard-Dienstkontos kann ein Benutzer möglicherweise seine eigenen Berechtigungen umgehen und stattdessen das Dienstkonto verwenden.

Beim Lesen dieses Threads ist dies kaputt. Kann dieser Fehler entweder behoben oder zumindest die Dokumentation aktualisiert werden, um zu verdeutlichen, dass dies derzeit nicht möglich ist?

Dieses Ticket wurde zum ersten Mal am 30. Januar ausgestellt, das ist eine lange Zeit, bis dieser Fehler offen ist.

Wir sollten diese Änderung gegen Ende Juni haben.

@ palma21 Der Juni ist vorbei. Fixes ?

Wir haben es eingeführt, einschließlich neuer Dokumente (die Sie oben bemerkt haben), mussten es jedoch aufgrund des neuen Browserverhaltens und eines Fehlers zurücksetzen.

Wir arbeiten derzeit an einer Lösung, die bis Ende dieses Monats vorliegen soll.

Es gibt eine Problemumgehung, um diese Funktionalität in der Zwischenzeit zu aktivieren
Bearbeiten der Bereitstellung mit
Argumente: ["--authentication-mode = token", "--enable-unsicheres Login"]

Ihr Fehler oben scheint ein Syntax- oder Editorproblem zu sein. Ich habe ihn gerade erneut getestet und er funktioniert immer noch.

Gibt es Updates zu diesem Fehler?

Gibt es angesichts des gleichen Problems ein Update zu diesem Thema und eine ETA, mit der es behoben wird?

Meine Güte, es ist wirklich enttäuschend, auf Microsoft-Produkte zu wetten, die ein paar Monate damit verbringen, eine Full-Stack-Lösung mithilfe ihrer AKS bereitzustellen, um herauszufinden, dass es einen solchen Fehler gibt.

Auch dieses Problem zu spammen - da mir die Support-Mitarbeiter meines Arbeitgebers über @ Microsoft ¹ dies befohlen haben.

Möchte sehr gerne eine Lösung, die nicht das Deaktivieren von SSL beinhaltet.

1: Persönliche und direkte Anweisungen von einem _Support Escalation Engineer_ erhalten von: Kundendienst und Support / Technischer Support von Microsoft Azure / Azure Containers Team - EMEA -

Ich liebe die Transparenz hier und die großartige Kommunikation von MS. 🤦‍♂

@ palma21 Kannst du uns bitte

Es wäre gut, ein Update dazu zu bekommen

Haben wir eine Lösung für dieses oder das nur RBAC-fähige AKS-Cluster-Mandanten, das nur Hacks durchlaufen muss?

Wie lautet der Name des Backlog-Elements, den wir verfolgen können, um dieses Problem zu beheben?

Die neuesten Nachrichten, die ich als Privatperson, die durch Arbeit mit einigen Microsoft-Experten sprechen, teilen kann, sind (von einem nicht genannten Microsoft Architect K8s Advisor-Experten - das ist nicht der Titel, es ist eine Beschreibung dieses Titels), dass das Dashboard-Plugin von Natur aus unsicher ist und sollte nicht verwendet werden.

Ich stimme dieser Aussage zu und würde alle zukünftigen Leute, die hierher kommen und dieselbe Frage stellen, bitten, die Kompetenz in K8s durchzulesen / aufzubauen, um die Sicherheitsrisiken / -bedenken zu verstehen, die ein solches Plugin mit sich bringt.

(Für den bloßen Vorteil, eine Web-Benutzeroberfläche mit Knöpfen und Wählscheiben zu haben, anstatt nur die perfekt funktionierenden CLI-Tools zu verwenden, zu denen K8s standardmäßig immer mehr hinzugefügt werden, z. B. kustomize ).

Dies ist mit https://github.com/pusher/oauth2_proxy möglich

@pierluigilenoci

Dies ist mit https://github.com/pusher/oauth2_proxy möglich

Hallo
Könnten Sie bitte ein funktionsfähiges Beispiel verknüpfen oder freigeben, das ein yaml für einen Dashboard-Eingang, values.yaml für oauth2_proxy und alle anwendbaren Einstellungen für eine Azure AD-Anwendung enthält?
Ich habe mehrere Tage lang versucht, oauth2_proxy dazu zu bringen, mit Azure AD zu arbeiten, aber ich kann kein einziges voll funktionsfähiges Beispiel finden, das ausführlich genug auf die Konfiguration dieses Beispiels eingeht, und das Experimentieren mit verschiedenen Flags und Einstellungen hat mich bisher nur dazu gebracht nicht weit genug.
Würde es wirklich schätzen!

@edemen meine Tipps:

• Verwenden Sie nicht das Standard-AKS-Dashboard, sondern installieren Sie es separat (v1.10.1) mit Helm
  Werte für das Ruder
  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;
• Installieren Sie oauth2_proxy mit dem Helm https://github.com/helm/charts/blob/master/stable/oauth2-proxy
• Werte für das Ruder
  extraArgs: provider: "azure" azure-tenant: "yourvalues" whitelist-domain: "yourvalues" cookie-domain: "yourvalues" set-authorization-header: "true"
  und
  ingress: enabled: true path: /oauth2

Das sollte reichen.

@pierluigilenoci
Vielen Dank für Ihre Antwort.
Ich habe es heute geschafft, Azure AD und oauth2-Proxy zum Laufen zu bringen, aber ich stelle fest, dass viele Einstellungen in Fehler 500 enden, der durch den von login.live.com zurückgegebenen Fehler 400 verursacht wird (weitere Details unter https://github.com/oauth2- Proxy / oauth2-Proxy / Issues / 458)
Wenn ich set-authorization-header: "true" , funktioniert die Authentifizierung mit dem oauth2-Proxy im Wesentlichen überhaupt nicht mehr mit Azure. Ich versuche herauszufinden warum, aber bisher nichts.
Nur für den Fall, ich installiere oauth2 Proxy mit helm install oauth2-proxy stable/oauth2-proxy -n oauth2-proxy --values oauth2-proxy-values.yaml

Keine Ursache. Anscheinend funktioniert Dashboard v1.10.1 nicht einmal mit Kubernetes 1.16, das wir haben.
Vielen Dank

Ich hatte kein Glück damit, dass das sofort einsatzbereite Kubernetes-Dashboard mit AKS funktioniert, aber ich muss zugeben, dass ich nicht viel Zeit damit verbracht habe, daran zu arbeiten. Die Lösung, die anscheinend funktioniert (die Zeit zeigt alle Probleme), besteht darin, das Standard-Dashboard mit kubectl proxy und die lokale Benutzer-Kubeconfig hochzuladen.

Es ist ein mehrstufiger Prozess, der nicht so einfach / nett wie eine einfache URL ist, aber der beste Weg zu sein scheint, das Dashboard zu verwenden, das im Kontext der AD-Benutzer ausgeführt wird. Ich halte immer noch Ausschau nach einem saubereren Ansatz, der keine großen Anpassungen des Dashboards selbst erfordert und dennoch Azure AD verwendet.

@edemen das funktioniert natürlich nur für K8s <1.15. Für K8s 1.16 müssen Sie vermutlich bis zur offiziellen Veröffentlichung des neuen v2.0-Dashboards warten.

Dashboard v2 hat https://github.com/kubernetes/dashboard/releases/tag/v2.0.0 gestartet. Aber es scheint teilweise Unterstützung für k8s 1.16 zu haben

@SayakMukhopadhyay bis zur Version v2.0.0-rc3 wurde es voll unterstützt. Ich habe den neuesten RC mit den Versionen 1.15 und 1.16 verwendet und ziemlich gut gearbeitet. Ich weiß nicht, welchen Vorgang Sie ausführen müssen, aber 99,99% der normalen Nutzung sind sicher abgedeckt.

Danke für die Bewertung!

Der Artikel wurde kürzlich mit Details zur Anmeldung beim Kubernetes-Dashboard aktualisiert.

Bitte schließe