Чтобы данные в Object Storage были надежно защищены, разграничьте доступ к ресурсам хранилища. Рядовые пользователи будут просматривать содержимое бакета, создатели бакетов — скачивать и загружать объекты, а администратор проекта — настраивать хранилище.
В Object Storage используются три механизма контроля доступа: роли пользователей, ACL и Bucket Policy.
Роли содержат наборы разрешений, которые описывают допустимые для пользователей операции. Роль пользователя может разрешать действия как отдельного сервиса, так и всех сервисов платформы. На более низком уровне за доступ ролей к операциям с хранилищем отвечают действия — их можно использовать при создании пользовательских ролей.
ACL (Access Control List) разрешает действия с бакетами и объектами на основе списка, в котором перечислены пользователи и их уровни доступа. ACL создается для каждого бакета и хранится в самом Object Storage.
Bucket Policy проверяет, соответствует ли операция настроенной политике доступа. С помощью политики можно указать дополнительные правила взаимодействия с ресурсами хранилища. Например, запретить или разрешить доступ к бакету для конкретных IP-адресов.
Как работает контроль доступа
Когда запрос поступает в систему, механизмы контроля доступа проверяют разрешения по определенному алгоритму. Ниже приведена упрощенная схема проверок доступа.
Проверки выполняются в следующем порядке:
Система проверяет, есть ли в HTTP-заголовке подпись. Если в заголовке запроса:
есть подпись — выполняется проверка роли пользователя в проекте;
нет подписи — выполняется проверка Bucket Policy.
Система проверяет, есть ли у пользователя из запроса роль, которая позволит выполнить операцию. Если роль:
позволяет выполнить действие — проверяется наличие Bucket Policy для ресурса;
не назначена или не позволяет выполнить действие — запрещает доступ;
имеет полные права на действия с хранилищем — разрешает доступ.
Для ролей с полным доступом следующие шаги алгоритма не выполняются — проверки Bucket Policy и ACL игнорируются. Полным доступом обладают роли, которым разрешено действие s3e.tenant.edit:
сервисная роль s3e.admin;
пользовательская роль, которой действие s3e.tenant.edit было назначено вручную или через наследование прав s3e.admin;
проектная роль Администратор проекта.
Система проверяет, есть ли правила Bucket Policy для ресурса из запроса. Если:
правило есть и запрос попадает под правило Allow — разрешает доступ;
правило есть и запрос попадает под правило Deny — запрещает доступ;
Если в системе нет ни одной политики или запрос не подходит ни к одному правилу — выполняется проверка ACL;
Система сверяет данные в запросе со списком ACL. Если в списке:
есть разрешение — разрешает доступ;
нет разрешений — запрещает доступ.
Что и когда использовать
Выбор настройки доступа зависит от сложности проекта и объема хранилища.
Роли подойдут для несложных сценариев и небольшого хранилища, когда достаточно разрешить или ограничить доступ к ресурсам в соответствии с набором прав. Управлять ролями можно прямо в интерфейсе сервиса, тогда как настройки ACL и Bucket Policy передаются с помощью API.
ACL можно использовать, если набора ролей недостаточно, а для некоторых бакетов хранилища требуются индивидуальные настройки доступа. С помощью ACL вы можете открыть публичный доступ к конкретному бакету для всех пользователей интернета.
Bucket Policy лучше использовать, когда объектов в хранилище очень много и важно точно указать, при каких условиях разрешать действия с ресурсами. С помощью политик вы можете разрешить скачивать объекты только с конкретного пула IP-адресов или запретить ряд операций с конкретным объектом в бакете.