All Products
Search

This Product

    Object Storage Service:Control access to OSS resources with RAM policies

    Document Center

    Object Storage Service:Control access to OSS resources with RAM policies

    Last Updated:Jun 01, 2026

    A RAM policy is an identity-based policy that defines which RAM identity can perform what operations on which OSS resources under what conditions. Use RAM policies to enforce fine-grained access control across your OSS resources.

    How it works

    RAM policies authorize Resource Access Management (RAM) identities — RAM users, user groups, and RAM roles. When OSS receives a request, it evaluates all applicable policies (RAM policies and bucket policies) and determines access in the following order:

    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 policy types: system policies (predefined by Alibaba Cloud, read-only) and custom policies (created and managed by you).

    Grant permissions using system policies

    Grant predefined system policies to a RAM user in the RAM console:

    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

    To use a custom policy, create it first and then attach 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).

        All supported policy elements are documented in 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

    Attach the custom policy 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 demonstrate common RAM policy configurations. Modify the bucket names, paths, and IP addresses to match your environment.

    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

    Grant a RAM user read-only access to mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/. The policy complexity varies by access method:

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

      Use this policy when the user knows the exact file paths.

      {
  "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 user needs to browse folder contents, 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.

      The OSS console requires navigating from the root directory to reach mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/, so additional list permissions are needed:

      {
  "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 Deny takes precedence, access from an IP address outside the 192.168.0.0/16 range is denied.

    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

    Follow these best practices to minimize data breach risks and enforce precise permission control:

    • Follow the principle of least privilege: Grant only the minimum permissions required. Avoid broad permissions such as oss:* unless absolutely necessary.

    • Use RAM roles and STS temporary credentials: For applications on ECS instances or in containers, use RAM roles with STS temporary credentials instead of long-term AccessKey pairs. Temporary credentials expire automatically, eliminating the risk of hard-coded secrets.

    • Separate human users and programmatic users: Create separate RAM users for people and applications to enable 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:

      • Never hard-code AccessKey pairs in project code.

      • Use STS temporary credentials or environment variables for access authorization.

      • Rotate your AccessKey pairs regularly.

    • RAM role security recommendations:

      • Do not change a RAM role's trusted entity without careful consideration — this may create over-authorization risks.

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

    • Audit permissions regularly: Review and remove unneeded RAM users and policies to keep permissions aligned with current business needs.

    • Use Condition to enhance security: Add Condition elements to restrict access by source IP address, VPC, or other dimensions.

    References