Å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å typer av åtkomstkontrollistor (ACL: er), åtkomst-ACL:er och standard-ACL:er.
Åtkomst-ACL:er: Dessa styr åtkomsten till ett objekt. Både filer och mappar har åtkomst-ACL:er.
standard-ACL:er: En "mall" med ACL:er som är associerade med en mapp som avgör åtkomst-ACL:er för alla underordnade objekt som skapas under mappen. Filer har inte standard-ACL:er.
Både åtkomst-ACL:er och standard-ACL:er har samma struktur.
Anmärkning
Att ändra standard-ACL för en överordnad påverkar inte åtkomst-ACL eller standard-ACL för underordnade objekt som redan finns.
Behörigheter
Behörigheterna för ett filsystemobjekt är Read, Writeoch Execute, och de kan användas på filer och mappar enligt följande tabell:
Fil | Mapp | |
---|---|---|
Läsa (R) | Kan läsa innehållet i en fil | Kräver Läs och Kör för att visa innehållet i mappen |
Skriva (W) | Kan skriva eller lägg till i en fil | Kräver Skriv och Kör för att skapa underobjekt i en mapp |
Utför (X) | Betyder inte något i samband med Data Lake Storage Gen1 | Krävs för att bläddra i underordnade objekt 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 betyder |
---|---|---|
7 | RWX |
Läsa + skriva + exekvera |
5 | R-X |
Läsa + utföra |
4 | R-- |
Läs |
0 | --- |
Inga behörigheter |
Behörigheter ärver inte
I POSIX-modellen som används av Data Lake Storage Gen1 lagras behörigheter för ett objekt på själva objektet. Med andra ord kan behörigheter för ett objekt inte ärvas från de överordnade objekten.
Vanliga scenarier som rör behörigheter
Följande är 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.
Verksamhet | Objekt | / | Seattle/ | Portland/ | Data.txt |
---|---|---|---|---|---|
Läs | Data.txt | --X |
--X |
--X |
R-- |
Lägg till | 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 |
--- |
Anmärkning
Skrivbehörigheter för filen krävs inte för att ta bort den så länge de föregående två villkoren är sanna.
Användare och identiteter
Varje fil och mapp har distinkta behörigheter för dessa identiteter:
- Den ägande användaren
- Ä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 samband med 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 ägare eller ägargrupp för alla filer och mappar.
Alla användare som ingår i Ägare roll för ett Data Lake Storage Gen1-konto är automatiskt en superanvändare.
Ägaranvändaren
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.
Anmärkning
Den ägande användaren kan inte ändra den ägande användaren av 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 har alltid angetts som hennes primära grupp. När Alice skapar en fil i POSIX är den ägande gruppen för filen inställd på hennes primära grupp, som i det här fallet är "ekonomi". Den ägande gruppen fungerar annars på samma 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
- ärende 1: rotmappen "/". Den här mappen skapas när ett Data Lake Storage Gen1-konto skapas. I det här fallet är ägargruppen inställd på ett GUID som består av enbart nollor. Det här värdet tillåter inte någon åtkomst. Det är en platshållare tills en grupp tilldelas.
- ärende 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:
- Finns det några superanvändare?
- Den ägande användaren, om den ägande användaren också är medlem i målgruppen.
Anmärkning
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 den ägande gruppen till den användare som skapade kontot när det gäller rotmappen för ärende 1ovan. Ett enskilt användarkonto är inte giltigt för att tillhandahålla 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 visas i algoritmen för åtkomstkontroll begränsar masken åtkomsten för namngivna användare, ägande gruppoch namngivna grupper.
Anmärkning
För ett nytt Data Lake Storage Gen1-konto är masken för åtkomst-ACL för rotmappen ("/") standardvärdet RWX.
Sticky bit
Den klibbiga biten ä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, om sticky-bit är aktiverad på en mapp, kan ett underordnat objekt endast tas bort eller bytas namn på av den användare som äger det underordnade objektet.
Den klibbiga biten 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 avgör standard-ACL på den överordnade mappen:
- En barnmapps förvals-ACL och åtkomst-ACL.
- En barnfils åtkomst-ACL (filer har ingen förvald 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 gruppoch andra.
Umask för Azure Data Lake Storage Gen1 är ett konstant värde satt till 007. Det här värdet översätts till
komponent för umask | Numeriskt format | Kortformat | Innebörd |
---|---|---|---|
umask.owning_user | 0 | --- |
För användare som äger, kopiera föräldrarnas standard-ACL till barnets åtkomst-ACL. |
umask.owning_group | 0 | --- |
För den ägande gruppen kopierar du den överordnade gruppens standard-ACL till den underordnade gruppens åtkomst-ACL. |
umask.other | 7 | RWX |
För övrigt tar du bort alla behörigheter för den underordnade åtkomst-ACL:en |
Umask-värdet som används av Azure Data Lake Storage Gen1 innebär i praktiken att värdet för andra aldrig tilldelas som standard på nya objekt – oavsett vad standard-ACL anger.
Följande pseudokod visar hur umasken tillämpas 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 aktiverad 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örigheten Write + Execute.
- Mappen som ska tas bort, och alla mappar i den, kräver Läs + Skriv + Kör behörigheter.
Anmärkning
Du behöver inte skrivbehörighet 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 ägare.
Vilken grupp anges som ägande grupp för en fil eller mapp när den skapas?
Den ägande gruppen kopieras från den ägande gruppen för den överordnade mappen under vilken den nya filen eller mappen skapas.
Jag äger en fil men jag har inte de RWX-behörigheter jag behöver. Vad gör jag?
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 ser jag användarnamn, men via API:er ser jag GUID:er, varför är det så?
Poster i ACL:erna lagras som GUID:er som motsvarar användare i Microsoft Entra-ID. API:erna returnerar GUID:erna som de är. Azure-portalen försöker göra ACL:er enklare att använda genom att översätta GUID:erna till egna namn när det är möjligt.
Varför kan jag ibland se 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. Se också till 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 en service principal?
På Azure-portalen går du till Microsoft Entra ID –> Företagsapplikationer 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 på filer och mappar?
32 ACL:er kan anges per fil och katalog. Åtkomst- och standard-ACL:er har varsin gräns på 32 ACL. Använd säkerhetsgrupper för ACL-tilldelningar om 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
- Guide för HDFS-behörighet
- Vanliga frågor och svar om POSIX
- POSIX 1003.1 2008
- POSIX 1003.1 2013
- POSIX 1003.1 2016
- POSIX ACL på Ubuntu