Åtkomstkontroll i Azure Data Lake Storage Gen1
Azure Data Lake Storage Gen1 implementerar en åtkomstkontrollmodell som härleds från HDFS, som i sin tur härleds från POSIX-åtkomstkontrollmodellen. Den här artikeln sammanfattar grunderna i åtkomstkontrollmodellen för Data Lake Storage Gen1.
Åtkomstkontrollistor för filer och mappar
Det finns två sorters åtkomstkontrollistor (ACL:er), Åtkomst-ACL:er och Standard-ACL:er.
Åtkomst-ACL:er: De här kontrollerar åtkomst till ett objekt. Både filer och mappar har åtkomst-ACL:er.
Standard-ACL: En "mall" av ACL:er som är associerad med en mapp som bestämmer åtkomst-ACL:er för underordnade objekt som skapats under mappen. Filer har inte standard-ACL:er.
Både åtkomst-ACL:er och standard-ACL:er har samma struktur.
Anteckning
Att ändra standard-ACL på ett överordnat objekt påverkar inte åtkomst-ACL eller standard-ACL för underordnade objekt som redan finns.
Behörigheter
Behörigheter för ett objekt i filsystemet är Läsa, Skriva och Köra och de kan användas för filer och mappar som visas i tabellen nedan:
Fil | Mapp | |
---|---|---|
Läsa (R) | Kan läsa innehållet i en fil | Kräver Läsa och Köra för att visa innehållet i mappen |
Skriva (W) | Kan skriva eller lägg till i en fil | Kräver Skriva och Köra för att skapa underordnade objekt i en mapp |
Köra (X) | Betyder ingenting i samband med Data Lake Storage Gen1 | Krävs för att bläddra bland de underordnade objekten i en mapp |
Kortformat för behörigheter
RWXanvänds för att ange läsa + skriva + köra. Ett numeriskt mer komprimerat format finns där Läsa = 4, skriva = 2 och Köra = 1 och deras summa representerar behörigheterna. Här följer några exempel.
Numeriskt format | Kortformat | Vad det innebär |
---|---|---|
7 | RWX |
Läsa + skriva + köra |
5 | R-X |
Läsa + köra |
4 | R-- |
Läsa |
0 | --- |
Inga behörigheter |
Behörigheter ärvs inte
I POSIX-modellen som används av Data Lake Storage Gen1 lagras behörigheter för ett objekt på själva objektet. Behörigheter för ett objekt kan med andra ord inte ärvas från de överordnade objekten.
Vanliga scenarier som rör behörigheter
Nedan följer några vanliga scenarier som hjälper dig att förstå vilka behörigheter som krävs för att utföra vissa åtgärder på ett Data Lake Storage Gen1 konto.
Åtgärd | Objekt | / | Seattle/ | Portland/ | Data.txt |
---|---|---|---|---|---|
Läsa | Data.txt | --X |
--X |
--X |
R-- |
Lägg till i | Data.txt | --X |
--X |
--X |
-W- |
Ta bort | Data.txt | --X |
--X |
-WX |
--- |
Skapa | Data.txt | --X |
--X |
-WX |
--- |
Lista | / | R-X |
--- |
--- |
--- |
Lista | /Seattle/ | --X |
R-X |
--- |
--- |
Lista | /Seattle/Portland/ | --X |
--X |
R-X |
--- |
Anteckning
Skrivbehörigheterna för filen behövs inte att ta bort filen så länge de två villkoren ovan är sanna.
Användare och identiteter
Alla filer och mappar har olika behörigheter för dessa identiteter:
- Ägande användare
- Ägande grupp
- Namngivna användare
- Namngivna grupper
- Alla andra användare
Identiteterna för användare och grupper är Microsoft Entra identiteter. Så om inget annat anges kan en "användare" i kontexten för Data Lake Storage Gen1 antingen betyda en Microsoft Entra användare eller en Microsoft Entra säkerhetsgrupp.
Superanvändaren
En superanvändare har flest rättigheter för alla användare i Data Lake Storage Gen1-kontot. En superanvändare:
- Har RWX-behörigheter till alla filer och mappar.
- Kan ändra behörigheterna för alla filer och mappar.
- Kan ändra ägande användare eller ägande grupp för alla filer och mappar.
Alla användare som ingår i rollen Ägare för ett Data Lake Storage Gen1-konto är automatiskt superanvändare.
Ägande användare
Användaren som skapade objektet är automatiskt ägande användare för objektet. En ägande användare kan:
- Ändra behörigheterna för en fil som ägs.
- Ändra ägande grupp för en fil som ägs, så länge den ägande användaren också är medlem i målgruppen.
Anteckning
Den ägande användaren kan inte ändra ägande användare för en fil eller mapp. Endast superanvändare kan ändra ägande användare av en fil eller mapp.
Ägande grupp
Bakgrund
I POSIX-ACL:er är varje användare associerad med en "primär grupp". Användaren "alice" kan till exempel tillhöra gruppen "finance". Alice kan också tillhöra flera grupper, men en grupp anges alltid som hennes primära grupp. När Alice skapar en fil i POSIX ställs den ägande gruppen för filen in på hennes primära grupp, som i det här fallet är "ekonomi". Den ägande gruppen fungerar annars på liknande sätt som tilldelade behörigheter för andra användare/grupper.
Eftersom det inte finns någon "primär grupp" som är associerad med användare i Data Lake Storage Gen1 tilldelas den ägande gruppen enligt nedan.
Tilldela ägande grupp för en ny fil eller mapp
- Fall 1: Rotmappen "/". Den här mappen skapas när ett Data Lake Storage Gen1 konto skapas. I det här fallet är ägandegruppen inställd på ett helt noll-GUID. Det här värdet tillåter inte åtkomst. Det är en platshållare tills en grupp tilldelas.
- Fall 2 (alla andra fall): När ett nytt objekt skapas, kopieras den ägande gruppen från den överordnade mappen.
Ändra ägande grupp
Den ägande gruppen kan ändras av:
- Alla superanvändare.
- Den ägande användaren, om den ägande användaren också är medlem i målgruppen.
Anteckning
Den ägande gruppen kan inte ändra ACL:er för en fil eller mapp.
För konton som skapades den 1 september 2018 eller före september 2018 angavs ägandegruppen till den användare som skapade kontot i fallet med rotmappen för ärende 1 ovan. Ett enskilt användarkonto är inte giltigt för att ge behörigheter via den ägande gruppen, vilket innebär att inga behörigheter beviljas med den här standardinställningen. Du kan tilldela den här behörigheten till en giltig användargrupp.
Algoritm för åtkomstkontroll
Följande pseudokod representerar algoritmen för åtkomstkontroll för Data Lake Storage Gen1 konton.
def access_check( user, desired_perms, path ) :
# access_check returns true if user has the desired permissions on the path, false otherwise
# user is the identity that wants to perform an operation on path
# desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
# path is the file or folder
# Note: the "sticky bit" is not illustrated in this algorithm
# Handle super users.
if (is_superuser(user)) :
return True
# Handle the owning user. Note that mask IS NOT used.
entry = get_acl_entry( path, OWNER )
if (user == entry.identity)
return ( (desired_perms & entry.permissions) == desired_perms )
# Handle the named users. Note that mask IS used.
entries = get_acl_entries( path, NAMED_USER )
for entry in entries:
if (user == entry.identity ) :
mask = get_mask( path )
return ( (desired_perms & entry.permmissions & mask) == desired_perms)
# Handle named groups and owning group
member_count = 0
perms = 0
entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
for entry in entries:
if (user_is_member_of_group(user, entry.identity)) :
member_count += 1
perms | = entry.permissions
if (member_count>0) :
return ((desired_perms & perms & mask ) == desired_perms)
# Handle other
perms = get_perms_for_other(path)
mask = get_mask( path )
return ( (desired_perms & perms & mask ) == desired_perms)
Masken
Som du ser i algoritmen för åtkomstkontroll begränsar masken åtkomsten för namngivna användare, ägande grupp och namngivna grupper.
Anteckning
För ett nytt Data Lake Storage Gen1 konto är masken för åtkomst-ACL för rotmappen ("/") standard för RWX.
Sticky bit
Sticky bit är en mer avancerad funktion i ett POSIX-filsystem. När det gäller Data Lake Storage Gen1 är det osannolikt att den klibbiga biten kommer att behövas. Sammanfattningsvis kan ett underordnat objekt bara tas bort eller byta namn på det underordnade objektets ägande användare om den fästiga biten är aktiverad i en mapp.
Sticky bit visas inte i Azure-portalen.
Standardbehörigheter för nya filer och mappar
När en ny fil eller mapp skapas under en befintlig mapp, anger standard-ACL:en på den överordnade mappen:
- En underordnad mapps standard-ACL och åtkomst-ACL.
- En underordnad fils åtkomst-ACL (filer har inte en standard-ACL).
umask
När du skapar en fil eller mapp används umask för att ändra hur standard-ACL:er anges för det underordnade objektet. umask är ett 9-bitars värde på överordnade mappar som innehåller ett RWX-värde för ägande användare, ägande grupp och annat.
Umask för Azure Data Lake Storage Gen1 är ett konstant värde som anges till 007. Det här värdet översätts till
umask-komponent | Numeriskt format | Kortformat | Innebörd |
---|---|---|---|
umask.owning_user | 0 | --- |
För ägande användare kopierar du den överordnades standard-ACL till den underordnade åtkomst-ACL:en |
umask.owning_group | 0 | --- |
För ägande grupp kopierar du den överordnades standard-ACL till den underordnade åtkomst-ACL:en |
umask.other | 7 | RWX |
För andra tar du bort alla behörigheter för barnets åtkomst-ACL |
Umask-värdet som används av Azure Data Lake Storage Gen1 innebär effektivt att värdet för andra aldrig överförs som standard på nya underordnade – oavsett vad standard-ACL anger.
Följande pseudokod visar hur umask används när du skapar ACL:er för ett underordnat objekt.
def set_default_acls_for_new_child(parent, child):
child.acls = []
for entry in parent.acls :
new_entry = None
if (entry.type == OWNING_USER) :
new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
elif (entry.type == OWNING_GROUP) :
new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
elif (entry.type == OTHER) :
new_entry = entry.clone(perms = entry.perms & (~umask.other))
else :
new_entry = entry.clone(perms = entry.perms )
child_acls.add( new_entry )
Vanliga frågor om ACL:er i Data Lake Storage Gen1
Måste jag aktivera stöd för ACL:er?
Nej. Åtkomstkontroll via ACL:er är alltid aktiverat för ett Data Lake Storage Gen1 konto.
Vilka behörigheter krävs för att rekursivt ta bort en mapp och dess innehåll?
- Den överordnade mappen måste ha behörigheterna skriva + köra.
- Mappen som ska tas bort och alla mappar inom den, behöver behörigheterna läsa + skriva + köra.
Anteckning
Du behöver inte Skriv-behörigheter för att ta bort filer i mappar. Dessutom kan rotmappen "/" aldrig tas bort.
Vem äger en fil eller mapp?
Skaparen av en fil eller mapp blir ägaren.
Vilken grupp anges som den ägande gruppen för en fil eller mapp vid skapandet?
Det kopieras från den ägande gruppen för den överordnade mappen under vilken den nya filen eller mappen skapas.
Jag är ägande användare av en fil, men jag har inte den RWX-behörighet jag behöver. Vad gör jag nu?
Den ägande användaren kan lätt ändra behörigheterna för filen för att ge sig själva de RWX-behörigheter de behöver.
När jag tittar på ACL:er i Azure-portalen, visas användarnamn men via API:er visas GUID:er. Varför?
Poster i ACL:erna lagras som GUID:er som motsvarar användare i Microsoft Entra ID. API:erna returnerar GUID:erna i befintligt skick. Azure-portalen försöker göra det enklare att använda ACL:er genom att översätta GUID:er till bekanta namn när det är möjligt.
Varför visas ibland GUID:er i ACL:er när jag använder Azure-portalen?
Ett GUID visas när användaren inte längre finns i Microsoft Entra. Detta inträffar vanligtvis när användaren har lämnat företaget eller om deras konto har tagits bort i Microsoft Entra ID. Kontrollera också att du använder rätt ID för att ange ACL:er (information i fråga nedan).
Vilket ID ska jag använda för att ange ACL:er när jag använder tjänstens huvudnamn?
På Azure-portalen går du till Microsoft Entra ID –> Företagsprogram och väljer ditt program. Fliken Översikt bör visa ett objekt-ID och detta är vad som ska användas när du lägger till ACL:er för dataåtkomst (och inte program-ID).
Stöder Data Lake Storage Gen1 arv av ACL:er?
Nej, men standard-ACL:er kan användas för att ange ACL:er för underordnade filer och mappar som nyligen skapats under den överordnade mappen.
Vilka är gränserna för ACL-poster för filer och mappar?
32 ACL:er kan anges per fil och per katalog. Åtkomst- och standard-ACL:er har varsin gräns på 32 ACL. Använd säkerhetsgrupper för ACL-tilldelningar om det är möjligt. Med hjälp av grupper är det mindre troligt att du överskrider det maximala antalet ACL-poster per fil eller katalog.
Var hittar jag mer information om POSIX-modellen för åtkomstkontroll?
- POSIX-åtkomstkontrollistor på Linux
- HDFS-behörighetsguide
- Vanliga frågor och svar om POSIX
- POSIX 1003.1 2008
- POSIX 1003.1 2013
- POSIX 1003.1 2016
- POSIX ACL på Ubuntu