Управляемая идентификация Azure Kubernetes и удостоверения модуля AAD

Кажется, теперь Azure Kubernetes предлагает два способа доступа к другим ресурсам Azure. 1. Управляемая идентификация AKS - https://docs.microsoft.com/en-us/azure/aks/use-managed-identity 2. Идентификатор модуля AAD - https://github.com/Azure/aad-pod-identity

Как приложение, работающее в AKS, как я могу запросить токен для идентификатора, управляемого кластером AKS, или идентификатора модуля AAD? Когда я вызываю конечную точку IMDS для получения токена, как она узнает, для какого идентификатора нужно сгенерировать токен?


azure-aks azure-container-service
person user3740951    schedule 15.06.2020    source источник
comment
Вы заинтересованы в том, чтобы каждый модуль имел собственный идентификатор при взаимодействии с сервером API? Kubernetes в качестве этого концептуального уровня с использованием Kubernetes Service Principal, вы получаете отдельные данные аудита для каждой операции каждого пользователя (учетная запись службы): kubernetes.io/docs/tasks/configure-pod-container/   -  person djsly    schedule 15.06.2020
comment
нет, я не хочу общаться с сервером api kubernetes. мой вопрос касается доступа к другим ресурсам Azure.   -  person user3740951    schedule 15.06.2020
comment
так что вы правы: github.com/Azure/aad-pod-identity является необходимое программное обеспечение.   -  person djsly    schedule 15.06.2020

Ответы (2)


arrow_upward
3
arrow_downward

Управляемое удостоверение AKS, указанное в варианте 1 (https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) предназначен только для внутреннего использования кластером. Вы не можете использовать это удостоверение для доступа к ресурсам Azure из модулей.

Вы можете использовать удостоверение Pod для удовлетворения своих потребностей. Вам необходимо создать привязку удостоверения (https://github.com/Azure/aad-pod-identity#5-deploy-azureidentitybinding) для управляемого удостоверения, которое вы хотите использовать, и укажите эту привязку удостоверения в спецификации вашего модуля (https://github.com/Azure/aad-pod-identity#6-deployment-and-validation ).

Когда модуль запрашивает маркер у конечной точки IMDS, ему не нужно указывать идентификатор: он определяется автоматически NMI на основе привязки идентификатора в спецификации модуля для модуля, выполняющего запрос.

person udayxhegde    schedule 13.07.2020

arrow_upward
0
arrow_downward

Точно так же хост может сделать запрос авторизации для получения токена участника-службы для ресурса непосредственно из конечной точки хоста NMI (http://127.0.0.1:2579/host/token/). Запрос должен включать в себя модули пространства имен модуля и имя модуля модуля в заголовке запроса и конечную точку ресурса ресурса, запрашивающего маркер. Сервер NMI идентифицирует модуль на основе модулей и имени модуля в заголовке запроса, а затем запрашивает у k8s (через MIC) соответствующий идентификатор лазурного цвета. Затем NMI делает запрос ADAL, чтобы получить токен для ресурса в запросе, возвращая токен и клиентский идентификатор в качестве ответа.

https://github.com/Azure/aad-pod-identity#node-managed-identity

person djsly    schedule 15.06.2020
comment
как насчет того, чтобы в каком-то варианте использования мне не нужен токен идентификатора модуля, а токен управляемой идентичности кластера AKS, как мне этого добиться? Подойдет ли отсутствие заголовка пространства имен модуля? - person user3740951; 15.06.2020
comment
прямо сейчас вам нужно будет свернуть объект службы контейнера с помощью API управления Azure. - person djsly; 16.06.2020
comment
но кажется, что servicePrincipalProfile вернет вам пустую полезную нагрузку с идентификатором клиента MSI, потому что сейчас AKS поддерживает только динамически подготовленный токен. Они будут поддерживать ваш собственный токен / ключ (принесите свой собственный пользовательский MSI). Получив это, вы сможете повторно использовать то же самое в своем POD прямо сейчас, вы можете повторно использовать систему, назначенную MSI, используя PRincipalID ресурса AKs с делегированием, см. docs.microsoft.com/en-us/azure/aks/ - person djsly; 16.06.2020
comment
Я не понимаю. не могли бы вы подробнее рассказать, как я могу получить токен для AKS MSI - docs .microsoft.com / en-us / azure / aks / use-managed-identity? Обычно это можно сделать через конечную точку IMDS (169.254.169.254). Но если у меня есть MIC и NMI, работающие для некоторых других модулей, чтобы получить токен в способе идентификации модуля, как я могу также получить токен для назначенного системой AKS MSI? - person user3740951; 16.06.2020
comment
ты не можешь. сейчас кажется, что объект containerService не раскрывает секрет. - person djsly; 16.06.2020
comment
используйте resources.azure.com, чтобы посмотреть на json-объект вашего кластера с поддержкой MSI, вы увидите в servicePrincipalProfile секрет, который должен быть NULL. - person djsly; 16.06.2020
comment
Ok. но тогда зачем вообще предлагать MSI, если мы не можем им пользоваться? - person user3740951; 16.06.2020
comment
это хорошо для пользователей, которые не хотят пока управлять своим собственным SerivcePrincipal. Ранний выпуск GA, я думаю, сделает его доступным. Как мне сказали, пользовательский MSI выйдет как релиз 2. - person djsly; 16.06.2020