Data Lake Store Access – tips’n’tricks

Mam kilka rozgrzebanych wpisów, od wczesnego szkicu po prawie-finalne wersje, ale nie mogę się zebrać za ich wykończenie. Zatem na bezrybiu i rak ryba – krótko o tym jak klikać dostępy do Azure Data Lake Store (klikać – tzn. że robiłem to z Portalu, być może jest jakaś sprytniejsza, sympatyczniejsza opcja, jeszcze nie wnikałem).

Niezależnie czy dostęp chce się nadać „normalnemu” użytkownikowi czy aplikacji w AD (do autoryzacji service-to-service) robi się to tak samo.

Załóżmy, że mamy konto ADLS i w nim przykładową ścieżkę folderów: /pro/wojtek/blog/…

Chcemy dodać, niech będzie usłudze, dostęp do odczytu z folderu blog. Żeby taki dostęp funkcjonował efektywnie użytkownik musi mieć uprawnienie Execute do wszystkich folderów „po drodze” do blob, włączając root (/). No i niby łatwo, ale żeby tego nie robić kilka razy, zwłaszcza kiedy w tych folderach jest już na prawdę dużo innych folderów i plików (bo przypisywanie im uprawnień trwa) warto o paru sprawach pamiętać:

Przypisanie Read do blog nie załatwi automatycznie Execute na ścieżce biegnącej „w górę” do roota. To jeszcze w miarę naturalne. Efekt – użytkownik nie ma dostępu bo nie może „przejść” przez foldery prowadzące do blog.

Nie ma opcji ręcznego nakazania zrobienia takiej ścieżki „w górę”. Da się to zrobić na dwa sposoby:

  • nadając uprawnienia folder po folderze – wybieranie Access w każdym miejscu i ustawianie Execute do każdego folderu – wygląda na pracochłonne i czasożerne rozwiązanie, ale prawdopodobnie i efekt otrzymamy szybciej niż…
  • nadając uprawnienia w roocie i oznaczając opcję rekursywnego przypisania ich w dół (all children…) – nie dość, że jeśli konto jest już bogate w strukturę i pliki to będzie to długo trwało, to jeszcze rozpropagujemy tego Executa również tam, gdzie niekoniecznie jest potrzebny i na tym się niedogodności nie kończą…

Ponieważ gdy jednak zdecydujemy się na drugie z rozwiązań (rekursywna propagacja uprawnień) to może nas czekać małe rozczarowanie. Czas na ilustrację.

Otóż „Add to” to nie Add. To Set. To znaczy jeśli najpierw ustawimy sobie uprawnienie Read do blog, a potem przypomni się nam żeby sobie rekursywnie dołożyć Execute na ścieżce to niestety rozczarowanie – Execute zastąpi wszystkie ustawione wcześniej uprawnienia. Tak więc – jeśli nie chcemy ustawiać uprawnień ręcznie tylko skorzystać z opcji „and all children” przy dodawaniu to należy pamiętać, żeby robić to „od góry” czyli najlepiej rozpocząć od roota zakładając najpierw najmniejszy zestaw uprawnień, a potem wchodzić w kolejne podfoldery podnosząc uprawnienia tam, gdzie trzeba.

Dodatkowo trzeba pamiętać o tym, że z kolei „Add as” (niżej na ilustracji) domyślnie ma ustawioną opcję „As access permition entry”. Jeśli puścimy to w folderze blog i wszystkich jego dzieciach to dostęp nam zadziała, ale tylko na plikach i folderach, które tam były w momencie ustawienia uprawnień. Jeśli pojawią się tam nowe dane (np. wyniki obliczeń z Data Lake Analytics) to niestety użytkownik do nich uprawnień posiadał nie będzie. Żeby uprawnienia same się przypisały interesujący nas zestaw należy opatrzyć ostatnią opcją, która nie tylko przypisze uprawnienia obecnym obiektom, ale także nowo utworzonym (default permission entry).

Dzisiejsza robota szłaby nieco sprawniej gdybym wiedział to wszystko wczoraj 🙂

Dodaj komentarz