AccessControlException, когда клиентское приложение .Net получает доступ к озеру данных Azure. - PullRequest
0 голосов
/ 05 января 2019

Я пытаюсь получить доступ к озеру данных из клиентского приложения .Net, используя этот пример

Я зарегистрировал клиентское приложение в AAD Tenant и оттуда использую идентификатор клиента и секрет клиента (как я полагаю, это аутентификация между сервисами.)

Озеро данных находится в другой подписке, но принадлежит тому же Арендатору / AAD

Приложение имеет разрешение на чтение / запись / выполнение в разделах «Владелец» и «Назначенные разрешения» для конкретной папки (две иерархии вниз по корневой папке) в datalake. Родительские папки до корня имеют разрешения «Выполнить» как , упомянутые здесь . Общий уровень доступа в «Access Control (IAM)» для приложения - «Reader»

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

Microsoft.Azure.DataLake.Store.AdlsException: Error opening a Read Stream for file something/something/something.txt
Operation: GETFILESTATUS failed with HttpStatus:Forbidden RemoteException: AccessControlException GETFILESTATUS failed with 
error 0x83090aa2 (Forbidden. ACL verification failed. Either the resource does not exist or the user is not authorized to 
perform the requested operation.).
[***][***] JavaClassName: org.apache.hadoop.security.AccessControlException.
Last encountered exception thrown after 1 tries. [Forbidden: AccessControlException]
[ServerRequestId:***]

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

Ответы [ 2 ]

0 голосов
/ 09 января 2019

Ответ - да, вы должны пользоваться принципами обслуживания пользователей.

Дополнительную информацию о приложениях и принципах обслуживания см. Здесь

В основном Azure использует идентификатор принципа службы в фоновом режиме для авторизации доступа к данным в озере данных. Если вы используете идентификатор приложения, вы увидите то же «Отображаемое имя» для своего приложения на блейде «Доступ» к папке озера данных и ошибочно считаете, что у вас есть доступ.

Поэтому для предоставления доступа ACL обязательно используйте идентификатор участника службы, а не идентификатор приложения.

0 голосов
/ 05 января 2019

Самый простой способ тестирования: предоставить владельцу приложения разрешения на озеро данных (Access Control IAM), подождать 15 минут и выполнить тестирование. если это исправляет это >> это означает, что вы где-то напутали с разрешениями.

Невозможно указать, где вы допустили ошибку при назначении разрешений. Как правило, для чтения файлов требуется чтение \ выполнение (что немного удивляет).

...