Use resource groups to manage permissions - Enterprise Distributed Application Service

Enterprise Distributed Application Service (EDAS) allows you to use resource groups provided by Resource Management to manage resource permissions. After you create resource groups for EDAS, you can add clusters and applications to different resource groups. Then, you can grant RAM users the required permissions on these resource groups. This simplifies the management of resource permissions.

Prerequisites

EDAS is developed with a primary and sub-account management system. To use resource groups to manage permissions, you must use Resource Access Management (RAM) instead of the EDAS primary and sub-account management system. For more information, see Replace EDAS-defined permissions with RAM policies.
The Resource Management service is automatically activated for Alibaba Cloud accounts and RAM users.

Background information

Resource Management provides a wide array of services to facilitate IT governance for enterprises. Resource Management allows you to build a resource hierarchy based on your business requirements. You can create resource groups for different users and grant the users the required permissions on clusters and applications.

Resource Group allows you to sort resources owned by your Alibaba Cloud account into groups. This simplifies resource and permission management within your Alibaba Cloud account.

Create resource groups to manage the resources of your Alibaba Cloud account in various regions.
Specify an administrator for each resource group. Each administrator manages the resources in the resource group for which they are responsible.

Relationship between the EDAS primary and sub-account management system and RAM

EDAS supports the following permission management systems that are independent of each other:

Note

Each Alibaba Cloud account can use only one of the following permission management systems. We recommend that you use RAM.

Before EDAS is integrated with RAM, EDAS uses a primary and sub-account management system to manage the permissions of sub-accounts.
After EDAS is integrated with RAM, EDAS uses resource groups to manage the permissions of RAM users.

Benefits of resource groups

The following example shows the benefits of resource groups in terms of permission management.

Company A has two departments: deptA and deptB. deptA uses a RAM user named subA to manage a cluster named clusterA and applications named appA1 and appA2. deptB uses a RAM user named subB to manage a cluster named clusterB and applications named appB1 and appB2.

RAM allows you to manage permissions by using policies or resource groups.

Table 1. The following table describes the differences between RAM policies and resource groups.
Item	RAM policy	Resource group
Scenarios	Allows you to grant a user limited permissions on a specified resource.	Allows you to grant a user limited permissions on a specified resource group that may contain one or more resources.
How it works	You must use your Alibaba Cloud account to create the RAM user subA for deptA and the RAM user subB for deptB in the RAM console. Then, create a policy named policyA for subA and a policy named policyB for subB. In the policies, specify the clusters and applications that you allow the RAM users to manage and the permissions on the clusters and applications.	You must use your Alibaba Cloud account to create a resource group named groupA for deptA and a resource group named groupB for deptB. Then, add the cluster and applications that belong to deptA to groupA and those that belong to deptB to groupB. In the RAM console, create the RAM user subA for deptA and the RAM user subB for deptB. Then, create a custom policy that is to be attached to both subA and subB in groupA and groupB. This custom policy grants subA and subB separate permissions on resources in groupA and groupB.
Characteristics	This method has the following disadvantages: Complex permission configurations If subA and subB manage different resources but require the same permissions, you still need to create two separate policies for them. Frequent modifications Each time a resource is created or deleted, you must modify the policy. For example, if subA creates more applications, such as appA3 and appA4, you must add the application IDs to policyA.	This method provides the following benefits: Simplified permission configurations Each resource group is a collection of resources. You can grant a RAM user the permissions on a specific resource group instead of specific resources. Shared policy You do not need to configure a separate policy for each RAM user to manage different resources. Instead, you can create a custom policy that is to be attached to different RAM users and focus only on the Action element in the custom policy.

Note

The preceding methods are applicable to different scenarios. Select a method based on your business requirements.

Limits

Resource groups facilitate permission management. However, you must take note of the following limits:

Microservices namespaces cannot be added to resource groups. Only applications and clusters can be added to resource groups. You can use only RAM to manage permissions on microservices namespaces.
Application Configuration Management (ACM) and Application Real-Time Monitoring Service (ARMS) resources cannot be added to resource groups.

Procedure

The preceding example is used to demonstrate how to use resource groups to manage permissions.

Log on to the Resource Management console and create two resource groups: groupA and groupB. For more information, see Create a resource group.
Add clusters and applications to groupA and groupB. For more information, see Transfer resources to a resource group.
Log on to the RAM console and create the RAM user subA for deptA and the RAM user subB for deptB. For more information, see Create a RAM user.

In the RAM console, create a custom policy that is to be attached to both subA and subB in groupA and groupB. For more information, see Create a custom policy.

The following code shows the content of the policy:

{
    "Version": "1",
    "Statement": [    
      {
        "Effect": "Allow",
        "Action": [
              "edas:*Cluster",
            "edas:*Application"
        ],
        "Resource": [
          "acs:edas:*:*:*"
        ]
      }
    ]
}

In the Resource Management console, attach the custom policy to subA and subB. For more information, see Add RAM authorization.
Optional: Manage permissions on resources by removing resources from or adding resources to groupA and groupB.
Optional: Create a custom policy to grant subA the permissions on resources that do not belong to groupA. In this example, the permissions to query microservices in a microservices namespace are granted to subA. For more information, see Grant permissions to RAM users.
Note
When subA queries microservices by specifying a microservices namespace, an error is returned due to insufficient permissions even if the AliyunEDASFullAccess permission on groupA is granted to subA. This is because microservices namespaces cannot be added to a resource group and the permissions on microservices namespaces need to be granted to subA.
The following code shows the content of the policy:
```
{
   "Version": "1",
   "Statement": [
     {
       "Action": ["edas:ReadService"],
       "Resource": ["acs:edas:$regionid:*:namespace/$namespace"],
       "Effect": "Allow"
      }
   ]
 }
```
You must also grant the permissions in addition to cluster management, application management, and application-based microservice management that are described in Details about policies to subA.

Verify the result

After you perform the preceding steps, check whether the RAM users are granted the specified permissions.