Custom Policy Use Cases
Using a Custom Policy Along with Full-Permission System-Defined Policies
If you want to assign full permissions to a user but disallow them from accessing a specific service, such as Cloud Trace Service (CTS), create a custom policy for denying access to CTS and then attach this custom policy together with the FullAccess policy to the user. As an explicit deny in any policy overrides any allows, the user can perform operations on all services except CTS.
Example policy denying access only to CTS:
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "cts:*:*" ] } ] }
- Action: Operations to be performed. Each action must be defined in the format "Service name:Resource type:Operation".
For example, cts:*:* refers to permissions for performing all operations on all resource types of CTS.
- Effect: Determines whether to deny or allow the operation.
Using a Custom Policy Along with a System-Defined Policy
- If you want to assign full permissions to a user but disallow them from creating BMSs, create a custom policy denying the bms:servers:create action and then attach this custom policy together with the BMS FullAccess policy to the user. As an explicit deny in any policy overrides any allows, the user can perform all operations on BMS except creating BMSs.
Example policy denying BMS creation:
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "bms:servers:create" ] } ] }
- If you want to assign OBS read-only permissions to all users but disallow certain users from viewing specific resources, for example, disallow users whose names start with TestUser from viewing buckets whose names start with TestBucket, create a custom policy denying such operations and attach this custom policy together with the OBS ReadOnlyAccess policy to those users. As an explicit deny in any policy overrides any allows, certain users cannot view buckets whose names start with TestBucket.
Example policy denying users whose names start with TestUser from viewing buckets whose names start with TestBucket:
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "obs:bucket:ListAllMybuckets", "obs:bucket:HeadBucket", "obs:bucket:ListBucket", "obs:bucket:GetBucketLocation" ], "Resource": [ "obs:*:*:bucket:TestBucket*" ], "Condition": { "StringStartWith": { "g:UserName": [ "TestUser" ] } } } ] }
Currently, only certain cloud services (such as OBS) support resource-based authorization. For services that do not support this function, you cannot create custom policies containing resource types.
Using Only a Custom Policy
You can create a custom policy and attach only the custom policy to the group to which the user belongs.
- The following is an example policy that allows access only to ECS, EVS, VPC, ELB, and Application Operations Management (AOM).
{ "Version": "1.1", "Statement": [ { "Effect": "Allow" "Action": [ "ecs:*:*", "evs:*:*", "vpc:*:*", "elb:*:*", "aom:*:*" ], } ] }
- The following is an example policy that allows only IAM users whose names start with TestUser to delete all objects in the my-object directory of the bucket my-bucket.
{ "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "obs:object:DeleteObject" ], "Resource": [ "obs:*:*:object:my-bucket/my-object/*" ], "Condition": { "StringStartWith": { "g:UserName": [ "TestUser" ] } ] }
- The following is an example policy that allows access to all services except ECS, EVS, VPC, ELB, AOM, and APM.
{ "Version": "1.1", "Statement": [ { "Effect": "Allow" "Action": [ "*:*:*" ], }, { "Action": [ "ecs:*:*", "evs:*:*", "vpc:*:*", "elb:*:*", "aom:*:*", "apm:*:*" ], "Effect": "Deny" } ] }
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot