DocsICP FilingConsole
Documentation
Home Page Object Storage Service User Guide Permission and Access Control RAM Policy

RAM Policy

Updated at:
Copy as MD
Product
My Favorites

RAM Policy is an authorization policy attached to a RAM identity (users, user groups, roles). When you need to manage the access permissions of RAM users or roles to OSS resources, you can use RAM Policy to define the operations that the identity can perform and the scope of resources that it can access.

How it works

RAM Policy uses an identity-based authorization model. The policy is attached to a RAM user, user group, or RAM role and defines which operations (Action) the identity can perform on which resources (Resource) under which conditions (Condition).

When a RAM identity initiates an access request, OSS comprehensively evaluates all related policies (including RAM Policy and Bucket Policy). Permission decisions follow the explicit deny priority principle:

  1. Explicit deny priority: If any policy contains a Deny rule that matches the request, the request is immediately denied.

  2. Search for explicit allow: If no Deny rule matches, and an Allow rule matches the request, the request is allowed.

  3. Default deny: If neither a Deny rule nor an Allow rule matches, the request is denied by default.

OSS supports two types of RAM policies: system policies are predefined by Alibaba Cloud and users can only use but not modify them; custom policies are created and maintained by users, providing more flexible permission configuration.

Granting system policies

System policies are created by Alibaba Cloud. You can directly grant them to user identities in the RAM console. The following uses a RAM user as an example to demonstrate the authorization steps.

  1. Go to the RAM Users page and click Add Permissions in the Actions column of the target user.

  2. In the Add Permissions panel, the resource scope defaults to Account level. To grant permissions to a specific resource group, select Resource group level.

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

  4. Click OK to complete the permission configuration.

Granting custom policies

Custom policies are created and maintained by users. To grant a custom policy, you must first create the custom policy and then grant it to the corresponding user identity.

Step 1: Create a custom policy

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

  2. Select Edit Script and enter the JSON-formatted authorization policy in the editor. You can use the RAM Policy Editor to quickly generate an authorization policy.

    Example authorization policy: Allows all operations on example-bucket and all resources within that bucket.

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

    A complete authorization policy consists of Version (version number) and Statement (authorization statements).

    • Version: The version of the policy, which is fixed at 1 and cannot be modified.

    • Statement: The main body of the policy, containing one or more specific allow/deny rules. Each authorization statement consists of Effect (authorization effect), Action (authorized operations), Resource (authorized resources), and Condition (authorization conditions).

      Policy element

      Description

      Effect

      The effect of the policy. Valid values: Allow (allow) or Deny (deny).

      Action

      The specific operations to perform on resources. Supports the use of the wildcard *.

      Resource

      The scope of resources to which the policy applies.

      Condition

      The condition under which the policy takes effect.

      When multiple conditions are configured, all conditions must be met simultaneously (AND relationship) for the policy to take effect.

      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 complete the creation of the custom policy.

Step 2: Grant permissions to a user identity

After you create a custom policy, you need to grant it to the target user identity. The following uses a RAM user as an example to demonstrate the authorization steps.

  1. Go to the RAM Users page and click Add Permissions in the Actions column of the target user.

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

  3. Click OK to complete the permission configuration.

Common authorization scenarios

The following scenarios demonstrate typical applications of RAM Policy in real-world business, covering permission granting, access restrictions, and various security control requirements. Each scenario provides a complete policy configuration example. You can modify the bucket name, directory path, and other parameters in the examples based on your actual requirements.

Scenario 1: Grant a RAM user full control permissions on a bucket

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

Important

For mobile applications, granting a user full control permissions on a bucket poses an extremely high 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 from deleting files matching a specific pattern in a bucket

The following example denies a RAM user from deleting all files with the .txt extension whose prefix is abc 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 through the OSS SDK or OSS command-line tools.

    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 through 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 from deleting a bucket

The following example denies a RAM user from deleting 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 upload and delete files but deny deletion of the bucket

The following example grants a RAM user only the permissions to upload and delete files (including deleting object versions) in a bucket named mybucket, but denies the permission to delete the bucket itself. Unlike Scenario 4, which uses broad authorization with oss:*, this scenario specifies the allowed operations precisely, following the principle of least privilege.

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

Within the same policy, Deny statements take precedence over Allow statements. Therefore, while the RAM user has the oss:PutObject, oss:DeleteObject, and oss:DeleteObjectVersion permissions, the oss:DeleteBucket operation is explicitly denied.

Scenario 6: Grant a RAM user permission to access multiple directories in a bucket

Assume that the bucket used for storing photos is mybucket. This bucket contains several directories representing the locations where photos were taken, and each location directory contains year subdirectories.

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

You need to grant a RAM user read-only permission to the mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/ directories. Directory-level authorization is an advanced authorization feature. The complexity of the authorization policy varies depending on the usage scenario. The following scenarios are provided for reference.

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

    Since the RAM user knows the full paths of the files, we recommend using the complete file path to read the file content in the directory.

    {
  "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 OSS command-line tools to access the mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/ directories and list the files in the directories.

    If the RAM user does not know which files are in the directory, they can use OSS command-line tools or APIs to directly obtain directory information. In this scenario, you need to 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 directories through the OSS console.

    When accessing the mybucket/hangzhou/2014/ and mybucket/hangzhou/2015/ directories through the OSS console, the RAM user can start from the root directory and navigate level by level into the target directory.

    {
  "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 7: Deny a RAM user from deleting any file in a bucket

The following example denies a RAM user from deleting any file in a bucket named mybucket.

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

Scenario 8: Deny a RAM user from accessing objects with specified tags

The following Deny policy denies a RAM user from accessing objects with the tags status:ok and key1:value1 in a bucket named examplebucket.

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

Scenario 9: 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, granting a RAM user permission to read all resources in a bucket named mybucket only through the IP address ranges 192.168.0.0/16 and 198.51.100.0/24.

    {
  "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"]
        },
        "StringNotLike": {
          "acs:SourceVpc": [
            "vpc-*"
          ]
        }
      }
    }
  ]
}

  • Add an IP address restriction to a Deny authorization.

    The following example adds an IP address restriction to a Deny authorization, denying RAM users whose source IP addresses are not within the 192.168.0.0/16 range from performing any operations 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"]
        },
        "StringLike": {
          "acs:SourceVpc": [
            "*"
          ]
        }
      }
    }
  ]
}
    Note

    Since the authorization rule of permission policies is deny-first, when a visitor accesses content in mybucket from an IP address outside of 192.168.0.0/16, OSS returns a permission denied error.

Scenario 10: Grant permissions to other users through the RAM or STS service

Through the RAM or STS service, grant a user whose IP address is 192.168.0.1 the permission to use the Java SDK client to perform the following operations.

  • List objects prefixed with foo in mybucket.

  • Allow uploading, downloading, and deleting objects starting with file in mybucket.

{
  "Version": "1",
  "Statement": [{
    "Action": [
      "oss:GetBucketAcl",
      "oss:ListObjects"
    ],
    "Resource": [
      "acs:oss:*:177530505652xxxx:mybucket"
    ],
    "Effect": "Allow",
    "Condition": {
      "StringLike": {
        "acs:UserAgent": "*java-sdk*",
        "oss:Prefix": "foo"
      },
      "IpAddress": {
        "acs:SourceIp": "192.168.0.1"
      },
      "StringNotLike": {
        "acs:SourceVpc": [
          "vpc-*"
        ]
      }
    }
  },
    {
      "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"
        },
        "StringNotLike": {
          "acs:SourceVpc": [
            "vpc-*"
          ]
        }
      }
    }
  ]
}

Scenario 11: Deny setting the ACL of buckets and objects to public access

The following example denies setting the ACL of buckets and objects to public access, ensuring 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 12: Grant a RAM user permission to use IMM-related features

The following RAM Policy grants a RAM user the permission to use IMM document processing.

{
  "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 13: Grant a RAM user permission to change the storage redundancy type

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

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

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

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

    Important

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

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

Scenario 14: Grant a RAM user permission to create OSS resource plan, reserved capacity, and zone-redundant storage (ZRS) reserved capacity orders

The following RAM Policy grants a RAM user the permission to create OSS resource plan, reserved capacity, and zone-redundant storage (ZRS) reserved capacity orders.

Important

After a RAM user creates an OSS resource plan, reserved capacity, or zone-redundant storage (ZRS) reserved capacity order, the RAM user can contact the Alibaba Cloud account owner to complete the order payment. To enable a RAM user to complete OSS resource plan order payments, the Alibaba Cloud account owner must grant the RAM user the order payment permission bss:PayOrder. bss:PayOrder is a high-risk permission involving fund operations. Do not grant it unless necessary.

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

Scenario 15: Grant a RAM user permission to activate OSS

The following RAM Policy grants a RAM user the permission to activate OSS.

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

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

The following RAM Policy grants a RAM user the permission to read and write data in buckets with specified tags, where 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 only perform the specified operations on OSS buckets with the tag key1=value1. The behaviors of different access methods are as follows:

  • When you initiate a ListBuckets request through the OSS SDK or ossutil, you must add tag filtering parameters (for example, tag-key=key1, tag-value=value1). If the policy is correctly configured, the response will contain only buckets that match the specified tag conditions.

  • When you initiate a ListBuckets request through the OSS console, the request will be denied because the console cannot attach tag parameters and therefore does not meet the policy condition (oss:BucketTag/key1=value1). The system prompts that the permission is insufficient.

  • Other operations (such as PutObject and GetObject) are also subject to tag condition restrictions. The target bucket for the operation must meet the tag requirement of key1=value1.

Scenario 17: Grant a RAM user write-only permission (oss:PutObject)

The following RAM Policy grants a RAM user the permission to upload files to OSS, but not the permission to read or list buckets and objects.

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

After this policy is granted to a RAM user, the RAM user can upload files through ossutil or the SDK, but cannot use ls to list buckets or cp to download files. These two types of requests return a 403 AccessDenied error, which is the expected behavior when the policy takes effect. If you only need to grant write-only permission to a specific bucket, you can tighten the Resource scope to acs:oss:*:*:{bucket-name}/*. Do not use acs:oss:*:*:/*, as this is not a valid Resource format and cannot pass authorization verification.

This policy can be granted to a RAM user alone or to a RAM role alone. It is not necessary to grant it to both at the same time. If you access OSS through STS temporary credentials, the final permissions of the RAM user are the intersection of the RAM role permissions and the STS session policy. In this case, you can grant this write-only permission policy directly to the RAM role.

Applying to production environments

When configuring RAM Policy and managing RAM identities, follow the following security best practices to effectively reduce the risk of data leaks and ensure the precision of permission management:

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

  • Use RAM roles and STS temporary credentials: For applications, especially those deployed on ECS or in containers, we recommend using RAM roles and obtaining STS temporary credentials to access OSS. Compared with long-term AccessKey pairs, temporary credentials have an automatic expiration mechanism. This avoids hard-coding long-term AccessKey pairs in the code or configuration files, significantly reducing the risk of AccessKey leaks.

  • Separate human users from programmatic users: Create separate RAM users for different personnel and applications to achieve specialized identity management and fine-grained permission control.

    • Human users: Configure console access and use a username and password to access the cloud service console. We recommend enabling MFA multi-factor authentication.

    • Programmatic users: Configure permanent AccessKey access and use the access key to call APIs for accessing cloud resources.

  • AccessKey security management:

    • Do not store the AccessKey ID and AccessKey Secret of a RAM user in project code. Otherwise, AccessKey leakage may occur.

    • We recommend using STS or environment variables to obtain access authorization.

    • Rotate AccessKeys on a regular basis.

  • RAM role security recommendations:

    • After creating a RAM role, do not arbitrarily change the trusted entity of the RAM role to avoid affecting business operations or causing excessive authorization risks.

    • Set a reasonable STS token validity period to avoid security risks caused by an excessively long validity period.

  • Regularly audit permissions: Periodically check and clean up RAM users and permission policies that are no longer needed to ensure that permissions remain aligned with current business requirements.

  • Use Condition to enhance security: Add a Condition in the policy, such as restricting source IP addresses or VPCs, to add an additional security layer for data access through multi-dimensional condition constraints.

    Important

    When configuring RAM Policy, configure it based on your own network access architecture. We recommend configuring both acs:SourceIp and acs:SourceVpc conditions to implement dual access control. A single condition may have security blind spots. For example, when only public IP addresses are restricted, VPC instances may bypass the restriction by using a matching egress IP address through the public Internet, causing unauthorized access.

Troubleshooting policies not taking effect

After configuring a RAM custom policy, if the OSS access request still fails, you can refer to the following common causes for step-by-step troubleshooting.

An explicit Deny rule overrides Allow

Symptom: An Allow statement has been configured in the RAM Policy, but the request still returns an AccessDenied error.

Troubleshooting steps:

  1. Go to the RAM Users page, click the target user, and on the Permissions tab, view all policies bound to this identity (including system policies and custom policies).

  2. Check each policy one by one for statements with Effect: Deny, focusing on rules where Action contains a wildcard (such as oss:*) or covers the target operation.

  3. If a service control policy (SCP) is enabled at the account level, also check whether there are Deny rules in the SCP that match the request.

Resolution: Delete unnecessary Deny statements, or narrow the scope of Resource and Condition in Deny rules to avoid mistakenly intercepting legitimate requests that have been Allowed. RAM Policy follows the explicit deny priority principle: if any Deny rule matches the request, access is denied, regardless of Allow rules in the same policy or other policies.

Incorrect Resource ARN format

Symptom: Object-level operations such as GetObject and PutObject return insufficient permissions, or bucket-level operations such as ListObjects fail. These two types of operations require separate Resource configurations.

Troubleshooting steps:

  1. Check the Resource field in the policy and confirm whether both bucket-level resources (acs:oss:*:*:bucketname) and object-level resources (acs:oss:*:*:bucketname/*) are included.

  2. Confirm that the account ID is entered correctly. If * is used to match all accounts, confirm that this matches the expected authorization scope.

  3. For directory-level authorization, confirm that the correct prefix wildcard is used (for example, acs:oss:*:*:mybucket/dir/*), rather than writing the directory path in Resource but omitting the bucket-level resource required by ListObjects.

Resolution: When both bucket-level and object-level operations need to be authorized, configure two types of Resources in the same policy:

{
  "Effect": "Allow",
  "Action": ["oss:ListObjects", "oss:GetBucketInfo"],
  "Resource": "acs:oss:*:*:mybucket"
},
{
  "Effect": "Allow",
  "Action": ["oss:GetObject", "oss:PutObject"],
  "Resource": "acs:oss:*:*:mybucket/*"
}

Policy not attached to the correct RAM identity

Symptom: After creating or modifying a policy, the permissions do not take effect, and the actual access behavior of the RAM user or role has not changed.

Troubleshooting steps:

  1. Go to the Policies page, find the target policy, and click Bind Users to view the list of currently bound identities. Confirm that the target user or role is in the list.

  2. If authorization is performed through a user group, go to the RAM User Groups page and confirm that the RAM user has been added to the corresponding user group and that the user group has the target policy bound to it.

  3. If you are using a RAM role, confirm that the application or user is assuming the correct role that has the target policy bound to it, rather than another role.

Resolution: On the Permissions tab of the target user, click Grant Permission to attach the target policy to this RAM identity, and then test again.

Condition mismatch

Symptom: The policy contains a Condition (such as IP restrictions, VPC restrictions, or time window restrictions), and requests from certain sources or during certain time periods are unexpectedly denied.

Troubleshooting steps:

  1. Check the Condition configuration in the policy and verify the condition keys used (such as acs:SourceIp, acs:SourceVpc, and oss:Prefix) and their corresponding matching values.

  2. Confirm whether the actual IP address, VPC ID, or other attributes of the client initiating the request meet the Condition requirements.

  3. Note that acs:SourceIp and acs:SourceVpc usually need to be configured together to avoid security blind spots. When only public IP addresses are restricted, requests within a VPC may be routed through a public Internet egress with a matching IP address to bypass the restriction. For more information, see the security recommendations in Applying to production environments.

Resolution: Adjust the Condition field based on the actual network access architecture. To locate the issue, you can temporarily remove the Condition to verify that the basic Allow of the policy works, and then gradually add condition constraints and verify.

Action name misspelled or incomplete

Symptom: An Allow for the corresponding operation has been configured, but the request still returns AccessDenied. Or, access through the OSS console is normal, but SDK or API calls fail (or vice versa).

Troubleshooting steps:

  1. Verify the names of each Action in the policy, paying attention to case sensitivity (OSS Actions are case-sensitive; the correct format is, for example, oss:GetObject, not oss:getobject).

  2. Operations through the OSS console typically require authorizing multiple Actions simultaneously (such as oss:ListBuckets, oss:GetBucketStat, oss:GetBucketInfo, and oss:GetBucketAcl). Check for any omissions.

  3. Refer to RAM authorization elements supported by OSS to confirm the complete name and applicable scenario of the required operation.

Resolution: Correct the misspelled Action name and supplement the required complete Action set based on the actual usage scenario (console, SDK, or API).

Cross-impact between Bucket Policy and RAM Policy

Symptom: The RAM Policy has authorized the target operation, but access to a specific bucket is still denied. Or the access behavior does not change after the RAM Policy is removed.

Troubleshooting steps:

  1. Go to the OSS console, enter the target bucket, and select Access Control > Bucket Policy to check whether there is a Deny rule that covers the current identity.

  2. According to the explicit deny priority principle, Deny rules in the Bucket Policy and Allow rules in the RAM Policy also follow the deny-first rule: even if the RAM Policy has authorized the operation, as long as there is a matching Deny rule in the Bucket Policy, the request will still be denied.

  3. Check the access control list (ACL) settings of the bucket. For buckets with a private ACL, all access must be explicitly authorized through a RAM Policy or Bucket Policy. When the bucket-level ACL is set to public-read or public-read-write, anonymous users can also access the data, which poses a data security risk.

Resolution: Comprehensively review the RAM Policy and Bucket Policy to confirm that they do not conflict. If the Allow rule in the RAM Policy needs to take effect, adjust or delete the corresponding Deny rule in the Bucket Policy, or consolidate related authorizations into the RAM Policy.

Related documents

Previous：Set expiration for policy statementsNext：Use a RAM role for cross-account access to OSS