Enterprise Distributed Application Service:Overview

EDAS-defined permissions and RAM policies

EDAS is developed with a permission management system, and also integrated with Resource Access Management (RAM).

• For more information about how to use RAM to manage permissions, see Overview.

• For more information about EDAS-defined permissions, see Manage EDAS-defined permissions (not recommended).

To manage permissions on Alibaba Cloud services including EDAS in the same system, we recommend that you use RAM. EDAS also allows you to replace EDAS-defined permissions with RAM policies. For more information, see Replace EDAS-defined permissions with RAM policies.

EDAS supports both EDAS-defined permissions and RAM policies. Sub-accounts and RAM users are managed by using the following rules:

• Access of RAM users is controlled by RAM policies, instead of EDAS-defined permissions.

• For sub-accounts:

  • Access of sub-accounts that are granted the AliyunEDASFullAccess permission is controlled by RAM policies, instead of EDAS-defined permissions.

  • We recommend that you switch sub-accounts that are regulated by EDAS-defined permissions to RAM users. For more information, see Replace EDAS-defined permissions with RAM policies. If you do not switch sub-accounts to RAM users, you can continue to use EDAS-defined permissions to control access of the sub-accounts.

Benefits of RAM

RAM is a resource access control service that is provided by Alibaba Cloud. You can use policies to control access of RAM users, such as employees, systems, or applications, and grant a RAM user specific permissions on a resource. For example, you can grant a RAM user read-only permissions on an EDAS application.

Finer-grained access control

More types of syntax

RAM policies support more types of syntax than EDAS-defined permissions. For example, you can use wildcard characters in permission statements, and attach multiple policies to a RAM user to precisely regulate access control.

The following example shows the syntax of a RAM policy:

{
    "Statement": [
      {
        "Action": [
          "edas:ReadApplication"
        ],
        "Effect": "Allow",
        "Resource": ["acs:edas:*:*:namespace/*/application/*"]
      },
      {
        "Action": [
          "edas:ReadApplication"
        ],
        "Effect": "Deny",
        "Resource": ["acs:edas:cn-beijing:*:namespace/*/application/12345678"]
      }
    ],
    "Version": "1"
}

The preceding policy contains two statements:

• In the first statement, the effect is set to Allow, the action is set to edas:ReadApplication, which allows the RAM user to view applications, and the resource is set to a wildcard character (*), which specifies all applications. This statement specifies that the RAM user is allowed to view all EDAS applications.

• In the second statement, the effect is set to Deny, and the resource is set to 12345678, which specifies the application whose ID is 12345678. This statement specifies that the RAM user is not allowed to view the application whose ID is 12345678.

Therefore, the policy that contains the preceding statements specifies that the RAM user is allowed to view all applications other than the application whose ID is 12345678.

You can also use conditional expressions to define a policy. For more information, see Policy overview.

Relationship between EDAS-defined permissions and RAM policies

EDAS-defined permissions are not equivalent to RAM policies. Therefore, you cannot directly change an EDAS-defined permission into a RAM policy. EDAS allows you to replace EDAS-defined permissions with RAM policies, which can inherit the EDAS-defined permissions in most cases. By default, the permissions that define whether a sub-account can perform a specific operation on EDAS resources such as applications and clusters are inherited by the RAM user to which the sub-account is switched.