All Products
Search

This Product

    Object Storage Service:RAM Policy

    Document Center

    Object Storage Service:RAM Policy

    Last Updated:Feb 03, 2026

    A RAM policy is an authorization policy that you attach to a Resource Access Management (RAM) identity, such as a user, user group, or role. To manage access to Object Storage Service (OSS) resources for RAM users or roles, use a RAM policy to define the operations the identity can perform and the resources it can access.

    How it works

    RAM policies use an identity-based authorization model. A policy is attached to a RAM user, user group, or RAM role. It defines what actions the identity can perform on which resources under what conditions.

    When a RAM identity makes an access request, OSS evaluates all relevant policies, including RAM policies and bucket policies. Permission evaluation follows the explicit deny first principle:

    1. Explicit deny first: If any policy contains an explicit "Effect": "Deny" rule that matches the request, the request is immediately denied.

    2. Find an explicit allow: If no matching Deny rule exists, the system searches for an explicit "Effect": "Allow" rule that matches the request. If a match is found, the request is allowed.

    3. Default deny: If no matching Deny or Allow rule exists, the request is denied by default.

    OSS supports two types of RAM policies. System policies are preset by Alibaba Cloud. You can use them but cannot modify them. Custom policies are created and maintained by you and provide more flexible permission configurations.

    Grant permissions using system policies

    System policies are created by Alibaba Cloud. You can grant these permissions to an identity directly in the Resource Access Management (RAM) console. The following steps describe how to grant permissions to a RAM user.

    1. Go to the RAM user list. In the Actions column of the target user, click Add Permissions.

    2. In the search box, enter the name of the system policy and select it. OSS supports the following two system policies:

    3. Click Confirm New Authorization to complete the permission settings.

    Grant permissions using custom policies

    You can create and maintain custom policies. To grant permissions using a custom policy, you must first create the custom policy and then grant it to the target identity.

    Step 1: Create a custom policy

    1. Go to the Policies list. Click Create Policy.

    2. Select Edit Script. In the editor, enter the authorization policy in JSON format. You can use the RAM Policy Editor to quickly generate an authorization policy.

      The following example policy grants full control over the example-bucket bucket and all resources within it.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:*",
      "Resource": [
        "acs:oss:*:*:example-bucket",
        "acs:oss:*:*:example-bucket/*"
      ]
    }
  ]
}

      A complete authorization policy includes a Version and one or more Statements.

      • Version: The version of the access policy. The value is fixed at 1 and cannot be changed.

      • Statement: The main body of the policy. It contains one or more specific allow or deny rules. Each statement includes Effect, Action, Resource, and Condition.

        Policy Element

        Description

        Effect

        The effect of the policy. Valid values are Allow and Deny.

        Action

        The specific operation to perform on the resource. The wildcard character * is supported.

        Resource

        The scope of resources to which the policy applies.

        Condition

        The conditions for the policy to take effect.

        If you configure multiple conditions, the policy takes effect only when all conditions are met (a logical AND).

        For a complete list of authorization elements, see OSS authorization syntax and elements.

    3. Click OK. Enter a Policy Name, and then click OK to create the custom policy.

    Step 2: Grant permissions to an identity

    After you create a custom policy, you must grant it to the target identity. The following steps describe how to grant permissions to a RAM user.

    1. Go to the RAM user list. In the Actions column of the target user, click Add Permissions.

    2. In the search box, enter the name of the custom policy and select it.

    3. Click Confirm New Authorization to complete the permission settings.

    Common authorization scenarios

    The following scenarios show typical applications of RAM policies in real-world business. They cover various needs, such as permission granting, access restriction, and security control. Each scenario provides a complete policy configuration example. You can modify parameters, such as bucket names and folder paths, as needed and use the policies directly.

    Scenario 1: Grant a RAM user full control over a bucket

    The following example grants a RAM user full control over a bucket named mybucket.

    Important

    For mobile applications, granting users full control over a bucket poses a very high security risk and should be avoided whenever possible.

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:*",
      "Resource": [
        "acs:oss:*:*:mybucket",
        "acs:oss:*:*:mybucket/*"
      ]
    }
  ]
}

    Scenario 2: Deny a RAM user permission to delete files that match a specific pattern in a bucket

    The following example denies a RAM user permission to delete all files that have the prefix `abc` and the `.txt` format in a bucket named mybucket.

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteObject"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket/abc*.txt"
      ]
    }
  ]
}

    Scenario 3: Grant a RAM user permission to list and read all resources in a bucket

    • The following example grants a RAM user permission to list and read all resources in a bucket named mybucket using an OSS SDK or the command line interface (CLI).

      Note

      The `ListObjects` operation (Action) must use the entire bucket as the Resource.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:ListObjects",
      "Resource": "acs:oss:*:*:mybucket"
    },
    {
      "Effect": "Allow",
      "Action": "oss:GetObject",
      "Resource": "acs:oss:*:*:mybucket/*"
    }
  ]
}

    • The following example grants a RAM user permission to list and read all resources in a bucket named mybucket using the OSS console.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListBuckets",
        "oss:GetBucketStat",
        "oss:GetBucketInfo",
        "oss:GetBucketTagging",
        "oss:GetBucketLifecycle",
        "oss:GetBucketWorm",                      
        "oss:GetBucketVersioning", 
        "oss:GetBucketAcl" 
      ],    
      "Resource": "acs:oss:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListObjects",
        "oss:GetBucketAcl"
      ],
      "Resource": "acs:oss:*:*:mybucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetObject",
        "oss:GetObjectAcl"
      ],
      "Resource": "acs:oss:*:*:mybucket/*"
    }
  ]
}

    Scenario 4: Deny a RAM user permission to delete a bucket

    The following example denies a RAM user permission to delete a bucket named mybucket.

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:*",
      "Resource": [
        "acs:oss:*:*:mybucket",
        "acs:oss:*:*:mybucket/*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteBucket"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket"
      ]
    }
  ]
}

    Scenario 5: Grant a RAM user permission to access multiple folders in a bucket

    Assume that a bucket named mybucket is used to store photos. This bucket contains several folders that represent photo locations. Each location folder contains year subdirectories.

    mybucket[Bucket]
  ├── beijing
  │   ├── 2014
  │   └── 2015
  └── hangzhou
      ├── 2014
      └── 2015

    You need to grant a RAM user read-only permission to access the mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/ folders. Folder-level authorization is an advanced feature. The complexity of the authorization policy varies based on the scenario. The following examples are for your reference.

    • Grant a RAM user permission to read only the content of files in the mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/ folders.

      Because the RAM user knows the full path of the files, we recommend that you use the full file paths to read the file content.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetObject"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket/hangzhou/2014/*",
        "acs:oss:*:*:mybucket/hangzhou/2015/*"
      ]
    }
  ]
}

    • Grant a RAM user permission to use the OSS CLI to access the mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/ folders and list the files in them.

      If the RAM user does not know which files are in the folders, they can use the OSS CLI or an API to directly obtain folder information. In this scenario, you must add the ListObjects permission.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetObject"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket/hangzhou/2014/*",
        "acs:oss:*:*:mybucket/hangzhou/2015/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListObjects"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket"
      ],
      "Condition":{
        "StringLike":{
          "oss:Prefix": [
            "hangzhou/2014/*",
            "hangzhou/2015/*"
          ]
        }
      }
    }
  ]
}

    • Grant a RAM user permission to access folders using the OSS console.

      When using the OSS console to access the mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/ folders, the RAM user can start from the root directory and navigate through the layers to the target folder.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListBuckets",
        "oss:GetBucketStat",
        "oss:GetBucketInfo",
        "oss:GetBucketTagging",
        "oss:GetBucketLifecycle",
        "oss:GetBucketWorm",                      
        "oss:GetBucketVersioning", 
        "oss:GetBucketAcl" 
      ], 
      "Resource": [
        "acs:oss:*:*:*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetObject",
        "oss:GetObjectAcl"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket/hangzhou/2014/*",
        "acs:oss:*:*:mybucket/hangzhou/2015/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListObjects"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket"
      ],
      "Condition": {
        "StringLike": {
          "oss:Delimiter": "/",
          "oss:Prefix": [
            "",
            "hangzhou/",
            "hangzhou/2014/*",
            "hangzhou/2015/*"
          ]
        }
      }
    }
  ]
}

    Scenario 6: Deny a RAM user permission to delete any file in a bucket

    The following example denies a RAM user permission to delete any file in a bucket named mybucket.

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteObject"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket/*"
      ]
    }
  ]
}

    Scenario 7: Deny a RAM user permission to access objects with specific tags

    The following `Deny` policy denies a RAM user permission to access objects with the tags status:ok and key1:value1 in the examplebucket bucket.

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:GetObject"
      ],
      "Resource": [
        "acs:oss:*:174649585760xxxx:examplebucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "oss:ExistingObjectTag/status":"ok",
          "oss:ExistingObjectTag/key1":"value1"
        }
      }
    }
  ]
}

    Scenario 8: Grant a RAM user permission to access OSS from specific IP addresses

    • Add an IP address restriction to an Allow authorization.

      The following example adds an IP address restriction to an Allow authorization. It grants a RAM user permission to read all resources in a bucket named mybucket only from the 192.168.0.0/16 and 198.51.100.0/24 IP address ranges.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListBuckets",
        "oss:GetBucketStat",
        "oss:GetBucketInfo",
        "oss:GetBucketTagging",
        "oss:GetBucketAcl" 
      ], 
      "Resource": [
        "acs:oss:*:*:*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListObjects",
        "oss:GetObject"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket",
        "acs:oss:*:*:mybucket/*"
      ],
      "Condition":{
        "IpAddress": {
          "acs:SourceIp": ["192.168.0.0/16", "198.51.100.0/24"]
        }
      }
    }
  ]
}

    • Add an IP address restriction to a Deny authorization.

      The following example adds an IP address restriction to a Deny authorization. It denies a RAM user whose source IP address is not in the 192.168.0.0/16 range from performing any operation on OSS.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListBuckets",
        "oss:GetBucketStat",
        "oss:GetBucketInfo",
        "oss:GetBucketTagging",
        "oss:GetBucketAcl" 
      ], 
      "Resource": [
        "acs:oss:*:*:*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListObjects",
        "oss:GetObject"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket",
        "acs:oss:*:*:mybucket/*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": "oss:*",
      "Resource": [
        "acs:oss:*:*:*"
      ],
      "Condition":{
        "NotIpAddress": {
          "acs:SourceIp": ["192.168.0.0/16"]
        }
      }
    }
  ]
}
      Note

      Because the authentication rule for access policies is "Deny first", if a user tries to access content in mybucket from an IP address outside the 192.168.0.0/16 range, OSS reports a permission error.

    Scenario 9: Grant permissions to other users through RAM or STS

    Grant a user with the IP address 192.168.0.1 permission to perform the following operations using a Java SDK client through RAM or Security Token Service (STS).

    • List objects that have the prefix foo in the mybucket bucket.

    • Upload, download, and delete objects that have the prefix file in the mybucket bucket.

    {
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "oss:GetBucketAcl",
        "oss:ListObjects"
      ],
      "Resource": [
        "acs:oss:*:177530505652xxxx:mybucket"
      ],
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "acs:UserAgent": "java-sdk",
          "oss:Prefix": "foo"
        },
        "IpAddress": {
          "acs:SourceIp": "192.168.0.1"
        }
      }
    },
    {
      "Action": [
        "oss:PutObject",
        "oss:GetObject",
        "oss:DeleteObject"
      ],
      "Resource": [
        "acs:oss:*:177530505652xxxx:mybucket/file*"
      ],
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "acs:UserAgent": "java-sdk"
        },
        "IpAddress": {
          "acs:SourceIp": "192.168.0.1"
        }
      }
    }
  ]
}

    Scenario 10: Prohibit setting the ACLs of buckets and objects to public access

    The following example prohibits setting the access control lists (ACLs) of buckets and objects to public to ensure OSS data security.

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:PutBucket",
        "oss:PutBucketAcl"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "oss:x-oss-acl": "private"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:PutObject",
        "oss:PutObjectAcl"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "oss:x-oss-object-acl": [
            "private",
            "default"
          ]
        }
      }
    }
  ]
}

    Scenario 11: Grant a RAM user permission to use IMM-related features

    The following RAM policy grants a RAM user permission to use the document processing feature of Intelligent Media Management (IMM).

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetObject",
        "oss:PutObject",
        "oss:PostProcessTask",
        "oss:ProcessImm"
      ],
      "Resource": "*"
    },
    {
      "Action": [
        "imm:CreateOfficeConversionTask",
        "imm:GetWebofficeURL"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Effect": "Allow",
      "Action": "ram:PassRole",
      "Resource": "acs:ram:*:*:role/aliyunimmdefaultrole"
    }
  ]
}

    Scenario 12: Grant a RAM user permission to change the storage redundancy type

    • Grant a RAM user permission to change the storage redundancy type of a specific bucket.

      The following example grants a RAM user permission to change the storage redundancy type of the mybucket bucket.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:CreateBucketDataRedundancyTransition",
        "oss:GetBucketDataRedundancyTransition",
        "oss:ListBucketDataRedundancyTransition",
        "oss:DeleteBucketDataRedundancyTransition"
      ],
      "Resource": "acs:oss:*:*:mybucket"
    }
  ]
}

    • Grant a RAM user permission to change the storage redundancy type of all buckets.

      Important

      The following example grants a RAM user permission to change the storage redundancy type of all buckets under your Alibaba Cloud account. Proceed with caution.

      {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:CreateBucketDataRedundancyTransition",
        "oss:GetBucketDataRedundancyTransition",
        "oss:ListBucketDataRedundancyTransition",
        "oss:DeleteBucketDataRedundancyTransition"
      ],
      "Resource": "acs:oss:*:*:*"
    }
  ]
}

    Scenario 13: Grant a RAM user permission to create orders for OSS resource plans

    The following RAM policy grants a RAM user permission to create orders for OSS resource plans.

    Important

    After a RAM user creates an order for an OSS resource plan, they can contact the Alibaba Cloud account owner to complete the payment. To allow the RAM user to pay for the order, the Alibaba Cloud account owner must grant the RAM user the bss:PayOrder permission. The bss:PayOrder permission is a high-risk permission that involves financial operations. Do not grant this permission unless it is necessary.

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:CreateOrder",
      "Resource": "acs:oss:*:*:*"
    }
  ]
}

    Scenario 14: Grant a RAM user permission to activate OSS

    The following RAM policy grants a RAM user permission to activate OSS.

    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:ActivateProduct",
      "Resource": "acs:oss:*:*:*"
    }
  ]
}

    Scenario 15: Grant a RAM user permission to read and write data in buckets with specific tags

    The following RAM policy grants a RAM user permission to read and write data in buckets that have a specific tag. The tag key is `key1` and the tag value is `value1`.

    {
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "oss:ListBuckets",
        "oss:GetBucketStat",
        "oss:GetBucketInfo",
        "oss:GetBucketAcl",
        "oss:ListObjects",
        "oss:PutObject",
        "oss:GetObject"
      ],
      "Resource": [
        "acs:oss:*:*:*"
      ],
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "oss:BucketTag/key1": "value1"
        }
      }
    }
  ]
}
    Note

    After the policy takes effect, the RAM user can perform the specified operations only on OSS buckets that have the tag key1=value1. The behavior varies based on the access method:

    • When you use an OSS SDK or ossutil to send a ListBuckets request, you must add tag filtering parameters, such as tag-key=key1,tag-value=value1. If the policy is configured correctly, the response returns only the buckets that match the specified tag conditions.

    • When you use the OSS console to send a ListBuckets request, the request is denied because the console cannot attach tag parameters. The request does not meet the policy condition (oss:BucketTag/key1=value1), and the system reports a permission error.

    • Other operations, such as PutObject and GetObject, are also subject to the tag condition. The target bucket for the operation must have the tag key1=value1.

    Best practices for production environments

    When you configure RAM policies and manage RAM identities, follow these security best practices. This can effectively reduce the risk of data breaches and ensure precise permission control:

    • Follow the principle of least privilege: Always grant only the minimum set of permissions required to perform a task. Avoid broad permissions, such as oss:*, unless absolutely necessary. The principle of least privilege reduces the potential attack surface and lowers the risk of permission abuse and operational errors.

    • Use RAM roles and STS temporary credentials: For applications, especially those deployed on ECS instances or in containers, use RAM roles and obtain temporary credentials from STS to access OSS. Unlike long-term AccessKey pairs, temporary credentials expire automatically. This practice avoids the need to hard-code long-term AccessKey pairs in your code or configuration files, which significantly reduces the risk of AccessKey pair leaks.

    • Separate human users and programmatic users: Create separate RAM users for different people and applications. This allows for specialized identity management and fine-grained permission control.

      • Human users: Set up console access. Use an account and password to access the product console. We recommend that you enable multi-factor authentication (MFA).

      • Programmatic users: Set up programmatic access with a permanent AccessKey pair. Use the AccessKey pair to call APIs to access cloud resources.

    • AccessKey pair security management:

      • Do not save the AccessKey ID and AccessKey secret of a RAM user in your project code. This practice can lead to an AccessKey pair leak.

      • We recommend that you use methods such as STS or environment variables to obtain access authorization.

      • Rotate your AccessKey pairs regularly.

    • RAM role security recommendations:

      • After you create a RAM role, do not change its trusted entity without careful consideration. This change can affect your business or create over-authorization risks.

      • Set a reasonable validity period for STS tokens. Avoid long validity periods to prevent security risks.

    • Audit permissions regularly: Periodically review and clean up unneeded RAM users and access policies. This practice ensures that permissions align with current business needs.

    • Use Condition to enhance security: You can add a Condition element to your policies. For example, you can restrict the source IP address or VPC. Using multi-dimensional conditional constraints adds an extra layer of security to data access.

      Important

      When you configure a bucket policy or RAM policy, do so based on your network access architecture. Configure both the acs:SourceIp and acs:SourceVpc conditions for dual access control. Using only one condition can create security risks. For example, if you restrict access only by public IP address, a VPC can still gain unauthorized access using a matching egress IP address.

    References