Last update:2025-08-18 15:58:39
Permission policy (IAM Policy) is a key element in Identity and Access Management, used to define the access permissions of users, groups, or roles to resources. Its function is to finely control who (user or entity) can access which resources and perform which specific actions through a series of permission rules. The core purpose of IAM policies is to ensure the security of resources, prevent unauthorized access, and provide flexible permission management to meet different business needs. In this way, businesses can effectively manage user permissions, adhere to the principle of least privilege, and reduce potential security risks. They are typically written in JSON format, detailing specific operations that are allowed or denied. For example, an IAM policy can allow a user group to access a specific bucket or restrict it to read-only operations.
The format of a permission policy is as follows:
{
"version": "1",
"statement": [
{
"action": [
"wos:GetBucket"
],
"resource": [
"wsc:wos:*:*:testbucket"
],
"effect": "allow"
},
{
"action": [
"wos:PutObject",
"wos:GetObject",
"wos:DeleteObject"
],
"resource": [
"wsc:wos:*:*:testbucket/*"
],
"effect": "allow"
}
]
}
The primary account can use such a policy to authorize sub-accounts in the IAM system. There is one statement in the policy (there can be multiple statements in one policy). The corresponding action, resource, and effect are specified in the statement.
The permissions of this policy configuration: list the information of all files in the space testbucket; upload files to the space testbucket; download the files in the space testbucket; delete the files in the space testbucket.
version defines the version of the permission policy, and the currently supported version is “1”.
Authorization semantics are described through statements, which can contain multiple semantics according to business scenarios, each containing a description of action, effect, and resource. Each time a request is made, the system will match and check one by one. All successfully matched statements will be divided into allow and deny according to the effect setting, among which deny takes precedence. If all matches are passed, the request is authenticated. If the match is successful, there is a prohibition, or if no entry is matched successfully, the request is forbidden to access.
Action refers to the operation of the S3 API or console provided by wos. The action rule is wos:{action_name}, which supports * wildcard, and can use * to represent 0 or more arbitrary English letters. For example, wos:List* means all S3 API or console operations provided by wos whose action_name starts with List. .
Action is a list, you can choose one or more of the actions, all action_name must be prefixed with “wos:”. There can be multiple actions.
Actions are divided into three categories:
1.Service-level operations. corresponding to operations similar to wos:GetService.
The corresponding relationship between specific action and S3 API is as follows:
| S3 API | action |
|---|---|
| GetService | wos:GetService |
The corresponding relationship between specific actions and console operations is as follows:
| Console operation | action |
|---|---|
| Buckets | |
| View | wos:GetService |
| Bucket-Manage-Basic statistics / Detection statistics / Overview | |
| View | wos: GetBucketAnalysis |
Note:
- If the GetService permission is assigned to the sub-account, the sub-account can obtain all the space owned by its parent account. (For the space created by the sub-account, the owner of the space is its parent account)
- All sub-accounts using the console must have GetService permission, otherwise other operations on the console may not be able to be used normally.
- If the GetBucketAnalysis permission is assigned to the sub-account, the sub-account can view all the menu items under statistical analysis.
2. Bucket level operations. corresponding to operations similar to wos:PutBucketLifecycle, wos:GetBucket, etc. The object of the operation is Bucket.
The corresponding relationship between specific action and S3 API is as follows:
| S3 API | action |
|---|---|
| GetBucket(ListObjects) | wos: GetBucket |
| GetBucketLifecycle | wos: GetBucketLifecycle |
| PutBucketLifecycle | wos: PutBucketLifecycle |
| DeleteBucketLifecycle | wos:DeleteBucketLifecycle |
| ListMultipartUploads | wos: ListMultipartUploads |
The corresponding relationship between specific actions and console operations is as follows:
| Console operation | action |
|---|---|
| Buckets | |
| Create Bucket | wos: PutBucket |
| Buckets-Manage-File management | |
| Query (view) | wos: GetBucket |
| Buckets-Manage-Basic settings | |
| View-Back-To-Origin | wos: GetBucketMirror |
| Edit-Back-To-Origin | wos: PutBucketMirror |
| Delete-Back-To-Origin | wos:DeleteBucketMirror |
| View-life cycle settings | wos: GetBucketLifecycle |
| Create rule-life cycle settings | wos: PutBucketLifecycle |
| Edit-life cycle settings | wos: PutBucketLifecycle |
| Clear all rules-life cycle settings | wos:DeleteBucketLifecycle |
| Delete-life cycle settings | wos:DeleteBucketLifecycle |
| Create rules-CORS settings | wos: PutBucketCors |
| Edit-CORS settings | wos: PutBucketCors |
| View-CORS settings | wos: GetBucketCors |
| Delete-CORS settings | wos:DeleteBucketCors |
| Clear all rules-CORS settings | wos:DeleteBucketCors |
| Delete Bucket | wos:DeleteBucket |
| Buckets-manage-Domain Management | |
| View-domain name | wos: GetBucketDomain |
| Bind custom domain name | wos: PutBucketDomain |
| Modify protocol | wos: PutBucketDomain |
| Delete-domain name | wos:DeleteBucketDomain |
3. Object level operation. corresponding to similar to wos:GetObject, wos:PutObject, wos:DeleteObject and wos:AbortMultipartUpload, the operation object is Object.
The corresponding relationship between specific action and S3 API is as follows:
| S3 API | action |
|---|---|
| GetObject | wos:GetObject |
| HeadObject | wos: HeadObject |
| PutObject | wos: PutObject |
| PostObject | wos: PutObject |
| InitiateMultipartUpload | wos: PutObject |
| UploadPart | wos: PutObject |
| CompleteMultipartUpload | wos: PutObject |
| DeleteObject | wos:DeleteObject |
| MultiDelete | wos:DeleteObject |
| AbortMultipartUpload | wos: AbortMultipartUpload |
| ListParts | wos: ListParts |
| CopyObject | wos:GetObject,wos:PutObject |
| RestoreObject | wos:RestoreObject |
The corresponding relationship between specific actions and console operations is as follows:
| Console operation | action |
|---|---|
| Buckets-Manage-File management | |
| New folder | wos: PutFolder |
| Upload file | wos: PutObject |
| Delete | wos:DeleteObject |
| Rename | wos: PutObject |
| Restore | wos:RestoreObject |
| Configure Expiration Data | wos:DeleteObject |
Resource refers to the resource stored on wos. The rule of resource is wsc:wos:{region}:{bucket_owner}:{bucket_name}/{object_name}, which supports wildcard. You can use to represent 0 or more arbitrary English letters. The region field is temporarily not supported and is set to “*”.
resource is also a list, which can contain one or more resources. There can be multiple resources.
Effect represents the outcome of the authorization statement in this document, defining the priority of authorization results. It is divided into two categories: allow and deny, which respectively refer to permission granted and access forbidden. When multiple statements are matched successfully at the same time, deny has a higher priority .
For example, it is expected that users are forbidden to delete a certain directory, but have full permissions for other files:
{
"version": "1",
"statement": [
{
"effect": "allow",
"action": [
"wos:*"
],
"resource": [
"wsc:wos:*:*:bucketname/*"
]
},
{
"effect": "deny",
"action": [
"wos:DeleteObject"
],
"resource": [
"wsc:wos:*:*:bucketname/test/*"
]
}
]
}