Help Center > > User Guide> IAM Permissions Management> Syntax of Fine-Grained Policies

Syntax of Fine-Grained Policies

Updated at: Nov 06, 2019 GMT+08:00

Policy Structure

A fine-grained policy consists of a version and one or more statements. Each policy can have multiple statements.

Figure 1 Policy structure

Policy Syntax

The MRS Viewer policy is used as an example to describe the syntax of fine-grained policies.

{
	"Version": "1.1",
	"Statement": [{
			"Effect": "Allow",
			"Action": ["mrs:*:get*",
				"mrs:*:list*",
				"ecs:*:get*",
				"ecs:*:list*",
				"evs:*:get*",
				"evs:*:list*",
				"vpc:*:get*",
				"vpc:*:list*"
			]
		},
		{
			"Effect": "Deny",
			"Action": ["mrs:cluster:create",
				"mrs:cluster:resize",
				"mrs:cluster:scaleUp",
				"mrs:cluster:delete",
				"mrs:cluster:policy",
				"mrs:cluster:syncUser",
				"mrs:job:submit",
				"mrs:job:stop",
				"mrs:job:delete",
				"mrs:job:batchDelete",
				"mrs:job:checkSql",
				"mrs:file:create",
				"mrs:file:delete",
				"mrs:tag:batchOperate",
				"mrs:tag:create",
				"mrs:tag:delete",
				"mrs:manager:access",
				"mrs:patch:install",
				"mrs:patch:uninstall",
				"mrs:ops:grant",
				"mrs:ops:shareLog",
				"mrs:alarm:subscribe"
			]
		}
	]
}
  • Version: Distinguishes between role-based access control (RBAC) and fine-grained policies.
    • 1.0: RBAC policies. An RBAC policy consists of permissions for an entire service. Users in a group with such a policy assigned are granted all of the permissions required for that service.
    • 1.1: Fine-grained policies. A fine-grained policy consists of API-based permissions for operations on specific resource types. Fine-grained policies, as the name suggests, allow for more fine-grained control than RBAC policies. Users granted permissions of such a policy can only perform specific operations on the corresponding service. Fine-grained policies include system and custom policies.
  • Statement: Permissions defined by a policy, including Effect and Action.
    • Effect

      The valid values for Effect are Allow and Deny. System policies contain only Allow statements. For custom policies containing both Allow and Deny statements, the Deny statements take precedence.

    • Action

      Permissions in the format of Service name:Resource type:Operation. A policy can contain one or more permissions. The wildcard (*) is allowed to indicate all of the services, resource types, or operations depending on its location in the action.

      For example, mrs:*:get* indicates permissions for querying all types of resources in MRS.

Multi-Action Policy

A custom policy can contain actions of multiple services that are all of the global or project-level type. The following is a policy with multiple statements:

{
        "Version": "1.1",
        "Statement": [
                {
                        "Action": [
                                "ecs:cloudServers:resize",
                                "ecs:cloudServers:delete",
				"ecs:cloudServers:delete",
				"ims:images:list",
				"ims:serverImages:create"
                        ],
                        "Effect": "Allow"
                }
        ]
}

Deny Policy

A deny policy must be used in conjunction with other policies to take effect. If the permissions assigned to a user contain both Allow and Deny actions, the Deny actions take precedence over the Allow actions.

The following method can be used if you need to assign permissions of the MRS Admin policy to a user but also forbid the user from deleting a cluster (mrs:cluster:delete). Create a custom policy with the same action for denying MRS cluster deletion, set Effect to Deny, and assign both policies to the group the user belongs to. Then the user can perform all operations on MRS except deleting clusters. The following is a policy for denying MRS cluster deletion.

{
      "Version": "1.1",
      "Statement": [
            {
		  "Effect": "Deny",
                  "Action": [
                        "mrs:cluster:delete"

                  ]
            }
      ]
}

Authentication Logic

If a user is granted permissions of multiple policies or of only one policy containing both Allow and Deny statements, then authentication starts from the Deny statements. The following figure shows the authentication logic for resource access.

Figure 2 Authentication logic

The actions in each policy bear the OR relationship.

  1. A user accesses the system and makes an operation request.
  2. The system evaluates all the permission policies assigned to the user.
  3. In these policies, the system looks for explicit deny permissions. If the system finds an explicit deny that applies, it returns a decision of Deny, and the authentication ends.
  4. If no explicit deny is found, the system looks for allow permissions that would apply to the request. If the system finds an explicit allow permission that applies, it returns a decision of Allow, and the authentication ends.
  5. If no explicit allow permission is found, IAM returns a decision of Deny, and the authentication ends.

Did you find this page helpful?

Submit successfully!

Thank you for your feedback. Your feedback helps make our documentation better.

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?







Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel