IAM policies are divided into identity-based policies and resource-based policies.

identity-based policy #

Policies tied to IAM identities (users, user groups, or roles) are called "identity-based policies," and in general, most scenarios require only identity-based policies.

Example 1: The following is an identity-based policy that defines allowing partial operations on the Application Load Balancer:

{ 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Action": [ 
        "alb:CreateListener", 
        "alb:DeleteListener", 
        "alb:ModifyListener", 
        "alb:DescribeListener", 
        "alb:DescribeListenerAttributes", 
        "alb:DescribeListenerHealth" 
      ], 
      "Resource": [ 
        "*" 
      ] 
    } 
  ] 
}

Example 2: The following policy defines permissions to allow deletion of an IAM user group named example-group:

{ 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Action": [ 
        "iam:DeleteGroup" 
      ], 
      "Resource": [ 
        "trn:iam::2000000001:group/example-group" 
      ] 
    } 
  ] 
}

Example 3: The following policy is based on Example 1, further adding the Condition element and limiting the time it can be accessed (the instructions for using this element can be found in the Condition documentation ):

{ 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Action": [ 
        "alb:CreateListener", 
        "alb:DeleteListener", 
        "alb:ModifyListener", 
        "alb:DescribeListener", 
        "alb:DescribeListenerAttributes", 
        "alb:DescribeListenerHealth" 
      ], 
      "Resource": [ 
        "*" 
      ] 
      "Condition": { 
         "DateGreaterThanEquals": { 
           "volc:CurrentTime":"2023-08-30T23:59:59Z" 
         } 
       } 
    } 
  ] 
}

An identity-based policy consists of the following elements:

Statement: Statement is the basic unit of describing rights in the policy, which is called permission declaration. Each policy can contain multiple permission declarations, which are expressed in the form of an array. Details can be found in the Statement documentation .
Effect: Effect defines whether the permission effect is allowed or denied. Details can be found in the Effect documentation .
Action: Actions define the scope of operation of permissions, and Actions supported by different Cloud as a Service can be queried from the API documentation of Cloud as a Service. Details can be found in the Action documentation .
Resource: Resource defines the resource scope of permissions, and when you don't need to control resource-level permissions, you can use wild-card * to represent all resources. To define specific resource-level permissions, refer to the Resource documentation .
Condition: Condition defines the effective conditions for permissions, and when no specific effective conditions need to be controlled, the Condition section may not be included in the policy. To define specific permissions, refer to the Condition documentation .

resource-based strategy #

In some scenarios, policies can be tied to resources rather than identities, and such policies are called "resource-based policies". In a resource-based policy, the Principal element must be included in the policy content because of the lack of identity binding, and because a resource-based policy naturally has a binding relationship with resources, the Resource element in the policy does not need to be defined.

The following is an example of a resource-based policy:

{ 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "sts:AssumeRole" 
            ], 
            "Principal": { 
                "Service": [ 
                    "vke" 
                ] 
            } 
        } 
    ] 
}

A resource-based strategy consists of the following elements:
Statement: Statement is the basic unit of describing rights in the policy, which is called permission declaration. Each policy can contain multiple permission declarations, which are expressed in the form of an array. Details can be found in the Statement documentation .
Effect: Effect defines whether the permission effect is allowed or denied. Details can be found in the Effect documentation .
Action: Actions define the scope of operation for permissions, and Actions supported by different Cloud as a Service can be queried from the API documentation of Cloud as a Service. Details can be found in the Action documentation .
Principal: Principal defines a trust object for permissions. For details, please refer to the Principal documentation . In the example, the trust object is the vke service, which plays an AssumeRole on behalf of the granted service.
Condition: Condition defines the effective conditions for permissions, and when no specific effective conditions need to be controlled, the Condition section may not be included in the policy. To define specific permissions, refer to the Condition documentation .

Volcano Engine currently supports the following two resource-based strategies for resource usage:

• Access control roles: Resource-based policies on roles are also known as trust policies.

• Object buckets: Resource-based policies on buckets are also known as bucket policies .