@Sudharma você pode compartilhar o documento ao qual está se referindo para que possamos melhor atendê-lo?

É este?

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

@ MicahMcKittrick-MSFT Já passei por isso e funciona bem. Estou me referindo a este
https://docs.microsoft.com/en-us/azure/aks/kubernetes-dashboard#for -rbac-enabled-clusters
precisamente com o RBAC para painel.

You can also integrate Azure Active Directory authentication to provide a more granular level of access. Mais interessado em como fazer isso.!

@Sudharma obrigado por isso!

@iainfoulds @seanmck poderia

@Sudharma desculpe a demora nisso. Tenho tentado reproduzir isso, mas tive problemas para obter uma configuração de cluster RBAC usando minha assinatura interna. Estamos todos dando uma olhada e atualizaremos assim que possível

Aplicativos @iainfoulds, mas não consegui configurar meu ambiente para testar isso com precisão. Por algum motivo, meu cluster habilitado para RBAC não está sendo provisionado corretamente, mesmo em minha assinatura pessoal. Estou tentando isso há dias, sem sorte. Você poderia tentar reproduzir isso também? Eu simplesmente não estou tendo sorte.

CC @ Karishma-Tiwari-MSFT @ jakaruna-MSFT se eles também puderem tentar uma reprodução

@Sudharma desculpe a demora nisso. Tenho tentado reproduzir isso, mas tive problemas para obter uma configuração de cluster RBAC usando minha assinatura interna. Estamos todos dando uma olhada e atualizaremos assim que possível

Sem problemas. No entanto, mantenha-me atualizado, pois estou ansioso por esta solução

É o mesmo problema comigo também. Vejo que o prompt de login do painel também não passa o token emitido pela tela de login. Ele ainda trata as solicitações de conexão do painel por meio da conta de serviço.

Além disso, não concedi acesso de painel à conta de serviço devido ao escalonamento de privilégios que ela cria.

Resumindo, o acesso ao painel via proxy funciona bem com a conta de serviço, mas não com o token de conta OpenID connect.

Esse problema também continua sendo um problema para nós. Então aqui está meu +1

+1 aqui também,

Olá equipe,

Você poderia fornecer mais detalhes sobre como ele funciona e o que é diferente do mecanismo nativo do Kubernetes? Gostaria de saber se poderíamos fornecer algum suporte para o mesmo. Também está se perguntando se o painel pode ser configurado para usar o Azure AD por meio de um serviço de proxy?

Alguém tem uma atualização sobre isso? Posso acessar se extrair o token ou usar o arquivo de configuração do kube após executar o "proxy kubectl", mas se executar az aks browse, recebo uma solicitação para fazer login pela web (embora já tenha feito um login az) com um código de dispositivo , inserir o código me leva a um erro na linha cmd "Token Oauth: Erro desconhecido". Eu configurei o cluster com Rbac (com registros de aplicativos de cliente e servidor e defini as permissões de acordo com (https://docs.microsoft.com/en-us/azure/aks/aad-integration).

A única coisa sobre a qual não tenho certeza é que usei um registro de aplicativo para o cliente, servidor e o principal de serviço, portanto, 3 registros de aplicativo no total. Foi provisionado via terraform. O documento do guia menciona apenas as permissões para os registros de aplicativos de cliente e servidor.

Espero que alguém possa ajudar

Ainda enfrentando o mesmo problema. Não é possível acessar o painel, API ou kubectl usando contas AD

O comando abaixo funciona, isso cria credenciais de administrador k8s para /home/user/.kube/config
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev --admin

Depois de adicionar a ligação da função de cluster com o usuário ou grupo AD, geralmente, os usuários podem fazer o login com
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev

Isso solicitará o token do dispositivo e os usuários podem fazer o login. Mas agora isso falha consistentemente.
O Kubectl ou painel pode ser acessado apenas por meio do administrador do cluster. Obviamente, não podemos dar credenciais de administrador de cluster a todos os usuários.

Desculpe, as pessoas estão tendo problemas aqui.

A equipe de engenharia identificou um problema e está trabalhando para resolvê-lo. Parece ser uma mudança subjacente no painel do Kubernetes, e não um comportamento específico no AKS. @ palma21 pode fornecer contexto adicional sobre cronogramas para resolução.

O problema

Para o resto que está tendo problemas exclusivamente com o painel, as versões mais recentes do painel exigem https ou o sinalizador de login inseguro ou cairão para o login da conta de serviço.

Para forçar isso, você pode editar a implantação do seu painel
por exemplo.
kubectl edit deploy -n kube-system kubernetes-dashboard

E adicione às especificações do seu contêiner.

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

Seguindo em frente, aplicaremos a autenticação por token, alterando a porta 9090 para 8443, o esquema para HTTPS e usando certificados autoassinados. Isso sairá em breve e será anunciado em nossas notas de lançamento.
https://github.com/Azure/aks/releases

Enfrentando o mesmo problema. Não é possível acessar o painel, API ou kubectl usando contas AD.

Meu erro: não consigo acessar o painel K8S usando contas AD.

Qual processo você está seguindo para acessar o painel? Você tentou meu comentário acima?

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

@ palma21 Acabei de experimentar sua sugestão e continuo recebendo o mesmo problema com a lista de erros ao fazer login no painel, por exemplo

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

configmaps é proibido: O usuário "clusterAdmin" não pode listar configmaps no namespace "default"

Não tenho vinculação de função para a conta de serviço 'kubernetes-dashboard'. Tentei com o token de conta de administrador de cluster. Não consigo fazer o login com minha conta AAD funcionar, embora seja um administrador de cluster e tenhamos o RBAC apropriado instalado, o token gerado com o comando abaixo é válido para o login do token do portador?

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

trecho de detalhes do pod:

Recipientes:
a Principal:
ID do contêiner: docker: // 610c6b258cde01196c03c918c3acca6c3c6ba531153ad1b7e0f034e032065319
Imagem: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
ID da imagem: docker- pullable: //k8s.gcr.io/kubernetes-dashboard-amd64@sha256 : 0ae6b69432e78069c5ce2bcde0fe409c5c4d6f0f4d9cd50a17974fea38898747
Porta: 9090 / TCP
Porta do host: 0 / TCP
Args:
--authentication-mode = token
--enable-insecure-login
Estado: Correndo
Iniciado: Qui, 25 de abril de 2019 12:04:43 +0100

Essa mensagem indica que sua função clusterAdmin não tem permissões para listar mapas de configuração nesse namespace. Você poderia tentar adicionar isso à sua função de usuário e ver se isso resolve o problema?
Caso contrário, envie seu yaml de função ClusterAdmin e yaml de implantação de painel e eu posso dar uma olhada.

Tentei novamente com uma conta de serviço (não o painel padrão) e parece estar funcionando, o que é ótimo. No entanto, o uso de um token de um usuário AAD com vinculação de função de administrador de cluster é uma falha no login. Um AAD deve ser usado com o RBAC correto para fazer login no painel com token e receber o nível de privilégio no painel conforme definido em sua ligação RBAC?

Sim, deveria. Você pode listar mapas de configuração no NS padrão com o usuário para o qual está obtendo o token para o painel k8s? Se você pode fazer essa ação com o usuário, é o esperado, caso contrário, eu diria para verificar qual token você está passando para o painel.

Para evitar o envio de spam para este tópico que parece resolvido, mande-me um e-mail para jpalma [at] microsoft.com

Para forçar isso, você pode editar a implantação do seu painel
por exemplo.
kubectl edit deploy -n kube-system kubernetes-dashboard

E adicione às especificações do seu contêiner.

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

Seguindo em frente, aplicaremos a autenticação por token, alterando a porta 9090 para 8443, o esquema para HTTPS e usando certificados autoassinados. Isso sairá em breve e será anunciado em nossas notas de lançamento.
https://github.com/Azure/aks/releases

Vocês prometeram prazos, no momento não há solução e voltamos a usar essa solução insegura. A questão está aberta há muito tempo e ao mesmo tempo há outras coisas sendo atendidas . Você pode nos dar cronogramas reais ??

@iainfoulds Você pode realmente fornecer timelienes ??
citando:

@ palma21 pode fornecer contexto adicional sobre cronogramas para resolução.

@ palma21 No momento a solução está longe de ser ideal, por algum motivo as linhas de código não funcionam,
erro: as implantações "kubernetes-dashboard" são inválidas

Seguindo em frente, aplicaremos a autenticação por token, alterando a porta 9090 para 8443 e o esquema para HTTPS
Quando???

Se o manifesto de implantação for inválido, provavelmente é um problema de sintaxe ou recuo. Acabei de fazer de novo e funciona.
Experimente com um inline
args: ["--authentication-mode=token", "--enable-insecure-login"]

Devemos ter essa mudança no prazo do final de junho.

Isso é o que eu fiz com base nas notas de @ 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.

Eu tentei isso:
kubectl edit deploy -n kube-system kubernetes-dashboard
com o AKS mais recente implantado a partir de 12/09/2019.
O bloco de notas foi aberto preenchido com um arquivo yaml, mas quando salvei e fechei, recebi o erro:

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

Alguma ideia?

Este parece ser um grande bug. Pelo que entendi, você não pode usar logins do AAD para acessar o painel do Kubernetes.

Pior ainda, a documentação está errada, pois implica que você pode:

Ao configurar a autenticação para o painel Kubernetes, é recomendável usar um token sobre a conta de serviço do painel padrão. Um token permite que cada usuário use suas próprias permissões. Usar a conta de serviço do painel padrão pode permitir que um usuário ignore suas próprias permissões e use a conta de serviço.

Ao ler este tópico, isso está quebrado. Este bug pode ser corrigido ou pelo menos a documentação atualizada para deixar claro que isso não é possível no momento?

Este tíquete foi gerado pela primeira vez em 30 de janeiro, que é muito tempo para o bug ser aberto.

Devemos ter essa mudança no prazo do final de junho.

@ palma21 Junho já passou, há um HEC para esta correção ser implantada?

Nós o implementamos, incluindo novos documentos (que você observou acima), mas tivemos que reverter devido a um novo comportamento do navegador e um bug.

No momento, estamos trabalhando para consertá-lo até o final deste mês.

Entretanto, há uma solução alternativa para ativar esta funcionalidade que envolve
editando a implantação com
args: ["--authentication-mode = token", "--enable-insecure-login"]

Seu erro acima parece ser um problema de sintaxe ou editor, acabei de testar novamente e ainda funciona.

Existe alguma atualização sobre este bug?

Enfrentando o mesmo problema, há alguma atualização sobre isso e um ETA que será corrigido?

Puxa, é realmente decepcionante apostar que os produtos da Microsoft passam alguns meses implantando uma solução full stack usando seu AKS para descobrir que há um bug como este ....

Enviar spam para esse problema também - visto que foi isso que a equipe de suporte do meu empregador no @ Microsoft ¹ me disse para fazer.

Gostaria muito de uma solução que _não_ envolvesse desligar o SSL.

1: Instruções recebidas pessoalmente e diretamente de um _Engenheiro de escalonamento de suporte_, proveniente de: Atendimento ao cliente e suporte / Suporte técnico do Microsoft Azure / Equipe de contêineres do Azure - EMEA -

Eu amo a transparência aqui e a ótima comunicação da MS. 🤦‍♂

@ palma21 Você pode compartilhar se tem alguma atualização sobre este problema? Obrigado :)

Seria bom obter uma atualização sobre isso

Temos alguma correção para isso ou apenas o locatário do cluster AKS habilitado para RBAC precisa passar apenas por hacks?

qual é o nome do item do backlog que podemos rastrear para ver esse problema resolvido?

As últimas notícias - que eu, como uma pessoa privada que através do trabalho falo com alguns especialistas da Microsoft - posso compartilhar são (de um Microsoft Architect K8s Advisor Expert não nomeado - esse não é o título, é uma descrição do referido título) que o Plugin do

Eu concordo com essa afirmação, e gostaria de pedir a todas as pessoas que vierem aqui fazendo essa mesma pergunta que leiam / desenvolvam competências em K8s para entender os riscos / preocupações de segurança que esse plug-in apresenta.

(Para o mero ganho de ter uma IU da Web com botões e dials em vez de apenas usar as ferramentas CLI perfeitamente viáveis ​​- entre as quais há cada vez mais adicionadas ao K8s como padrão, como o kustomize ).

Isso pode ser feito com https://github.com/pusher/oauth2_proxy

@pierluigilenoci

Isso pode ser feito com https://github.com/pusher/oauth2_proxy

Oi
Você poderia vincular ou compartilhar um exemplo viável que inclua um yaml para uma entrada de painel, values.yaml para oauth2_proxy e quaisquer configurações aplicáveis ​​para um aplicativo Azure AD?
Tenho tentado fazer com que oauth2_proxy funcione com o Azure AD por vários dias, mas não consigo encontrar um único exemplo completo viável que dê detalhes suficientes sobre a configuração disso, e experimentar vários sinalizadores e configurações só me levou até agora, não longe o suficiente.
Eu realmente aprecio isso!

@edemen minhas dicas:

• não use o painel AKS padrão, instale-o separadamente (v1.10.1) com o helm
  Valores para leme
  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;
• instale oauth2_proxy com helm https://github.com/helm/charts/blob/master/stable/oauth2-proxy
• Valores para leme
  extraArgs: provider: "azure" azure-tenant: "yourvalues" whitelist-domain: "yourvalues" cookie-domain: "yourvalues" set-authorization-header: "true"
  e
  ingress: enabled: true path: /oauth2

Isso deve ser o suficiente.

@pierluigilenoci
Obrigado por responder.
Consegui fazer o Azure AD e o proxy oauth2 funcionarem hoje, mas estou descobrindo que muitas configurações acabam no erro 500, causado pelo erro 400 retornado por login.live.com (mais detalhes em https://github.com/oauth2- proxy / oauth2-proxy / issues / 458)
Essencialmente, se eu usar set-authorization-header: "true" , a autenticação com o proxy oauth2 para de funcionar com o Azure. Tentando descobrir o porquê, mas nada até agora.
Por precaução, estou instalando o proxy oauth2 com helm install oauth2-proxy stable/oauth2-proxy -n oauth2-proxy --values oauth2-proxy-values.yaml

Deixa pra lá. Aparentemente, o Dashboard v1.10.1 nem funciona no Kubernetes 1.16 que temos.
Obrigado

Não tive sorte em fazer com que o painel do Kubernetes pronto para usar funcionasse com o AKS, mas devo admitir que não gastei muito tempo trabalhando nisso. A solução que parece estar funcionando (o tempo mostrará quaisquer problemas) é usar o painel padrão com kubectl proxy e enviar o kubeconfig dos usuários locais.

É um processo de várias etapas que não é tão fácil / agradável quanto um URL simples, mas parece ser a melhor maneira de usar o painel em execução no contexto de usuários do AD. Ainda estou de olho em uma abordagem mais limpa que não exige muita personalização do painel em si e ainda usa o Azure AD.

@edemen é claro que isso funciona apenas para K8s <1,15. Para K8s 1.16, você precisa esperar até o lançamento oficial do novo painel v2.0, eu presumo.

O Dashboard v2 lançou https://github.com/kubernetes/dashboard/releases/tag/v2.0.0 . Mas parece ter suporte parcial para k8s 1.16

@SayakMukhopadhyay até a versão v2.0.0-rc3 era totalmente compatível. Usei o RC mais recente com as versões 1.15 e 1.16 e funcionou muito bem. Não sei qual operação você precisa fazer, mas com certeza 99,99% do uso normal é coberto.

Obrigado pelo feedback!

O artigo foi atualizado recentemente com detalhes sobre como fazer login no painel do Kubernetes.

feche por favor