• Identity and Access Management

iam
  1. Help Center
  2. Identity and Access Management
  3. User Guide
  4. User Guide
  5. Fine-grained Policy Management
  6. Policy Language

Policy Language

Policy Content

A fine-grained authorization policy consists of the policy version (the Version field) and authorization statement (the Statement field).

  • Version: Policy version.
    • 1.0: Non-fine-grained permission
    • 1.1: Fine-grained permission
  • Statement: Detailed information about a policy, containing the Effect and Action elements.
    • Effect

      Valid values for Effect include Allow and Deny. In a custom policy that contains both Allow and Deny statements, the Deny statements take the precedence.

    • Action

      The value can be one or more resource authorization items.

      The value format is Service name:Resource type:Action, for example, vpc:ports:create.

      NOTE:
      • Service name: indicates the product name, such as ecs, evs, or vpc. Only lowercase letters are allowed.
      • Resource type and Action: The values are case-insensitive, and the wildcard (*) are allowed. A wildcard (*) can represent all or part of information about resource types and actions for the specific service.

Example Policies

  • A policy can define a single permission, such as the permission to query ECS details.
    {
          "Version": "1.1",
          "Statement": [
                {
                      "Effect": "Allow",
                      "Action": [
                            "ecs:servers:list",
                            "ecs:servers:get",
                            "ecs:serverVolumes:use",
                            "ecs:diskConfigs:use",
                            "ecs:securityGroups:use",
                            "ecs:serverKeypairs:get",
                            "vpc:securityGroups:list",
                            "vpc:securityGroups:get",
                            "vpc:securityGroupRules:get",
                            "vpc:networks:get",
                            "vpc:subnets:get",
                            "vpc:ports:get",
                            "vpc:routers:get"
                      ]
                }
          ]
    }
  • A policy can define multiple permissions, such as the permissions to lock ECSs and create EVS disks.
    {
        "Version": "1.1",
          "Statement": [
                {
                      "Effect": "Allow",
                      "Action": [
                            "ecs:servers:lock",
                            "evs:volumes:create"
                      ]
                }
          ]
    }
  • The following example shows how to use the wildcard (*) to define all permissions on Image Management Service (IMS) resources.
    {
            "Version": "1.1",
            "Statement": [
                    {
                            "Action": [
                                    "ims:*:*",
                                    "ecs:*:list",
                                    "ecs:*:get",
                                    "evs:*:get"
                            ],
                            "Effect": "Allow"
                    }
            ]
    }

Authentication Logic

IAM authenticates users according to the permissions that have been granted to them. The authentication logic is as follows:

Figure 1 Authentication logic
NOTE:

The actions in each policy bear the OR relationship.

  1. A user accesses the system and initiates an operation request.
  2. IAM evaluates all the access policies that have been granted to the user.
  3. In these policies, IAM looks for explicit deny instructions. If IAM finds an explicit deny that applies, it returns a decision of Deny, and the authentication ends.
  4. If no explicit deny is found, IAM looks for Allow instructions that would apply to the request. If IAM finds an explicit permit that applies, it returns a decision of Allow, and the authentication ends.
  5. If no explicit permit is found, IAM returns a decision of Deny, and the authentication ends.