@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-cluster
именно с RBAC для приборной панели.

You can also integrate Azure Active Directory authentication to provide a more granular level of access. Еще интересует, как это сделать.!

@Sudharma, спасибо за это!

@iainfoulds @seanmck не могли бы вы прокомментировать этот вопрос дальше?

@Sudharma извините за задержку с этим. Я пытался воспроизвести это, но у меня возникли проблемы с настройкой кластера RBAC с использованием моей внутренней подписки. Мы все ищем и обновим, как только сможем

@iainfoulds aplogies, но мне не удалось настроить свою среду, чтобы точно проверить это. По какой-то причине мой кластер с включенным RBAC не инициализируется правильно даже в моей личной подписке. Я пробовал это в течение нескольких дней, но безуспешно. Не могли бы вы попробовать воспроизвести это тоже? Мне просто не везет.

CC @ Karishma-Tiwari-MSFT @ jakaruna-MSFT, если они тоже могут попробовать репро

@Sudharma извините за задержку с этим. Я пытался воспроизвести это, но у меня возникли проблемы с настройкой кластера RBAC с использованием моей внутренней подписки. Мы все ищем и обновим, как только сможем

Нет проблем. Однако, пожалуйста, держите меня в курсе, так как я очень хочу это решение

То же самое и со мной. Я вижу, что приглашение для входа на панель управления также не передает токен, выданный через экран входа в систему. Он по-прежнему обрабатывает запросы на подключение к панели управления через учетную запись службы.

Кроме того, я не предоставил доступ к панели управления учетной записи службы из-за повышения привилегий, которое она создает.

Короче говоря, доступ к панели управления через прокси-сервер хорошо работает с учетной записью службы, но не с токеном учетной записи подключения OpenID.

Этот вопрос остается проблемой и для нас. Итак, вот мой +1

+1 и здесь,

Привет команда,

Не могли бы вы подробнее рассказать о том, как он работает и чем отличается от собственного движка Kubernetes. Мне интересно, можем ли мы оказать некоторую поддержку тому же самому. Также интересно, можно ли настроить панель управления для использования Azure AD через прокси-службу?

У кого-нибудь есть обновления по этому поводу? Я могу получить доступ, если вытащу токен или использую файл конфигурации kube после запуска «kubectl proxy», но если я запустил az aks browse, меня попросят войти в систему через Интернет (даже если я уже выполнил вход в систему az) с кодом устройства , ввод кода приводит меня к ошибке в строке cmd «Токен Oauth: неизвестная ошибка». Я настроил кластер с Rbac (с регистрацией клиентских и серверных приложений и установил разрешения согласно (https://docs.microsoft.com/en-us/azure/aks/aad-integration).

Единственное, в чем я не уверен, это то, что я использовал регистрацию приложения для клиента, сервера и субъекта-службы, поэтому всего 3 регистрации приложений. Он был предоставлен через терраформ. В руководстве упоминаются только разрешения для регистрации клиентского и серверного приложений.

Надеюсь, кто-то может помочь

По-прежнему сталкиваюсь с той же проблемой. Невозможно получить доступ к панели управления, API или kubectl с помощью учетных записей AD

Команда ниже работает, это создает учетные данные администратора 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 или панель управления доступны только через администратора кластера. Очевидно, мы не можем дать всем пользователям права администратора кластера.

Извините, люди здесь сталкиваются с проблемами.

Группа инженеров определила проблему и работает над ее решением. Похоже, что это основное изменение панели управления Kubernetes, а не конкретное поведение в AKS. @ 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

Столкнувшись с той же проблемой. Невозможно получить доступ к панели управления, API или kubectl с помощью учетных записей AD.

Моя ошибка: не могу получить доступ к панели управления K8S с помощью учетных записей AD.

Какой процесс вы выполняете, чтобы получить доступ к панели инструментов? Вы пробовали мой комментарий выше?

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

@ palma21 Я только что попробовал ваше предложение и все еще получаю ту же проблему со списком ошибок при входе в панель управления, например

• kubectl прокси
• http: // localhost : 8001 / api / v1 / namespaces / kube-system / services / kubernetes-dashboard / proxy / #! / логин

configmaps запрещено: пользователь "clusterAdmin" не может перечислить configmaps в пространстве имен "default"

У меня нет привязки ролей для учетной записи службы «kubernetes-dashboard». Я пробовал использовать токен учетной записи администратора кластера. Кажется, я не могу получить логин с моей учетной записью AAD для работы вообще, хотя это администратор кластера, и у нас есть соответствующий RBAC, является ли токен, созданный с помощью приведенной ниже команды, действительным для входа в систему с токеном-носителем?

• az account 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
Аргументы:
--authentication-mode = токен
--enable-insecure-login
Состояние: работает
Начат: чт, 25 апр 2019 12:04:43 +0100

Это сообщение указывает на то, что ваша роль clusterAdmin не имеет разрешений на вывод списка конфигурационных карт в этом пространстве имен. Не могли бы вы попробовать добавить это к своей роли пользователя и посмотреть, решит ли это проблему?
В противном случае отправьте yaml своей роли ClusterAdmin и yaml развертывания панели инструментов, и я могу посмотреть.

Просто попробовал еще раз с учетной записью службы (не на панели управления по умолчанию), и, похоже, она работает, и это здорово. Однако при использовании токена пользователя AAD с привязкой роли администратора кластера не удается войти в систему. Должно ли использование AAD с правильным RBAC иметь возможность входить в панель мониторинга с токеном и получать уровень привилегий на панели мониторинга, как определено в их привязке RBAC?

Да, должно. Можете ли вы перечислить карты конфигурации на NS по умолчанию с пользователем, которому вы получаете токен, на панель управления k8s? Если вы можете выполнить это действие с пользователем, то оно ожидаемо, в противном случае я бы сказал, проверьте, какой токен вы передаете на панель инструментов.

Чтобы избежать рассылки спама в этой теме, которая кажется решенной, напишите мне по адресу 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 Не могли бы вы на самом деле предоставить timelienes ??
цитирование:

@ palma21 может предоставить дополнительный контекст по

@ palma21 На данный момент решение далеко не идеальное, по какой-то причине строки кода не работают,
ошибка: развертывания "kubernetes-dashboard" недействительны

В дальнейшем мы будем применять аутентификацию токена, изменяя порт 9090 на 8443, схему на HTTPS.
Когда???

Если манифест развертывания недействителен, это, вероятно, проблема с синтаксисом или отступом. Я просто сделал это снова, и это работает.
Попробуйте со встроенным
args: ["--authentication-mode=token", "--enable-insecure-login"]

Это изменение должно произойти примерно в конце июня.

Вот что я сделал на основе заметок
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
с последней версией AKS, развернутой по состоянию на 12 сентября 2019 г.
Блокнот открыт с файлом yaml, но когда я сохранил и закрыл, я получил сообщение об ошибке:

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

Есть идеи?

Это похоже на серьезную ошибку. Насколько я понимаю, вы не можете использовать логины AAD для доступа к панели управления Kubernetes.

Хуже того, документация неверна, поскольку подразумевает, что вы можете:

При настройке аутентификации для панели инструментов Kubernetes рекомендуется использовать токен вместо учетной записи службы панели мониторинга по умолчанию. Токен позволяет каждому пользователю использовать свои собственные разрешения. Использование учетной записи службы панели мониторинга по умолчанию может позволить пользователю обойти свои собственные разрешения и вместо этого использовать учетную запись службы.

Судя по этой теме, это не работает. Можно ли исправить эту ошибку или хотя бы обновить документацию, чтобы прояснить, что в настоящее время это невозможно?

Этот тикет был впервые подан 30 января, то есть еще долго, чтобы исправить эту ошибку.

Это изменение должно произойти примерно в конце июня.

@ palma21 Июнь уже прошел, есть ли

Мы развернули его, включая новые документы (которые вы заметили выше), но пришлось откатить его из-за нового поведения браузера и ошибки.

В настоящее время мы работаем над исправлением, чтобы оно появилось к концу этого месяца.

Тем временем существует обходной путь для включения этой функции, который включает
редактирование развертывания с помощью
args: ["--authentication-mode = token", "--enable-insecure-login"]

Ваша ошибка выше, похоже, связана с синтаксисом или проблемой редактора, я только что протестировал повторно, и она все еще работает.

Есть ли какие-нибудь обновления относительно этой ошибки?

Столкнувшись с той же проблемой, есть ли какие-либо обновления по этому поводу и ETA, с помощью которых она будет исправлена?

Черт возьми, действительно обидно делать ставку на продукты Microsoft, потратив пару месяцев на развертывание полного стека с использованием своего AKS, чтобы обнаружить, что есть такая ошибка ...

Спамить и эту проблему - поскольку это то, что мне сказали делать сотрудники службы поддержки моего работодателя через @ Microsoft ¹ .

Очень хотелось бы решения, которое _не_ отключение SSL.

1: Получены инструкции лично и непосредственно от _Support Escalation Engineer_ от: Службы поддержки и поддержки клиентов / Службы технической поддержки Microsoft Azure / Группы контейнеров Azure - EMEA -

Мне нравится прозрачность здесь и отличное общение со стороны MS. 🤦‍♂

@ palma21 Не могли бы вы поделиться, если у вас есть

Было бы хорошо узнать об этом

Есть ли у нас какое-то исправление для этого или его клиенту кластера AKS с включенным RBAC нужно только взломать?

какое имя элемента невыполненной работы мы можем отслеживать, чтобы увидеть решение этой проблемы?

Последние новости, которыми я, как частное лицо, по работе разговариваю с некоторыми экспертами Microsoft, могу поделиться (от неназванного эксперта Microsoft Architect K8s Advisor - это не заголовок, это описание указанного заголовка), что подключаемый модуль Dashboard по своей сути небезопасен и не должен использоваться.

Я согласен с этим утверждением и прошу всех будущих людей, которые придут сюда и зададут этот же вопрос, прочитать / повысить компетентность в K8s, чтобы понять риски / проблемы безопасности, которые представляет такой плагин.

(Просто для того, чтобы иметь веб-интерфейс с ручками и циферблатами вместо того, чтобы просто использовать идеально работающие инструменты CLI, среди которых все больше и больше добавляется в K8s в качестве стандарта, например, kustomize ).

Это можно сделать с https://github.com/pusher/oauth2_proxy

@pierluigilenoci

Это можно сделать с https://github.com/pusher/oauth2_proxy

Привет
Не могли бы вы связать или поделиться работоспособным примером, который включает yaml для входа на панель мониторинга, values.yaml для oauth2_proxy и любые применимые настройки для приложения Azure AD?
Я пытался заставить oauth2_proxy работать с Azure AD в течение нескольких дней, но не могу найти ни одного полного работоспособного примера, который бы достаточно подробно описал настройку этого, и эксперименты с различными флагами и настройками только помогли мне, но недостаточно далеко.
Был бы очень признателен!

@edemen мои советы:

• не используйте панель управления AKS по умолчанию, установите ее отдельно (v1.10.1) с помощью helm
  Значения для руля
  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;
• установить oauth2_proxy с помощью helm https://github.com/helm/charts/blob/master/stable/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, но я обнаружил, что многие настройки заканчиваются ошибкой 500, вызванной ошибкой 400, возвращаемой login.live.com (подробнее см. Https://github.com/oauth2- прокси / oauth2-proxy / issues / 458)
По сути, если я использую set-authorization-header: "true" , аутентификация с прокси-сервером oauth2 вообще перестает работать с Azure. Пытаюсь понять почему, но пока ничего.
На всякий случай устанавливаю прокси oauth2 с helm install oauth2-proxy stable/oauth2-proxy -n oauth2-proxy --values oauth2-proxy-values.yaml

Ничего. Судя по всему, Dashboard v1.10.1 не работает даже на Kubernetes 1.16, который у нас есть.
Спасибо

Мне не повезло с готовой панелью управления Kubernetes, работающей с AKS, но я должен признать, что не тратил на нее много времени. Решение, которое кажется работающим (время покажет какие-либо проблемы), заключается в использовании стандартной панели инструментов с kubectl proxy и загрузке локальных пользователей kubeconfig.

Это многоэтапный процесс, который не так прост и приятен, как простой URL-адрес, но, по-видимому, является лучшим способом использования панели мониторинга, работающей в контексте пользователей AD. Я по-прежнему ищу более чистый подход, который не требует большой настройки самой панели мониторинга и при этом использует Azure AD.

@edemen, конечно, это работает только для K8s <1.15. Я полагаю, что для K8s 1.16 вам нужно дождаться официального выпуска новой приборной панели v2.0.

Dashboard v2 запущен https://github.com/kubernetes/dashboard/releases/tag/v2.0.0 . Но вроде есть частичная поддержка k8s 1.16

@SayakMukhopadhyay до версии v2.0.0-rc3 полностью поддерживался. Я использовал последний RC с версией 1.15 и 1.16 и работал неплохо. Я не знаю, какую операцию вам нужно выполнить, но наверняка покрывается 99,99% нормального использования.

Спасибо за ваш отзыв!

Статья недавно была обновлена ​​подробностями о входе в панель управления Kubernetes.

пожалуйста, закрой