Object Storage Service:Control access to OSS by using RAM policies

OSS storage model

OSS uses a flat storage model, which stores objects as key-value pairs directly within a bucket. No physical directory hierarchy exists. The folders that you see in the console are simulated using object key prefixes and a separator (/). This lets you group, classify, and manage objects.

For the examplebucket bucket, the folder structure and corresponding Object Keys are displayed in the console as follows:

examplebucket
├── Development/                     # Key: Development/ (folder object)
│   ├── Alibaba Cloud.pdf            # Key: Development/Alibaba Cloud.pdf
│   ├── ProjectA.docx                # Key: Development/ProjectA.docx
│   └── ProjectB.docx                # Key: Development/ProjectB.docx
├── Marketing/                       # Key: Marketing/ (folder object)
│   ├── data2020.xlsx                # Key: Marketing/data2020.xlsx
│   └── data2021.xlsx                # Key: Marketing/data2021.xlsx
├── Private/                         # Key: Private/ (folder object)
│   └── 2017/                        # Key: Private/2017/ (folder object)
│       ├── images.zip               # Key: Private/2017/images.zip
│       └── promote.pptx             # Key: Private/2017/promote.pptx
└── oss-dg.pdf                       # Key: oss-dg.pdf

The key of a folder object ends with /. OSS uses this as a flag to identify the object as a folder. However, all objects, including folder objects, are stored in a flat structure.

Because OSS does not have a real directory hierarchy, when you grant access to a folder, you are actually granting access to all objects that have a specific prefix. For example, granting access to the Development/ folder is equivalent to granting access to all objects whose keys start with Development/.

Differences in requests for buckets, folders, and files

Operations on different targets, such as buckets, folders, and files, correspond to different API requests and Resource configurations. Understanding these differences is key to correctly configuring access policies.

GET /?prefix=Development/&delimiter=/ HTTP/1.1
Host: examplebucket.oss-cn-hangzhou.aliyuncs.com

Differences between console and API/SDK access

Accessing OSS through the console requires more permissions than accessing it directly using an API or SDK. This is because a user needs to navigate from the bucket list to the target folder.

Policy design approach

To grant read and write access to the Development/ folder, you need to grant two types of permissions:

1. List permission: Allows a user to list the objects in the Development/ folder (oss:ListObjects). A Condition restricts the listing to objects that start with the Development prefix.

2. Read and write permissions: Grants permission to read (oss:GetObject) and upload (oss:PutObject) files in the Development/ folder. The Resource element points to examplebucket/Development/*.

Create and grant the policy

1. Go to the RAM Policies page and click Create Policy.

2. Select the Script Editor tab and enter the following policy content:

   {
     "Version": "1",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "oss:ListObjects",
         "Resource": "acs:oss:*:*:examplebucket",
         "Condition": {
           "StringLike": {
             "oss:Prefix": [
               "Development",
               "Development/*"
             ]
           }
         }
       },
       {
         "Effect": "Allow",
         "Action": [
           "oss:GetObject",
           "oss:PutObject",
           "oss:GetObjectAcl"
         ],
         "Resource": "acs:oss:*:*:examplebucket/Development/*"
       }
     ]
   }

   Policy analysis:

   • First Statement: Grants the list permission on the bucket. The Condition with oss:Prefix restricts the listing to content within the Development folder and its subfolders.

   • Second Statement: Grants read and write permissions. The Resource points to all objects in the Development/* path.

3. Click OK. Enter a Policy Name, such as AllowAnneAccessDevelopment, and click OK to create the policy.

4. Go to the User List page. Find the RAM user Anne, click Add Permissions, and select the policy that you just created.

Create a user group and add members

1. Go to the RAM User Groups page and click Create User Group. For example, name it DenyPrivateAccessGroup.

2. Click Add Members and add the RAM users who should be denied access to the Private/ folder to the user group.

Create and grant the deny policy

1. Go to the RAM Policies page and click Create Policy.

2. Select the Script Editor tab and enter the following policy content:

   {
     "Version": "1",
     "Statement": [
       {
         "Effect": "Deny",
         "Action": "oss:*",
         "Resource": "acs:oss:*:*:examplebucket/Private/*"
       },
       {
         "Effect": "Deny",
         "Action": "oss:ListObjects",
         "Resource": "acs:oss:*:*:examplebucket",
         "Condition": {
           "StringLike": {
             "oss:Prefix": [
               "Private/",
               "Private/*"
             ]
           }
         }
       }
     ]
   }

   Policy analysis:

   • First Statement: Denies all operations on any object under the Private/ path.

   • Second Statement: Denies listing the contents of the Private/ folder to prevent users from viewing the file list.

3. Click OK. Enter a Policy Name, such as DenyAccessPrivateFolder, and click OK to create the policy.

4. Go to the RAM User Groups page. For the user group, click Add Permissions and select the policy that you just created.

When a RAM user in the group tries to access the Private/ folder, OSS returns a permission denied error, regardless of whether the user is trying to list or download files.