@Sudharma pouvez-vous partager le document

Est-ce celui-ci?

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

@ MicahMcKittrick-MSFT Je suis à travers cela et cela fonctionne très bien. Je fais référence à celui-ci
https://docs.microsoft.com/en-us/azure/aks/kubernetes-dashboard#for -rbac-enabled-clusters
précisément avec le RBAC pour tableau de bord.

You can also integrate Azure Active Directory authentication to provide a more granular level of access. Plus intéressé par la façon de procéder.!

@Sudharma merci pour ça!

@iainfoulds @seanmck pourriez-vous commenter davantage cette question?

@Sudharma désolé pour le retard à ce sujet. J'ai essayé de reproduire cela mais j'ai eu des problèmes pour obtenir une configuration de cluster RBAC en utilisant mon abonnement interne. Nous examinons tous et mettrons à jour dès que possible

@iainfoulds aplogies mais je n'ai pas été en mesure de configurer mon environnement pour tester cela avec précision. Pour une raison quelconque, mon cluster activé RBAC ne se provisionne pas correctement, même sur mon abonnement personnel. J'essaye ceci depuis des jours sans aucune chance. Pourriez-vous essayer de reproduire cela également? Je n'ai tout simplement pas de chance.

CC @ Karishma-Tiwari-MSFT @ jakaruna-MSFT s'ils peuvent également essayer une reproduction

@Sudharma désolé pour le retard à ce sujet. J'ai essayé de reproduire cela mais j'ai eu des problèmes pour obtenir une configuration de cluster RBAC en utilisant mon abonnement interne. Nous examinons tous et mettrons à jour dès que possible

Aucun problème. Cependant, veuillez me tenir au courant car je suis impatient de cette solution

C'est le même problème avec moi aussi. Je vois que l'invite de connexion au tableau de bord ne transmet pas non plus le jeton émis via l'écran de connexion. Il traite toujours les demandes de connexion au tableau de bord via le compte de service.

De plus, je n'ai pas donné accès au tableau de bord au compte de service, en raison de l'élévation de privilèges qu'il crée.

En bref, l'accès au tableau de bord via un proxy fonctionne bien avec le compte de service, mais pas avec le jeton de compte OpenID connect.

Cette question reste également un problème pour nous. Alors voici mon +1

+1 ici aussi,

Bonjour l'équipe,

Seriez-vous en mesure de fournir plus de détails sur son fonctionnement et ce qui est différent du moteur Kubernetes natif. Je me demande si nous pourrions apporter un soutien pour la même chose. Vous vous demandez également si le tableau de bord peut être configuré pour utiliser Azure AD via un service proxy?

Quelqu'un a une mise à jour à ce sujet? Je peux accéder si je tire le jeton ou utilise le fichier de configuration kube après avoir exécuté "kubectl proxy", mais si je lance az aks parcourir, on me demande de me connecter via le Web (même si j'ai déjà fait une connexion az) avec un code d'appareil , la saisie du code me conduit à une erreur sur la ligne cmd "Oauth token: Unknown Error". J'ai configuré le cluster avec Rbac (avec les inscriptions des applications client et serveur et défini les autorisations selon (https://docs.microsoft.com/en-us/azure/aks/aad-integration).

La seule chose dont je ne suis pas sûr, c'est que j'ai utilisé un enregistrement d'application pour le client, le serveur et le principal du service, donc 3 enregistrements d'application au total. Il a été provisionné via terraform. Le document du guide ne mentionne que les autorisations pour les enregistrements des applications client et serveur.

J'espère que quelqu'un peut aider

Toujours confronté au même problème. Impossible d'accéder au tableau de bord, à l'API ou à kubectl à l'aide de comptes AD

La commande ci-dessous fonctionne, cela crée des informations d'identification d'administrateur k8s vers /home/user/.kube/config
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev --admin

Après avoir ajouté la liaison de rôle de cluster avec l'utilisateur ou le groupe AD, généralement, les utilisateurs peuvent se connecter avec ci-dessous
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev

Cela demandera un jeton d'appareil et les utilisateurs pourront se connecter. Mais maintenant, cela échoue systématiquement.
Kubectl ou le tableau de bord n'est accessible que via l'administrateur du cluster. De toute évidence, nous ne pouvons pas donner de crédits d'administrateur de cluster à tous les utilisateurs.

Désolé, les gens rencontrent des problèmes ici.

L'équipe d'ingénierie a identifié un problème et s'efforce de le résoudre. Cela semble être un changement sous-jacent du tableau de bord Kubernetes plutôt qu'un comportement spécifique dans AKS. @ palma21 peut fournir un contexte supplémentaire sur les délais de résolution.

Le problème de

Pour les autres qui rencontrent des problèmes exclusivement avec le tableau de bord, les versions plus récentes du tableau de bord nécessitent https ou l'indicateur de connexion non sécurisée ou elles tomberont dans la connexion au compte de service.

Pour forcer cela, vous pouvez modifier le déploiement de votre tableau de bord
par exemple.
kubectl edit deploy -n kube-system kubernetes-dashboard

Et ajoutez à vos spécifications de conteneur.

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

À l'avenir, nous appliquerons l'authentification par jeton, changerons le port 9090 en 8443, le schéma en HTTPS et utiliserons des certificats auto-signés. Cela sortira bientôt et sera annoncé dans nos notes de publication.
https://github.com/Azure/aks/releases

Face au même problème. Impossible d'accéder au tableau de bord, à l'API ou à kubectl à l'aide de comptes AD.

Mon erreur: impossible d'accéder au tableau de bord K8S à l'aide de comptes AD.

Quel processus suivez-vous pour accéder au tableau de bord? Avez-vous essayé mon commentaire ci-dessus?

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

@ palma21 Je viens d'essayer votre suggestion et j'ai toujours le même problème avec la liste des erreurs lors de la connexion au tableau de bord, par exemple

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

configmaps est interdit: l'utilisateur "clusterAdmin" ne peut pas lister les configmaps dans l'espace de noms "default"

Je n'ai aucune liaison de rôle pour le compte de service «kubernetes-dashboard». J'ai essayé avec le jeton de compte d'administrateur de cluster. Je ne parviens pas à faire fonctionner la connexion avec mon compte AAD bien que ce soit un administrateur de cluster et que nous ayons le RBAC approprié en place, le jeton généré avec la commande ci-dessous est-il valide pour la connexion au jeton du porteur?

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

extrait des détails du pod:

Conteneurs:
principale:
ID du conteneur: docker: // 610c6b258cde01196c03c918c3acca6c3c6ba531153ad1b7e0f034e032065319
Image: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
ID de l'image: docker- pullable: //k8s.gcr.io/kubernetes-dashboard-amd64@sha256 : 0ae6b69432e78069c5ce2bcde0fe409c5c4d6f0f4d9cd50a17974fea38898747
Port: 9090 / TCP
Port hôte: 0 / TCP
Args:
--authentication-mode = jeton
--enable-insecure-login
État: en cours d'exécution
Démarré: jeu.25 avril 2019 12:04:43 +0100

Ce message indique que votre rôle clusterAdmin ne dispose pas des autorisations nécessaires pour répertorier les mappages de configuration sur cet espace de noms. Pourriez-vous essayer d'ajouter cela au rôle de votre utilisateur et voir si cela le résout?
Sinon, veuillez envoyer votre rôle ClusterAdmin yaml et votre déploiement de tableau de bord yaml et je peux jeter un coup d'œil.

Je viens de réessayer avec un compte de service (pas le tableau de bord par défaut) et cela semble fonctionner, ce qui est génial. Cependant, l'utilisation d'un jeton d'un utilisateur AAD avec une liaison de rôle d'administrateur de cluster échoue à se connecter. Un AAD doit-il utiliser avec RBAC correct être en mesure de se connecter au tableau de bord avec un jeton et recevoir le niveau de privilège dans le tableau de bord tel que défini dans leur liaison RBAC?

Oui ça devrait. Pouvez-vous répertorier les cartes de configuration sur le NS par défaut avec l'utilisateur à qui vous obtenez le jeton sur le tableau de bord k8s? Si vous pouvez faire cette action avec l'utilisateur, c'est normal, sinon je dirais de vérifier quel jeton vous transmettez au tableau de bord.

Pour éviter de spammer ce fil qui semble résolu, envoyez-moi un mail à jpalma [at] microsoft.com

Pour forcer cela, vous pouvez modifier le déploiement de votre tableau de bord
par exemple.
kubectl edit deploy -n kube-system kubernetes-dashboard

Et ajoutez à vos spécifications de conteneur.

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

À l'avenir, nous appliquerons l'authentification par jeton, changerons le port 9090 en 8443, le schéma en HTTPS et utiliserons des certificats auto-signés. Cela sortira bientôt et sera annoncé dans nos notes de publication.
https://github.com/Azure/aks/releases

Vous avez promis des délais, pour le moment il n'y a pas de solution et nous revenons à cette solution non sécurisée. La question est ouverte depuis longtemps alors qu'en même temps il y a d'autres choses en cours . Pouvez-vous nous donner des délais réels?

@iainfoulds Pouvez-vous s'il vous plaît fournir des timeliens ??
citant:

@ palma21 peut fournir un contexte supplémentaire sur les délais de résolution.

@ palma21 Pour le moment, la solution est loin d'être idéale, pour une raison quelconque les lignes de code ne fonctionnent pas,
erreur: les déploiements "kubernetes-dashboard" ne sont pas valides

À l'avenir, nous appliquerons l'authentification par jeton, en changeant le port 9090 en 8443, le schéma en HTTPS
Quand???

Si le manifeste de déploiement n'est pas valide, il s'agit probablement d'un problème de syntaxe ou d'indentation. Je viens de le refaire et ça marche.
Essayez avec un en ligne
args: ["--authentication-mode=token", "--enable-insecure-login"]

Nous devrions avoir ce changement vers la fin de juin.

Voici ce que j'ai fait sur la base des notes de
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.

J'ai essayé ceci:
kubectl edit deploy -n kube-system kubernetes-dashboard
avec le dernier AKS déployé à partir du 12/09/2019.
Le bloc-notes s'est ouvert rempli d'un fichier yaml, mais lorsque j'ai enregistré et fermé, j'ai reçu l'erreur:

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

Des idées?

Cela semble être un bug majeur. Si je comprends bien, vous ne pouvez pas utiliser les connexions AAD pour accéder au tableau de bord Kubernetes.

Pire encore, la documentation est fausse, car elle implique que vous pouvez:

Lors de la configuration de l'authentification pour le tableau de bord Kubernetes, il est recommandé d'utiliser un jeton sur le compte de service du tableau de bord par défaut. Un jeton permet à chaque utilisateur d'utiliser ses propres autorisations. L'utilisation du compte de service de tableau de bord par défaut peut permettre à un utilisateur de contourner ses propres autorisations et d'utiliser le compte de service à la place.

À la lecture de ce fil, c'est cassé. Ce bogue peut-il être corrigé, ou au moins la documentation mise à jour pour indiquer clairement que ce n'est actuellement pas possible?

Ce ticket a été soulevé pour la première fois le 30 janvier, ce qui est long pour que ce bug soit ouvert.

Nous devrions avoir ce changement vers la fin de juin.

@ palma21 Juin est parti, y a-t-il un ETA pour que ce correctif soit déployé?

Nous l'avons déployé, y compris de nouveaux documents (que vous avez remarqués ci-dessus), mais nous avons dû l'annuler en raison d'un nouveau comportement du navigateur et d'un bogue.

Nous travaillons actuellement sur un correctif pour l'avoir d'ici la fin du mois.

Il existe une solution de contournement pour activer cette fonctionnalité dans l'intervalle qui implique
modification du déploiement avec
args: ["--authentication-mode = token", "--enable-insecure-login"]

Votre erreur ci-dessus semble être un problème de syntaxe ou d'éditeur, je viens de refaire le test et cela fonctionne toujours.

Y a-t-il des mises à jour concernant ce bogue?

Face au même problème, y a-t-il une mise à jour à ce sujet et un ETA par lequel il sera corrigé?

Gosh, c'est vraiment décevant de parier que les produits Microsoft passent quelques mois à déployer une solution complète en utilisant leur AKS pour découvrir qu'il y a un bogue comme celui-ci ...

Spamming ce problème aussi - vu que c'est ce que le personnel de support de mon employeur sur @ Microsoft ¹ m'a dit de faire.

Voudrait beaucoup une solution qui n'implique pas de désactiver SSL.

1: A reçu des instructions personnellement et directement d'un _Support Escalation Engineer_, provenant de: Customer Service and Support / Microsoft Azure Technical Support / Azure Containers Team - EMEA -

J'adore la transparence ici et l'excellente communication de MS. 🤦‍♂

@ palma21 Pouvez-vous s'il vous plaît partager si vous avez des

Ce serait bien d'avoir une mise à jour à ce sujet

Avons-nous un correctif pour cela ou son seul locataire de cluster AKS activé RBAC doit-il passer par des hacks uniquement?

quel est le nom de l'élément de backlog que nous pouvons suivre pour voir ce problème à résoudre?

Les dernières nouvelles - que je peux partager en tant que personne privée qui par le biais de mon travail avec des experts Microsoft - sont (d'un expert Microsoft Architect K8s Advisor non nommé - ce n'est pas le titre, c'est une description dudit titre) que le plugin Dashboard est intrinsèquement dangereux et ne doit pas être utilisé.

Je suis d'accord avec cette déclaration, et je demanderais à toutes les futures personnes qui viendront ici poser cette même question de lire / développer des compétences dans K8s de comprendre les risques / préoccupations de sécurité qu'un tel plugin introduit.

(Pour le simple gain d'avoir une interface utilisateur Web avec des boutons et des cadrans au lieu d'utiliser simplement les outils CLI parfaitement fonctionnels - parmi lesquels il y a de plus en plus d'ajouts aux K8 en standard, tels que kustomize ).

Cela est faisable avec https://github.com/pusher/oauth2_proxy

@pierluigilenoci

Cela est faisable avec https://github.com/pusher/oauth2_proxy

salut
Pourriez-vous s'il vous plaît lier ou partager un exemple réalisable qui inclut un yaml pour une entrée de tableau de bord, values.yaml pour oauth2_proxy et tous les paramètres applicables pour une application Azure AD?
J'ai essayé de faire fonctionner oauth2_proxy avec Azure AD pendant plusieurs jours, mais je ne trouve pas un seul exemple exploitable complet qui entrerait suffisamment en détail sur la configuration de cela, et l'expérimentation de divers indicateurs et paramètres ne m'a amené que jusqu'à présent, mais pas assez loin.
Je l'apprécierais vraiment!

@edemen mes conseils:

• n'utilisez pas le tableau de bord AKS par défaut, installez-le séparément (v1.10.1) avec helm
  Valeurs pour la barre
  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;
• installez oauth2_proxy avec helm https://github.com/helm/charts/blob/master/stable/oauth2-proxy
• Valeurs pour la barre
  extraArgs: provider: "azure" azure-tenant: "yourvalues" whitelist-domain: "yourvalues" cookie-domain: "yourvalues" set-authorization-header: "true"
  et
  ingress: enabled: true path: /oauth2

Cela devrait suffire.

@pierluigilenoci
Merci d'avoir répondu.
J'ai réussi à faire fonctionner Azure AD et le proxy oauth2 aujourd'hui, mais je constate que de nombreux paramètres se retrouvent dans l'erreur 500 causée par l'erreur 400 renvoyée par login.live.com (plus de détails dans https://github.com/oauth2- proxy / oauth2-proxy / issues / 458)
Essentiellement, si j'utilise set-authorization-header: "true" , l'authentification avec le proxy oauth2 cesse de fonctionner du tout avec Azure. Essayer de comprendre pourquoi, mais rien pour l'instant.
Juste au cas où, j'installe le proxy oauth2 avec helm install oauth2-proxy stable/oauth2-proxy -n oauth2-proxy --values oauth2-proxy-values.yaml

Ça ne fait rien. Apparemment, Dashboard v1.10.1 ne fonctionne même pas sur Kubernetes 1.16 que nous avons.
Je vous remercie

Je n'ai pas eu de chance de faire fonctionner le tableau de bord Kubernetes prêt à l'emploi avec AKS, mais je dois admettre que je n'ai pas passé beaucoup de temps à y travailler. La solution qui semble fonctionner (le temps affichera tous les problèmes) consiste à utiliser le tableau de bord standard avec kubectl proxy et à télécharger les utilisateurs locaux kubeconfig.

C'est un processus en plusieurs étapes qui n'est pas aussi simple / agréable qu'une simple URL, mais qui semble être le meilleur moyen d'utiliser le tableau de bord exécuté dans le contexte des utilisateurs AD. Je suis toujours à l'affût d'une approche plus propre qui ne nécessite pas beaucoup de personnalisation du tableau de bord lui-même et qui utilise pourtant Azure AD.

@edemen bien sûr, cela ne fonctionne que pour les K8 <1,15. Pour K8s 1.16, vous devez attendre la sortie officielle du nouveau tableau de bord v2.0, je suppose.

Dashboard v2 a lancé https://github.com/kubernetes/dashboard/releases/tag/v2.0.0 . Mais il semble avoir un support partiel pour k8s 1.16

@SayakMukhopadhyay jusqu'à la version v2.0.0-rc3, il était entièrement pris en charge. J'ai utilisé la dernière RC avec les versions 1.15 et 1.16 et j'ai plutôt bien fonctionné. Je ne sais pas quelle opération vous devez faire, mais c'est sûr que 99,99% de l'utilisation normale est couverte.

Merci pour votre retour!

L'article a été récemment mis à jour avec des détails sur la connexion au tableau de bord Kubernetes.

s'il vous plait fermer