Dela via

Ange container-ACL

  • Artikel

Åtgärden Set Container ACL anger behörigheterna för den angivna containern. Behörigheterna anger om blobar i en container kan nås offentligt.

Från och med version 2009-09-19 tillhandahåller containerbehörigheterna följande alternativ för att hantera containeråtkomst:

  • Fullständig offentlig läsåtkomst: Container- och blobdata kan läsas via anonym begäran. Klienter kan räkna upp blobar i containern via anonym begäran, men kan inte räkna upp containrar i lagringskontot.

  • endast offentlig läsåtkomst för blobar: Blob-data i den här containern kan läsas via anonym begäran, men containerdata är inte tillgängliga. Klienter kan inte räkna upp blobar i containern via anonym begäran.

  • Ingen offentlig läsåtkomst: Container- och blobdata kan endast läsas av kontoägaren.

Set Container ACL anger också en lagrad åtkomstprincip för användning med signaturer för delad åtkomst. Mer information finns i Definiera en lagrad åtkomstprincip.

All offentlig åtkomst till containern är anonym, liksom åtkomst via en signatur för delad åtkomst.

Begäran

Den Set Container ACL begäran kan skapas på följande sätt. Vi rekommenderar att du använder HTTPS. Ersätt myaccount- med namnet på ditt lagringskonto:

Metod Begärande-URI HTTP-version
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1

Emulerad lagringstjänstbegäran

När du gör en begäran mot den emulerade lagringstjänsten anger du emulatorns värdnamn och blobtjänstporten som 127.0.0.1:10000följt av det emulerade lagringskontonamnet:

Metod Begärande-URI HTTP-version
PUT http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl HTTP/1.1

Mer information finns i Använda Azurite-emulatorn för lokal Azure Storage-utveckling.

URI-parametrar

Du kan ange följande ytterligare parametrar i begärande-URI:n:

Parameter Beskrivning
timeout Valfri. Parametern timeout uttrycks i sekunder. Mer information finns i Ange tidsgränser för Blob Service-åtgärder.

Begärandehuvuden

De obligatoriska och valfria begäranderubrikerna beskrivs i följande tabell:

Begärandehuvud Beskrivning
Authorization Krävs. Anger auktoriseringsschema, kontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage.
Date eller x-ms-date Krävs. Anger UTC (Coordinated Universal Time) för begäran. Mer information finns i Auktorisera begäranden till Azure Storage.
x-ms-version Valfri. Anger vilken version av åtgärden som ska användas för den här begäran. Mer information finns i Versionshantering för Azure Storage-tjänsterna.
x-ms-blob-public-access Valfri. Anger om data i containern kan nås offentligt och åtkomstnivån. Möjliga värden är:

- container: Anger fullständig offentlig läsåtkomst för container- och blobdata. Klienter kan räkna upp blobar i containern via anonym begäran, men kan inte räkna upp containrar i lagringskontot.
- blob: Anger offentlig läsåtkomst för blobar. Blobdata i den här containern kan läsas via anonym begäran, men containerdata är inte tillgängliga. Klienter kan inte räkna upp blobar i containern via anonym begäran.

Om det här huvudet inte ingår i begäran är containerdata privata för kontoägaren.

Observera att det inte är tillåtet att ange offentlig åtkomst för en container i ett Azure Premium Storage-konto.
x-ms-lease-id: <ID> Valfritt, version 2012-02-12 och senare. Om det anges lyckas Set Container ACL endast om containerns lån är aktivt och matchar detta ID. Om det inte finns något aktivt lån eller om ID:t inte matchar returneras 412 (villkorsfel).
x-ms-client-request-id Valfri. Tillhandahåller ett klientgenererat, täckande värde med en kibibytesteckengräns (KiB) som registreras i loggarna när loggningen konfigureras. Vi rekommenderar starkt att du använder det här huvudet för att korrelera aktiviteter på klientsidan med begäranden som servern tar emot. Mer information finns i Övervaka Azure Blob Storage-.

Den här åtgärden stöder också användning av villkorsstyrda huvuden för att köra åtgärden endast om ett angivet villkor uppfylls. Mer information finns i Ange villkorsstyrda rubriker för Blob Service-åtgärder.

Begärandetext

Ange en lagrad åtkomstprincip genom att ange en unik identifierare och åtkomstprincip i begärandetexten för den Set Container ACL åtgärden.

Elementet SignedIdentifier innehåller den unika identifieraren, som anges i Id-elementet, och information om åtkomstprincipen enligt AccessPolicy-elementet. Den maximala längden på den unika identifieraren är 64 tecken.

Fälten Start och Expiry måste uttryckas som UTC-tider och måste följa ett giltigt ISO 8061-format. ISO 8061-format som stöds innehåller följande:

  • YYYY-MM-DD
  • YYYY-MM-DDThh:mmTZD
  • YYYY-MM-DDThh:mm:ssTZD
  • YYYY-MM-DDThh:mm:ss.fffffffTZD

För datumdelen av dessa format är YYYY en fyrsiffrig årsrepresentation, MM är en tvåsiffrig månadsrepresentation och DD är en tvåsiffrig dagrepresentation. För tidsdelen är hh timrepresentationen i 24-timmars notation, mm är den tvåsiffriga minutrepresentationen, ss är den tvåsiffriga andra representationen och fffffff är den sjusiffriga millisekundersrepresentationen. En tidsdesignare T separerar datum- och tidsdelarna i strängen, och en tidszonsdesignator TZD anger en tidszon.

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Exempelbegäran

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
x-ms-blob-public-access: container  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2009-09-28T08:49:37.0000000Z</Start>  
      <Expiry>2009-09-29T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Svar

Svaret innehåller en HTTP-statuskod och en uppsättning svarshuvuden.

Statuskod

En lyckad åtgärd returnerar statuskod 200 (OK).

Mer information om statuskoder finns i Status och felkoder.

Svarshuvuden

Svaret för den här åtgärden innehåller följande rubriker. Svaret kan också innehålla ytterligare standard-HTTP-huvuden. Alla standardhuvuden överensstämmer med HTTP/1.1-protokollspecifikationen.

Svarsrubrik Beskrivning
ETag ETag för containern. Om begärandeversionen är 2011-08-18 eller senare omges ETag-värdet av citattecken.
Last-Modified Returnerar datum och tid då containern senast ändrades. Datumformatet följer RFC 1123. Mer information finns i Representera datum/tid-värden i rubriker.

Alla åtgärder som ändrar containern eller dess egenskaper eller metadata uppdaterar den senaste ändrade tiden, inklusive att ange containerns behörigheter. Åtgärder på blobar påverkar inte containerns senaste ändringstid.
x-ms-request-id Identifierar unikt den begäran som gjordes och kan användas för att felsöka begäran. Mer information finns i Felsöka API-åtgärder
x-ms-version Anger blobtjänstversionen som användes för att köra begäran. Det här huvudet returneras för begäranden mot version 2009-09-19 och senare.
Date Ett UTC-datum/tid-värde som genereras av tjänsten, vilket anger den tid då svaret initierades.
x-ms-client-request-id Kan användas för att felsöka begäranden och motsvarande svar. Värdet för det här huvudet är lika med värdet för x-ms-client-request-id-huvudet om det finns i begäran och värdet inte innehåller fler än 1 024 synliga ASCII-tecken. Om den x-ms-client-request-id rubriken inte finns i begäran visas den inte i svaret.

Exempelsvar

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
ETag: "0x8CB171613397EAB"  
Last-Modified: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Tillstånd

Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. Du kan auktorisera åtgärden Set Container ACL enligt beskrivningen nedan.

Viktig

Microsoft rekommenderar att du använder Microsoft Entra-ID med hanterade identiteter för att auktorisera begäranden till Azure Storage. Microsoft Entra-ID ger överlägsen säkerhet och användarvänlighet jämfört med auktorisering av delad nyckel.

Azure Storage stöder användning av Microsoft Entra-ID för att auktorisera begäranden till blobdata. Med Microsoft Entra-ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, huvudnamn för programtjänsten eller en hanterad Azure-identitet. Säkerhetsobjektet autentiseras av Microsoft Entra-ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.

Mer information om auktorisering med Microsoft Entra-ID finns i Auktorisera åtkomst till blobar med hjälp av Microsoft Entra-ID.

Behörigheter

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra-användare, grupp, hanterad identitet eller tjänstens huvudnamn ska anropa den Set Container ACL åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som innehåller den här åtgärden:

Mer information om hur du tilldelar roller med Hjälp av Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.

Anmärkningar

När du anger behörigheter för en container ersätts de befintliga behörigheterna. Om du vill uppdatera containerns behörigheter anropar du Hämta container-ACL för att hämta alla åtkomstprinciper som är associerade med containern. Ändra den åtkomstprincip som du vill ändra och anropa sedan Set Container ACL med den fullständiga uppsättningen data för att utföra uppdateringen.

Aktivera anonym offentlig åtkomst för containerdata

Om du vill aktivera anonym offentlig läsåtkomst för containerdata anropar du Set Container ACL med x-ms-blob-public-access-huvudet inställt på container eller blob. Om du vill inaktivera anonym åtkomst anropar du Set Container ACL utan att ange x-ms-blob-public-access-huvudet.

Om du anger x-ms-blob-public-access till blobkan klienter anropa följande åtgärder anonymt:

Om du anger x-ms-blob-public-access till containerkan klienter anropa följande åtgärder anonymt:

Upprätta åtkomstprinciper på containernivå

En lagrad åtkomstprincip kan ange starttid, förfallotid och behörigheter för signaturer för delad åtkomst som den är associerad med. Beroende på hur du vill styra åtkomsten till containern eller blobresursen kan du ange alla dessa parametrar i den lagrade åtkomstprincipen och utelämna dem från URL:en för signaturen för delad åtkomst. Genom att göra det kan du antingen ändra den associerade signaturens beteende när som helst eller återkalla den. Eller så kan du ange en eller flera åtkomstprincipparametrar i den lagrade åtkomstprincipen och de andra på URL:en. Slutligen kan du ange alla parametrar på URL:en. I det här fallet kan du använda den lagrade åtkomstprincipen för att återkalla signaturen, men inte ändra dess beteende. Mer information finns i Definiera en lagrad åtkomstprincip.

Tillsammans måste signaturen för delad åtkomst och den lagrade åtkomstprincipen innehålla alla fält som krävs för att auktorisera signaturen. Om några obligatoriska fält saknas misslyckas begäran. På samma sätt misslyckas begäran med statuskod 400 (felaktig begäran) om ett fält anges i både url:en för signatur för delad åtkomst och den lagrade åtkomstprincipen.

Som mest kan fem separata åtkomstprinciper anges för en enda container när som helst. Om fler än fem åtkomstprinciper skickas i begärandetexten returnerar tjänsten statuskod 400 (felaktig begäran).

En signatur för delad åtkomst kan utfärdas på en container eller en blob oavsett om containerdata är tillgängliga för anonym läsåtkomst. En signatur för delad åtkomst ger ett större mått på kontroll över hur, när och till vem en resurs görs tillgänglig.

Not

När du upprättar en lagrad åtkomstprincip på en container kan det ta upp till 30 sekunder innan principen börjar gälla. Under det här intervallet, tills principen blir aktiv, misslyckas en signatur för delad åtkomst som är associerad med den lagrade åtkomstprincipen med statuskoden 403 (Förbjuden).

Fakturering

Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via BLOB Storage REST API eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner ackumuleras till exempel till en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Set Container ACL begäranden baserat på lagringskontotypen:

Operation Typ av lagringskonto Faktureringskategori
Ange container-ACL Premium-blockblob
Standard generell användning v2		 Andra åtgärder
Ange container-ACL Standard generell användning v1 Skrivåtgärder

Mer information om priser för den angivna faktureringskategorin finns i Prissättning för Azure Blob Storage.

Se även

Begränsa åtkomsten till containrar och blobar
Delegera åtkomst med en signatur för delad åtkomst
Skapa och använda en signatur för delad åtkomst
Definiera en lagrad åtkomstprincip
Hämta container-ACL-
Auktorisera begäranden till Azure Storage
Status- och felkoder
Blob Service-felkoder