Custom permission policy reference
If the system policies do not meet your requirements, you can create custom permission policies to achieve least privilege. Custom policies allow for fine-grained permission control and are an effective way to improve resource access security. This topic describes common scenarios and provides policy examples for using custom permission policies with Cell Phone Number Service.
What is a custom policy?
Resource Access Management (RAM) policies are classified into system policies and custom policies. You can manage custom policies based on your business requirements.
After you create a custom policy, you must attach the policy to a RAM user, RAM user group, or RAM role. This way, the permissions that are specified in the policy can be granted to the principal.
You can delete a RAM policy that is not attached to a principal. If the RAM policy is attached to a principal, before you can delete the RAM policy you must detach the RAM policy from the principal.
Custom policies support version control. You can manage custom policy versions based on the version management mechanism provided by RAM.
References
Common scenarios and examples for custom permission policies
Example 1: Allow calls to one or more specific API operations.
When calling an API, the script configuration is as follows:
{ "Version": "1", "Statement": [{ "Action": [ "dytns:DescribePhoneNumberAttribute" ], "Resource": "*", "Effect": "Allow" }] }To allow calls to multiple API operations, use the following script configuration:
{ "Version": "1", "Statement": [{ "Action": [ "dytns:DescribePhoneNumberOperatorAttribute" ,"dytns:PhoneNumberStatusForPublic" ,"dytns:PhoneNumberStatusForAccount" ], "Resource": "*", "Effect": "Allow" }] }The API operation name supports the asterisk (*) wildcard character.
{ "Version": "1", "Statement": [{ "Action": [ "dytns:DescribePhoneNumberAttribute*" ], "Resource": "*", "Effect": "Allow" }] }
Example 2: Allow calls to Cell Phone Number Service API operations only from specified IP addresses or CIDR blocks.
NoteIf the value of
acs:SourceIpis a single IP address, specify the exact IP address. Do not use the CIDR block format xx.xx.xx.xx/32. For example, use 10.0.0.1 instead of 10.0.0.1/32.In the policy, 42.XXX.XX.XX represents the IP address that you want to allow calls from, and /24 represents the mask for the CIDR block. You can set the allowed IP addresses or CIDR blocks based on your requirements.
The `DateLessThan` field sets an expiration time for the policy. The IP address restriction is valid only until the specified time. After this time, the restriction is automatically removed.
The configuration is as follows:
{ "Version": "1", "Statement": [{ "Action": "dytns:*", "Resource": "*", "Condition": { "IpAddress": { "acs:SourceIp": "42.XXX.XX.XX/24" }, "DateLessThan": { "acs:CurrentTime": "2016-12-16T15:00:00+08:00" } }, "Effect": "Allow" }] }You can remove the `DateLessThan` field. If you remove this field, the policy for the IP address or CIDR block remains valid indefinitely. The configuration is as follows:
{ "Version": "1", "Statement": [{ "Action": "dypns:*", "Resource": "*", "Condition": { "IpAddress": { "acs:SourceIp": "42.XXX.XX.XX/24" } }, "Effect": "Allow" }] }Example 3: Combine different conditions in a policy. For example, you can allow access only from the IP address 192.168.1.100 and only to the DescribePhoneNumberAttribute and API methods. The configuration is as follows:
{ "Version": "1", "Statement": [{ "Action": "dytns:DescribePhoneNumberAttribute", "Resource": "*", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.1.100" } }, "Effect": "Allow" }] }
Authorization reference
To use custom policies effectively, you must understand the permission control requirements of your business and the authorization information for Cell Phone Number Service. For more information, see Authorization Information.