Jogosultságkezelés Data Lake-ben


Anno, amikor elkezdtem foglalkozni az Azure Data Lake-kel, az első, amit felírtam magamnak az volt, hogy a „Data Lake egy olyan Blob Storage, ami tud jogosultságot kezelni” Ez az egy gondolat sokáig elég volt ahhoz, hogy el tudjam helyezni az Azure Data Lake-et a Microsoft Big Data térképén.

A következő cikkben pont ezt az apró különbséget fogjuk górcső alá venni és megnézzük, hogy Azure Data Lake-ben hogyan tudunk jogosultságot kezelni.   

A Jogosultságot kétféleképpen is szabályozhatjuk a Data Lake-ben:

  • Role-based access control (RBAC) segítségével és
  • Access control list (ACL) segítségével

Ha végtelenül le akarom egyszerűsíteni akkor a Role-based access control (RBAC)-t használjuk az adminisztrátori feladatok (erőforrás szintű) jogosultságának szabályozására, az Access control list (ACL)-t pedig a felhasználó szintű (fájlalapú) jogosultság kezelésre.

Nézzük egy kicsit részletesebben:

Azure Data Lake jogosultság kezelés

Role-based access control (RBAC)

Az RBAC egy szabályalapú jogosultság kezelés, melynek célja, hogy az „adminisztrátorok” jogát szabályozni tudjuk. Azokét az emberekét, alkalmazásokét, amelyek az Azure erőforrásokat menedzselik. És bár fájlrendszer szinten tudunk vele jogosultságot kezelni, de könyvtár/fájl szinten már nem. Az RBAC hatóköre ugyanis a

  • Resource Group
    • Storage Account
      • Container/Files system
        • Folder
          • file

hierarchiában csak a Container/File system szintig terjed, jogosultságot kezelni vele könyvtár fájl szinten már nem tudunk. Hiába vagyunk például tulajdonosai (owner) egy storage accountnak, ez a jogosultság nem elég ahhoz, hogy mondjuk Power BI-jal lekérdezzük az fájlok tartalmát, mert az RBAC az erőforrás jogosultságát szabályozza, nem a fájlokét. (Az owner jogosultságot öröklik a könyvtárak, fájlok is, de az RBAC szintű owner tulajdonság kevés ahhoz, hogy pl Power BI-jal lekérdezzük a fájlok tartalmát) De erről már az Access to the resource is forbidden című cikkben értekeztünk.

Access control list (ACL)

Az Acces Control List (ACL) alapú jogosultság kezeléssel könyvtár/fájl szinten tudjuk a jogosultságot szabályozni:

Azure Data Lake jogosultság kezelés

ACL-lel tudunk valakinek úgy is jogosultságot adni, fájlokhoz/könyvtárakhoz, hogy storage account szinten semmilyen jogosultsággal nem rendelkezik. De ha valakinek Storage Account szinten RBAC-cal adtunk olvasási jogot, azt már fájl/könyvtár szinten nem tudjuk csökkenteni. Itt is igaz ugyanis, hogy a jogosultságok fentről lefelé öröklődnek, ha valakinek adtunk hozzáférést a storage account-hoz akkor az látni fog minden könyvtárat, minden fájlt.

Ha tehát fájl/könvytár szinten szeretnénk jogosultságot kezelni, akkor RBAC-ot el kell felejteni és a jogosultság kezelést ACL-lel kell megoldani.

Az ACL alapú jogosultság kezelés nyomokban hasonlít a windows könyvtárak jogosultságkezeléséhez. De csak nagyon nyomokban. Épp ezért összeírtam azokat a furcsaságokat, amelyek egy windows könyvtárak jogosultság kezelésén szocializálódott BI-osnak nehézséget okoztak:

  1. Nem elég egy könyvtárhoz read jogot adni ahhoz, hogy a felhasználók hozzáférjenek a könyvtár tartalmához. Ha azt szeretnénk, hogy egy felhasználó hozzáférjen a könyvtárhoz, akkor a könyvtár összes szülő könyvtárához kell Execute jogosultságot adnunk.
  2. Egy könyvtár jogosultságának megváltoztatása csak a változtatás után bekerült fájlokra lesz hatással. A korábban bekerült fájlok jogosultsága nem fog változni! A fájlok ugyanis nem öröklik a szülőkönyvtár jogosultságának változását! Ha szeretnénk megváltoztatni egy könyvtár jogosultságát, akkor a könyvtáron belül minden létező fájl jogosultságát meg kell változtatnunk. Az újonnan bekerülő fájlok már megkapják majd a szülő könyvtár jogosultságát, de a létezők nem.

A fentiek miatt személynek sosem adunk jogosultságot könyvtárhoz. Mindig csoportnak adunk jogosultságot, még akkor is, ha a csoportba egy személy tartozik. így el tudjuk kerülni, hogy a jogosultságok változásakor újra kelljen írni a létező fájlok jogosultságát

Irodalom:


Elválasztó

Már készül a következő cikk. Iratkozzon fel az értesítőre.

|

Kővári Attila
2020. február 10.