Use resource groups to manage Auto Scaling for resource isolation and access control - Auto Scaling

Background

A resource group helps you manage your cloud resources by grouping them based on dimensions such as purpose, permissions, or ownership. This facilitates hierarchical resource management for multiple users and projects within an organization. A cloud resource can belong to only one resource group, and its relationships with other resources are not affected when it is added to a resource group. For more information, see Resource groups.

When you use resource groups, note the following:

When you add a scaling group to a resource group, its related resources, such as scaling configurations, scaling rules, event-triggered tasks, and scheduled tasks, are automatically added to the same resource group.
The resource group of a scaling group is independent of the resource groups of the instances within it.

For example, a scaling group can belong to a different resource group from the ECS instances or elastic container instances that the scaling group scales out.
A resource group can contain scaling groups from different regions.

For example, a resource group can contain a scaling group from the China (Beijing) region and another from the China (Hangzhou) region.
If you grant a RAM user permissions to manage all Alibaba Cloud resources, the RAM user can view all resource groups under the main account.

Use cases

Note

Before you use resource groups to manage scaling groups, make sure that you have created a RAM user. If you have not, see Create a RAM user.

You can use resource groups to manage scaling groups in the following use cases:

Add scaling groups with different purposes to different resource groups to classify and manage them. For more information, see Scenario 1: Group scaling groups by purpose.
Assign separate administrators to each resource group to manage users and permissions within the scope of each group. For more information, see Scenario 2: Scope administrator access to a resource group.

Scenario 1: Group scaling groups by purpose

Overview

Assume that you have both production and test environments. If their scaling groups are not organized, they all appear in one list, making operational errors more likely. To simplify management and prevent mistakes, we recommend creating two resource groups: one for the production environment and one for the test environment. You can then add the scaling groups to their respective resource groups based on their purpose.

For example, an Alibaba Cloud account has two scaling groups: Scaling Group A for the production environment and Scaling Group B for the test environment. You add Scaling Group A to the production resource group and Scaling Group B to the test resource group. The requirements are as follows:

In the test resource group, you can view and manage only Scaling Group B. This prevents accidental modifications to Scaling Group A that could affect online services when the All resources scope is selected.
In the production resource group, you can view and manage only Scaling Group A. This prevents accidental modifications to Scaling Group B that could impact the production release schedule when the All resources scope is selected.

Procedure

Create resource groups for the test and production environments.

This example uses a production resource group named ProdResourceGroup and a test resource group named TestResourceGroup. For more information, see Create a resource group.

After completing the operation, the resource group status is Creating.... After about 3 seconds, click . If the status changes to Available, the resource group has been successfully created.
Create a scaling group for the test environment.

To ensure that the ECS instances in a scaling group belong to the same resource group as the scaling group, use the following methods when you create a scaling group, for example, TestScalingGroup. The method depends on the selected Instance Configuration Source.
- If you set Instance Configuration Source to Launch Template, specify the Resource Group as TestResourceGroup in the Advanced configurations (optional) step when you create the launch template. For more information, see Create a launch template.
- If you set Instance Configuration Source to Select Existing Instance, specify the Resource Group as TestResourceGroup in the Advanced configurations (optional) section when you create the ECS instance. For more information, see Create an instance by using the wizard.
- If you set Instance Configuration Source to Create from Scratch, specify the Resource Group as TestResourceGroup in the Advanced Settings section when you create the scaling configuration. For more information, see Create a scaling configuration for ECS instances.
When you configure the scaling group parameters, set Resource Group to TestResourceGroup to create the scaling group for the test environment. For more information, see Create a scaling group.
Create a scaling group for the production environment.

To ensure that the ECS instances in the scaling group belong to the same resource group as the scaling group, use the following methods when you create a scaling group, for example, ProdScalingGroup. The method depends on the selected Instance Configuration Source.
- If you set Instance Configuration Source to Launch Template, specify the Resource Group as ProdResourceGroup in the Advanced configurations (optional) step when you create the launch template. For more information, see Create a launch template.
- If you set Instance Configuration Source to Select Existing Instance, specify the Resource Group as ProdResourceGroup in the Advanced configurations (optional) section when you create the ECS instance. For more information, see Create an instance by using the wizard.
- If you set Instance Configuration Source to Create from Scratch, specify the Resource Group as ProdResourceGroup in the Advanced Settings section when you create the scaling configuration. For more information, see Create a scaling configuration for ECS instances.
When you configure the scaling group parameters, set Resource Group to ProdResourceGroup to create the scaling group for the production environment. For more information, see Create a scaling group.

Verify the result

Log on to the Auto Scaling console.
In the upper-left corner of the top navigation bar, select different resource groups to verify the visibility of scaling groups and their instances.
- When you select All resources, both the test scaling group (TestScalingGroup) and the production scaling group (ProdScalingGroup) appear in the scaling group list. If the scaling groups scaled out new ECS instances, you can view all instances from both the test (TestResourceGroup) and production (ProdResourceGroup) resource groups on the Instances tab.
- When you select TestResourceGroup, only the TestScalingGroup scaling group appears in the list. If the scaling group scaled out new ECS instances, you can view only the instances that belong to the test resource group (TestResourceGroup) on the Instances tab.
- When you select ProdResourceGroup, only the ProdScalingGroup scaling group appears in the list. If the scaling group scaled out new ECS instances, you can view only the instances that belong to the production resource group (ProdResourceGroup) on the Instances tab.

Scenario 2: Manage permissions by resource group

Overview

Assume a company has different departments that use separate scaling groups, which belong to different resource groups (for example, production and test resource groups). Each department has its own administrators. To let administrators manage scaling groups only within their department's resource group, you can grant them permissions scoped to that group. This ensures that certain administrators can only view and operate resources in the production environment, while others are restricted to the test environment.

For example, a company uses a single Alibaba Cloud account and assigns a RAM user to each department. For two departments, Department A and Department B, the goal is to ensure they can manage their scaling groups independently without interfering with each other. The access control requirements are as follows:

Administrators cannot create or modify scaling groups, or change configurations like scaling rules, for another department.
Administrators cannot view the scaling groups of another department.

Procedure

In RAM, create a custom policy named ApiWithoutResourcePolicy.

Some Auto Scaling API operations do not support resource group-based authentication, so you must create a custom policy to grant permissions for these operations. For more information, see Create a custom policy.
- The following API operations do not support resource group-based authentication:
  - DescribeRegions
  - DescribeLimitation
  - DescribeNotificationTypes
  - ListTagKeys
  - ListTagValues
- Use the following content for the ApiWithoutResourcePolicy custom policy:
```
{
  "Version": "1",
  "Statement": [
     {
        "Action": [
           "ess:DescribeRegions",
           "ess:DescribeLimitation",
           "ess:DescribeNotificationTypes",
           "ess:ListTagKeys",
           "ess:ListTagValues"
          ],
         "Resource": "*",
         "Effect": "Allow"
       }
    ]
}
```
Create RAM users for the administrators of Department A and Department B and grant them permissions at the Alibaba Cloud account scope.

This step provides an example for the Department A administrator. Select the RAM user for the Department A administrator as the Principal. Attach the ApiWithoutResourcePolicy custom policy created in Step 1 and the AliyunECSFullAccess system policy. For more information, see Grant permissions to a RAM user.
- Grant the custom policy to the Department A administrator:
  
  On the Add permissions panel, set Authorized scope to Alibaba Cloud account, confirm that the principal is the target RAM user, click the Custom policy tab, and then search for and select the ApiWithoutResourcePolicy policy.
- On the Add permissions page, set Authorized scope to Alibaba Cloud account, confirm that the principal is the target RAM user, click the System policy tab, and then search for and select AliyunECSFullAccess (permissions to manage Elastic Compute Service).
Create a resource group named DepartmentA for Department A and a resource group named DepartmentB for Department B.

For more information, see Create a resource group.
Grant the Department A administrator the AliyunESSFullAccess policy, scoped to the DepartmentA resource group.

For more information, see Grant permissions on a resource group to a RAM identity or Grant permissions to a RAM user.
Repeat Step 4 to grant the Department B administrator the AliyunESSFullAccess policy, scoped to the DepartmentB resource group.

Set Permission Scope to the specific resource group DepartmentB, and select the RAM user for the Department B administrator as the Principal.

Verify the result

Log on to the Auto Scaling console.
In the upper-left corner of the top navigation bar, select different resource groups and attempt to create a scaling group.

For more information, see Create a scaling group.
- When you select DepartmentA, the Department A administrator can successfully create a scaling group in the DepartmentA resource group.
  
  On the Scaling Groups page, the scaling group ScalingGroup-A is displayed with type ECS and status Enabled.
- When you select DepartmentB, the Department A administrator does not have permission to create a scaling group in the DepartmentB resource group.
  
  The console returns the error code Forbidden.Unauthorized. The policy type is Identity-based policy (resource-group-level), and the permission decision is Implicitly denied.
Verify whether the Department A administrator can view scaling groups in different resource groups.

For more information, see View scaling groups.
- The Department A administrator can successfully view scaling groups in the DepartmentA resource group.
  
  The Scaling Groups page displays ScalingGroup-A with type ECS, status Enabled, a maximum of 1 instance, and no running instances.
- When the Department A administrator attempts to view scaling groups in the DepartmentB resource group, permission is denied.
  
  The error details show the error code Forbidden.Unauthorized, authentication action ess:DescribeScalingGroups, policy type Identity-based policy (resource-group-level), and permission decision Implicitly denied.