Получение списка ACL контейнера

Операция Get Container ACL получает разрешения для указанного контейнера. Разрешения указывают, могут ли данные контейнера получить общедоступный доступ.

По состоянию на версию 2009-09-19 разрешения контейнера предоставляют следующие параметры управления доступом к контейнерам:

• полный общедоступный доступ на чтение: данные контейнера и больших двоичных объектов можно считывать с помощью анонимного запроса. Клиенты могут перечислять большие двоичные объекты в контейнере с помощью анонимного запроса, но они не могут перечислять контейнеры в учетной записи хранения.

• общедоступный доступ на чтение для больших двоичных объектов только: данные BLOB-объектов в этом контейнере можно считывать с помощью анонимного запроса, но данные контейнера недоступны. Клиенты не могут перечислять большие двоичные объекты в контейнере с помощью анонимного запроса.

• Нет общедоступного доступа на чтение: данные контейнера и БОЛЬШОго двоичного объекта могут читаться только владельцем учетной записи.

Get Container ACL также возвращает сведения о любых политиках доступа на уровне контейнера, указанных в контейнере, которые могут использоваться с подписанными URL-адресами. Дополнительные сведения см. в статье Определение хранимой политики доступа.

Все общедоступные доступы к контейнеру анонимны, так как доступ осуществляется через подписанный URL-адрес.

Просьба

Запрос Get Container ACL может быть создан следующим образом. Рекомендуется использовать ПРОТОКОЛ HTTPS. Замените myaccount именем учетной записи хранения:

Метод	URI запроса	ВЕРСИЯ HTTP
GET/HEAD	https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl	HTTP/1.1

Запрос службы эмулированного хранилища

При выполнении запроса к эмулированной службе хранилища укажите имя узла эмулятора и порт хранилища BLOB-объектов как 127.0.0.1:10000, а затем имя эмулированной учетной записи хранения:

Метод	URI запроса	ВЕРСИЯ HTTP
GET/HEAD	http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl	HTTP/1.1

Дополнительные сведения см. в статье Использование эмулятора Azurite для разработки локальной службы хранилища Azure.

Параметры URI

В URI запроса могут быть указаны следующие дополнительные параметры:

Параметр	Описание
timeout	Необязательный. Параметр timeout выражается в секундах. Дополнительные сведения см. в разделе Настройка времени ожидания для операций хранилища BLOB-объектов.

Запрос кодов ошибок

Обязательные и необязательные заголовки запросов описаны в следующей таблице:

Заголовок запроса	Описание
Authorization	Обязательно. Указывает схему авторизации, имя учетной записи и подпись. Дополнительные сведения см. в статье Авторизация запросов к службе хранилища Azure.
Date или x-ms-date	Обязательно. Указывает универсальное время (UTC) для запроса. Дополнительные сведения см. в статье Авторизация запросов к службе хранилища Azure.
x-ms-lease-id: <ID>	Необязательно, версия 2012-02-12 и более поздняя. Если он указан, Get Container ACL успешно выполняется только в том случае, если аренда контейнера активна и соответствует этому идентификатору. Если нет активной аренды или идентификатор не соответствует, возвращается 412 (Precondition Failed).
x-ms-version	Требуется для всех авторизованных запросов. Указывает версию операции, используемой для этого запроса. Дополнительные сведения см. в разделе Управление версиями служб хранилища Azure.
x-ms-client-request-id	Необязательный. Предоставляет созданное клиентом непрозрачное значение с ограничением символов 1-kibibyte (KiB), записанным в журналах при настройке ведения журнала. Настоятельно рекомендуется использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером. Дополнительные сведения см. в статье Monitorхранилища BLOB-объектов Azure.

Текст запроса

Никакой.

Ответ

Ответ включает код состояния HTTP, набор заголовков ответов и текст ответа.

Код состояния

Успешная операция возвращает код состояния 200 (ОК).

Сведения о кодах состояния см. в коды состояния и коды ошибок.

Коды ошибок ответа

Ответ для этой операции содержит следующие заголовки. Ответ также может включать дополнительные стандартные заголовки HTTP. Все стандартные заголовки соответствуют спецификации протокола HTTP/1.1.

Заголовок ответа	Описание
x-ms-blob-public-access	Указывает, могут ли данные в контейнере получать общедоступный доступ и уровень доступа. Возможные значения: - container. Указывает полный открытый доступ на чтение для данных контейнера и BLOB-объектов. Клиенты могут перечислять большие двоичные объекты в контейнере с помощью анонимного запроса, но они не могут перечислять контейнеры в учетной записи хранения. - blob: Указывает общедоступный доступ на чтение больших двоичных объектов. Данные BLOB-объектов в этом контейнере можно считывать с помощью анонимного запроса, но данные контейнера недоступны. Клиенты не могут перечислять большие двоичные объекты в контейнере с помощью анонимного запроса. - true: только версии 2016-05-31. Указывает, что контейнер был помечен для полного общедоступного доступа на чтение с помощью версии выше 2009-09-19. По состоянию на версию 2016-05-31 это значение возвращается как container. Если этот заголовок не возвращается в ответе, контейнер является частным для владельца учетной записи.
ETag	Тег сущности для контейнера. Если версия запроса — 2011-08-18 или более поздняя, значение ETag заключено в кавычки.
Last-Modified	Возвращает дату и время последнего изменения контейнера. Формат даты следует RFC 1123. Дополнительные сведения см. в разделе Представление значений даты и времени в кодах ошибок. Любая операция, которая изменяет контейнер или его свойства или метаданные, обновляет время последнего изменения. Операции с большими двоичными объектами не влияют на время последнего изменения контейнера.
x-ms-request-id	Уникально идентифицирует выполненный запрос и может использоваться для устранения неполадок запроса. Дополнительные сведения см. в статье Устранение неполадок с операциями API.
x-ms-version	Указывает версию службы, которая использовалась для выполнения запроса. Этот заголовок возвращается для запросов, выполненных в отношении версии 2009-09-19 и более поздних версий.
Date	Значение даты и времени в формате UTC, созданное службой, указывающее время, когда был инициирован ответ.
x-ms-client-request-id	Можно использовать для устранения неполадок запросов и их соответствующих ответов. Значение этого заголовка равно значению заголовка x-ms-client-request-id, если оно присутствует в запросе, а значение содержит не более 1024 видимых символов ASCII. Если в запросе отсутствует заголовок x-ms-client-request-id, этот заголовок отсутствует в ответе.

Текст ответа

Если для контейнера была указана политика доступа на уровне контейнера, Get Container ACL возвращает подписанный идентификатор и политику доступа в тексте ответа.

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

Пример ответа

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-blob-public-access: container  
Date: Sun, 25 Sep 2011 20:28:22 GMT  
ETag: "0x8CAFB82EFF70C46"  
Last-Modified: Sun, 25 Sep 2011 19:42:18 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
  
<?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>  
  

Авторизация

Авторизация требуется при вызове любой операции доступа к данным в службе хранилища Azure. Вы можете авторизовать операцию Get Container ACL, как описано ниже.

Важный

Корпорация Майкрософт рекомендует использовать идентификатор Microsoft Entra с управляемыми удостоверениями для авторизации запросов в службу хранилища Azure. Идентификатор Microsoft Entra обеспечивает более высокую безопасность и удобство использования по сравнению с авторизацией общего ключа.

идентификатора Microsoft Entra (рекомендуется)

Служба хранилища Azure поддерживает использование идентификатора Microsoft Entra для авторизации запросов к данным BLOB-объектов. С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности. Субъект безопасности может быть пользователем, группой, субъектом-службой приложений или управляемым удостоверением Azure. Субъект безопасности проходит проверку подлинности с помощью идентификатора Microsoft Entra для возврата маркера OAuth 2.0. Затем маркер можно использовать для авторизации запроса к службе BLOB-объектов.

Дополнительные сведения об авторизации с помощью идентификатора Microsoft Entra см. в статье Авторизация доступа к большим двоичным объектам с помощью идентификатора Microsoft Entra ID.

Разрешения

Ниже приведены действия RBAC, необходимые для пользователя Microsoft Entra, группы, управляемого удостоверения или субъекта-службы для вызова операции Get Container ACL и минимально привилегированной встроенной роли Azure RBAC, которая включает в себя следующее:

• действие Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/container/getAcl/action
• встроенная роль с минимальными привилегиями:владельца данных BLOB-объектов хранилища

Дополнительные сведения о назначении ролей с помощью Azure RBAC см. в статье Назначение роли Azure для доступа к данным BLOB-объектов.

общий ключ

Операция поддерживаетавторизации общего ключа . Авторизация с помощью ключей учетных записей не рекомендуется для большинства сценариев, так как она менее безопасна.

Корпорация Майкрософт рекомендует запретить авторизацию общего ключа для учетной записи хранения, когда это возможно. Дополнительные сведения см. в разделе Запрет авторизации с помощьюобщего ключа.

Замечания

Никакой. Сведения о выставлении счетов см. в о том, как эта операция влияет на затраты.

Выставления счетов

Запросы цен могут возникать от клиентов, использующих API хранилища BLOB-объектов, непосредственно через REST API хранилища BLOB-объектов или из клиентской библиотеки службы хранилища Azure. Эти запросы начисляют плату за транзакцию. Тип транзакции влияет на то, как взимается учетная запись. Например, транзакции чтения начисляются в другую категорию выставления счетов, чем операции записи. В следующей таблице показана категория выставления счетов для запросов Get Container ACL на основе типа учетной записи хранения:

Операция	Тип учетной записи хранения	Категория выставления счетов
Получение списка ACL контейнера	Большой двоичный объект класса Premium Стандартный общего назначения версии 2	Другие операции
Получение списка ACL контейнера	Стандартный общего назначения версии 1	Операции чтения

Дополнительные сведения о ценах на указанную категорию выставления счетов см. в цен на хранилище BLOB-объектов Azure.

См. также

Ограничить доступ к контейнерам и большим двоичным объектам
Определение хранимой политики доступа
задать списка ACL контейнера
Авторизация запросов в службу хранилища Azure
коды состояния и ошибок
коды ошибок хранилища BLOB-объектов