@Sudharma, ¿ puede compartir el documento al que se refiere para que podamos ayudarlo mejor?

¿Es este?

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

@ MicahMcKittrick-MSFT Estoy pasando por esto y funciona bien. Me refiero a este
https://docs.microsoft.com/en-us/azure/aks/kubernetes-dashboard#for -rbac-enabled-clusters
precisamente con el RBAC para salpicadero.

You can also integrate Azure Active Directory authentication to provide a more granular level of access. Más interesados ​​en cómo hacer esto!

@Sudharma ¡ gracias por eso!

@iainfoulds @seanmck ¿ alguno de ustedes podría comentar más sobre esta pregunta?

@Sudharma perdón por la demora en esto. He intentado reproducir esto, pero he tenido problemas para obtener una configuración de clúster RBAC con mi suscripción interna. Todos lo estamos echando un vistazo y lo actualizaremos lo antes posible.

@iainfoulds aplogies pero no he podido configurar mi entorno para probar esto con precisión. Por alguna razón, mi clúster habilitado para RBAC no se está aprovisionando correctamente incluso en mi suscripción personal. He estado intentando esto durante días sin suerte. ¿Podrías intentar reproducir esto también? Simplemente no estoy teniendo suerte.

CC @ Karishma-Tiwari-MSFT @ jakaruna-MSFT si también pueden probar una reproducción

@Sudharma perdón por la demora en esto. He intentado reproducir esto, pero he tenido problemas para obtener una configuración de clúster RBAC con mi suscripción interna. Todos lo estamos echando un vistazo y lo actualizaremos lo antes posible.

No hay problema. Sin embargo, manténgame actualizado ya que estoy ansioso por esta solución

Es el mismo problema conmigo también. Veo que el indicador de inicio de sesión del tablero tampoco pasa el token emitido a través de la pantalla de inicio de sesión. Todavía trata las solicitudes de conexión del tablero a través de la cuenta de servicio.

Además, no he dado acceso al panel de control a la cuenta de servicio, debido a la escalada de privilegios que crea.

En resumen, el acceso al panel a través de proxy funciona bien con la cuenta de servicio, pero no con el token de la cuenta OpenID Connect.

Este problema también sigue siendo un problema para nosotros. Así que aquí está mi +1

+1 aquí también,

Hola equipo,

¿Podría proporcionar más detalles sobre cómo funciona y en qué se diferencia del motor nativo de Kubernetes? Me pregunto si podríamos brindar algún apoyo para lo mismo. También se pregunta si el panel de control se puede configurar para usar Azure AD a través de un servicio de proxy.

¿Alguien tiene una actualización sobre esto? Puedo acceder si saco el token o uso el archivo de configuración de kube después de ejecutar "kubectl proxy", pero si ejecuto az aks browse, me piden que inicie sesión a través de la web (aunque ya lo he hecho) con un código de dispositivo , ingresar el código me lleva a un error en la línea de cmd "Oauth token: Error desconocido". Configuré el clúster con Rbac (con registros de aplicaciones de cliente y servidor y configuré los permisos según (https://docs.microsoft.com/en-us/azure/aks/aad-integration).

Lo único de lo que no estoy seguro es que he usado un registro de aplicación para el cliente, el servidor y el principal de servicio, por lo que 3 registros de aplicaciones en total. Se aprovisionó a través de terraform. El documento de la guía solo menciona los permisos para los registros de aplicaciones de cliente y servidor.

Espero que alguien pueda ayudar

Aún enfrenta el mismo problema. No se puede acceder al panel, API o kubectl usando cuentas AD

El siguiente comando funciona, esto crea las credenciales de administrador de k8s en /home/user/.kube/config
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev --admin

Después de agregar el enlace de roles de clúster con el usuario o grupo de AD, generalmente, los usuarios pueden iniciar sesión con el siguiente
az aks get-credentials --resource-group xxx-dev-test01 --name xxxk8sdev

Esto solicitará el token del dispositivo y los usuarios podrán iniciar sesión. Pero ahora esto falla constantemente.
Solo se puede acceder a Kubectl o al panel de control a través del administrador del clúster. Obviamente, no podemos otorgar créditos de administrador de clúster a todos los usuarios.

Lamento que la gente tenga problemas aquí.

El equipo de ingeniería ha identificado un problema y está trabajando para resolverlo. Parece ser un cambio de panel de Kubernetes subyacente en lugar de un comportamiento específico en AKS. @ palma21 puede proporcionar contexto adicional sobre las líneas de tiempo para la resolución.

El problema de

Para el resto que tienen problemas exclusivamente con el panel, las versiones más nuevas del panel requieren https o la marca de inicio de sesión inseguro o caerán en el inicio de sesión de la cuenta de servicio.

Para forzar esto, puede editar la implementación de su panel
p.ej.
kubectl edit deploy -n kube-system kubernetes-dashboard

Y agregue a las especificaciones de su contenedor.

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

En el futuro, aplicaremos la autenticación de token, cambiaremos el puerto 9090 a 8443, el esquema a HTTPS y utilizaremos certificados autofirmados. Esto saldrá pronto y se anunciará en nuestras notas de la versión.
https://github.com/Azure/aks/releases

Frente al mismo problema. No se puede acceder al panel de control, API o kubectl con cuentas de AD.

Mi error: no puedo acceder al panel de K8S usando cuentas AD.

¿Qué proceso está siguiendo para acceder al panel de control? ¿Has probado mi comentario de arriba?

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

@ palma21 Acabo de probar su sugerencia y sigo teniendo el mismo problema con la lista de errores al iniciar sesión en el tablero, por ejemplo.

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

configmaps está prohibido: el usuario "clusterAdmin" no puede enumerar configmaps en el espacio de nombres "predeterminado"

No tengo ningún vínculo de rol para la cuenta de servicio 'kubernetes-dashboard'. Lo intenté con el token de la cuenta de administrador del clúster. Parece que no puedo iniciar sesión con mi cuenta AAD para que funcione, aunque es un administrador de clúster y tenemos el RBAC adecuado, ¿el token generado con el comando a continuación es válido para el inicio de sesión del token del portador?

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

fragmento de detalles del grupo de anuncios:

Contenedores:
principal:
ID de contenedor : Docker: // 610c6b258cde01196c03c918c3acca6c3c6ba531153ad1b7e0f034e032065319
Imagen: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
ID de la imagen: docker- pullable: //k8s.gcr.io/kubernetes-dashboard-amd64@sha256 : 0ae6b69432e78069c5ce2bcde0fe409c5c4d6f0f4d9cd50a17974fea38898747
Puerto: 9090 / TCP
Puerto de host: 0 / TCP
Args:
--authentication-mode = token
- habilitar-inicio de sesión inseguro
Estado: Running
Comenzó: jue, 25 abr 2019 12:04:43 +0100

Ese mensaje indica que su rol clusterAdmin no tiene permisos para listar mapas de configuración en ese espacio de nombres. ¿Podría intentar agregar eso a su rol de Usuario y ver si eso lo resuelve?
De lo contrario, envíe su yaml de rol de ClusterAdmin y yaml de implementación de panel y puedo echar un vistazo.

Intenté nuevamente con una cuenta de servicio (no el panel predeterminado) y parece estar funcionando, lo cual es genial. Sin embargo, el uso de un token de un usuario de AAD con enlace de rol de administrador de clúster no puede iniciar sesión. ¿Debería un usuario de AAD con el RBAC correcto poder iniciar sesión en el tablero con token y recibir el nivel de privilegio en el tablero como se define en su enlace RBAC?

Sí, debería. ¿Puede enumerar los mapas de configuración en el NS predeterminado con el usuario que recibe el token en el panel de control de k8s? Si puede hacer esa acción con el usuario, entonces se espera; de lo contrario, diría que verifique qué token está pasando al Tablero.

Para evitar enviar spam a este hilo que parece resuelto, envíeme un correo electrónico a jpalma [at] microsoft.com

Para forzar esto, puede editar la implementación de su panel
p.ej.
kubectl edit deploy -n kube-system kubernetes-dashboard

Y agregue a las especificaciones de su contenedor.

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

En el futuro, aplicaremos la autenticación de token, cambiaremos el puerto 9090 a 8443, el esquema a HTTPS y utilizaremos certificados autofirmados. Esto saldrá pronto y se anunciará en nuestras notas de la versión.
https://github.com/Azure/aks/releases

Ustedes prometieron plazos, por el momento no hay solución y volvemos a usar esta solución insegura. El tema lleva abierto mucho tiempo mientras que al mismo tiempo se están atendiendo otras cosas . ¿Puedes darnos cronogramas reales?

@iainfoulds ¿Puedes darnos un tiempo?
citando:

@ palma21 puede proporcionar contexto adicional sobre las líneas de tiempo para la resolución.

@ palma21 Por el momento la solución está lejos de ser ideal, por alguna razón las líneas de código no funcionan,
error: las implementaciones "kubernetes-dashboard" no son válidas

En el futuro, aplicaremos la autenticación de token, cambiando el puerto 9090 a 8443, el esquema a HTTPS
¿¿¿Cuando???

Si el manifiesto de implementación no es válido, es probable que se deba a un problema de sintaxis o sangría. Lo hice de nuevo y funciona.
Prueba con una línea
args: ["--authentication-mode=token", "--enable-insecure-login"]

Deberíamos tener este cambio a finales de junio.

Esto es lo que hice basándome en las 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.

Probé esto:
kubectl edit deploy -n kube-system kubernetes-dashboard
con el último AKS implementado a partir del 12 de septiembre de 2019.
El Bloc de notas se abrió con un archivo yaml, pero cuando guardé y cerré recibí el error:

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

¿Algunas ideas?

Esto parece un error bastante importante. Según tengo entendido, no puede usar los inicios de sesión de AAD para acceder al panel de Kubernetes.

Peor aún, la documentación es incorrecta, ya que implica que puede:

Al configurar la autenticación para el panel de Kubernetes, se recomienda que utilice un token sobre la cuenta de servicio del panel predeterminada. Un token permite a cada usuario utilizar sus propios permisos. El uso de la cuenta de servicio del panel de control predeterminada puede permitir a un usuario omitir sus propios permisos y utilizar la cuenta de servicio en su lugar.

De leer este hilo, esto está roto. ¿Se puede corregir este error o al menos actualizar la documentación para dejar en claro que esto no es posible actualmente?

Este ticket se generó por primera vez el 30 de enero, eso es mucho tiempo para que este error esté abierto.

Deberíamos tener este cambio a finales de junio.

@ palma21 junio se ha ido, ¿hay una ETA para implementar esta solución?

Lo implementamos, incluidos los nuevos documentos (que notó anteriormente), pero tuvimos que revertirlo debido al nuevo comportamiento del navegador y un error.

Actualmente estamos trabajando en una solución para tenerlo a finales de este mes.

Hay una solución para habilitar esta funcionalidad mientras tanto, que implica
editar la implementación con
argumentos: ["--authentication-mode = token", "--enable-insecure-login"]

Su error anterior parece ser un problema de sintaxis o editor, acabo de volver a probar y todavía funciona.

¿Hay alguna actualización sobre este error?

Frente al mismo problema, ¿hay alguna actualización sobre esto y una ETA por la que se solucionará?

Dios, es realmente decepcionante apostar por que los productos de Microsoft pasen un par de meses implementando una solución de pila completa usando su AKS para descubrir que hay un error como este ...

Enviar correo basura a este problema también, ya que eso es lo que el personal de soporte de mi empleador en @ Microsoft ¹ me dijo que hiciera.

Me gustaría mucho una solución que _no_ implique desactivar SSL.

1: Recibí instrucciones personalmente y directamente de un _Support Escalation Engineer_, proveniente de: Servicio al cliente y soporte / Soporte técnico de Microsoft Azure / Equipo de contenedores de Azure - EMEA -

Me encanta la transparencia aquí y la excelente comunicación de MS. 🤦‍♂

@ palma21 ¿Puede compartir si tiene alguna actualización sobre este tema? Gracias :)

Sería bueno recibir una actualización sobre esto.

¿Tenemos alguna solución para esto o solo es necesario que el inquilino del clúster AKS habilitado para RBAC tenga que pasar por hacks?

¿Cuál es el nombre del elemento de la lista de trabajos pendientes que podemos rastrear para ver este problema hasta su resolución?

Las últimas noticias, que yo, como persona privada que a través del trabajo hablo con algunos expertos de Microsoft, puedo compartir es (de un experto asesor de Microsoft Architect K8s no identificado; ese no es el título, es una descripción de dicho título) que el complemento del

Estoy de acuerdo con esa afirmación, y le pediría a todas las personas futuras que vengan aquí haciendo esta misma pregunta que lean / desarrollen competencia en K8s para comprender los riesgos / preocupaciones de seguridad que presenta este complemento.

(Por el mero beneficio de tener una interfaz de usuario web con perillas y diales en lugar de simplemente usar las herramientas CLI perfectamente funcionales, entre las cuales se agregan cada vez más a K8 como estándar, como kustomize ).

Esto es posible con https://github.com/pusher/oauth2_proxy

@pierluigilenoci

Esto es posible con https://github.com/pusher/oauth2_proxy

Hola
¿Podría vincular o compartir un ejemplo viable que incluya un yaml para la entrada de un panel, values.yaml para oauth2_proxy y cualquier configuración aplicable para una aplicación de Azure AD?
He estado tratando de hacer que oauth2_proxy funcione con Azure AD durante varios días, pero no puedo encontrar un solo ejemplo completo y viable que entre en detalles suficientes sobre la configuración de esto, y experimentar con varios indicadores y configuraciones solo me llevó hasta ahora, pero no lo suficientemente lejos.
¡Realmente lo agradecería!

@edemen mis consejos:

• no use el panel de AKS predeterminado, instálelo por separado (v1.10.1) con helm
  Valores para timón
  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;
• instalar oauth2_proxy con helm https://github.com/helm/charts/blob/master/stable/oauth2-proxy
• Valores para timón
  extraArgs: provider: "azure" azure-tenant: "yourvalues" whitelist-domain: "yourvalues" cookie-domain: "yourvalues" set-authorization-header: "true"
  y
  ingress: enabled: true path: /oauth2

Esto debería ser suficiente.

@pierluigilenoci
Gracias por responder.
He logrado que Azure AD y el proxy oauth2 funcionen hoy, pero descubro que muchas configuraciones terminan en el error 500 causado por el error 400 devuelto por login.live.com (más detalles en https://github.com/oauth2- proxy / oauth2-proxy / issues / 458)
Básicamente, si uso set-authorization-header: "true" , la autenticación con el proxy oauth2 deja de funcionar con Azure. Tratando de averiguar por qué, pero nada hasta ahora.
Por si acaso, estoy instalando el proxy oauth2 con helm install oauth2-proxy stable/oauth2-proxy -n oauth2-proxy --values oauth2-proxy-values.yaml

No importa. Aparentemente, Dashboard v1.10.1 ni siquiera funciona en Kubernetes 1.16 que tenemos.
Gracias

No tuve suerte al hacer que el panel de Kubernetes listo para usar funcionara con AKS, pero debo admitir que no pasé mucho tiempo trabajando en él. La solución que parece estar funcionando (el tiempo mostrará cualquier problema) es usar el panel estándar con kubectl proxy y cargar los usuarios locales kubeconfig.

Es un proceso de varios pasos que no es tan fácil / agradable como una URL simple, pero parece ser la mejor manera de usar el panel que se ejecuta en el contexto de los usuarios de AD. Todavía estoy atento a un enfoque más limpio que no requiera mucha personalización del panel en sí y, sin embargo, use Azure AD.

@edemen, por supuesto, esto solo funciona para K8 <1.15. Para K8s 1.16, debe esperar hasta el lanzamiento oficial del nuevo tablero v2.0, supongo.

Dashboard v2 ha lanzado https://github.com/kubernetes/dashboard/releases/tag/v2.0.0 . Pero parece tener soporte parcial para k8s 1.16

@SayakMukhopadhyay hasta la versión v2.0.0-rc3 era totalmente compatible. Usé el último RC con la versión 1.15 y 1.16 y funcionó bastante bien. No sé qué operación necesita hacer, pero seguro que cubre el 99,99% del uso normal.

¡Gracias por los comentarios!

El artículo se actualizó recientemente con detalles sobre cómo iniciar sesión en el panel de Kubernetes.

por favor cierra