Use tags to manage scaling group permissions - Auto Scaling

Auto Scaling lets you categorize and control access to scaling groups by using tags. You can grant fine-grained permissions to individual scaling groups or to multiple groups that share a specific tag. This topic explains how to use tag-based authentication to manage RAM user permissions, which improves management efficiency and reduces the risk of data leaks.

Background

A tag is an identifier for a cloud resource. You can use tags to categorize, search for, and aggregate cloud resources with the same characteristics from different dimensions. For more information, see Tags.
Resource Access Management (RAM) allows you to manage user identities and control access to and operations on your cloud resources based on policies. For more information, see What is RAM?.

By using tags as conditions in a Resource Access Management (RAM) policy, you can implement fine-grained control over Auto Scaling.

The following figure shows how to use tags to manage resource access and operation permissions of RAM users, which is called tag-based authentication.

APIs that do not support tag authentication

After you attach a policy for tag-based authentication to a RAM user, tag-based authentication is not supported when the RAM user calls the following API operations to manage Auto Scaling.

API	Tag authentication support
DescribeRegions	No
For scheduled tasks not associated with a scaling group: CreateScheduledTask ModifyScheduledTask DescribeScheduledTasks DeleteScheduledTask	No
For event-triggered tasks not associated with a scaling group: CreateAlarm DescribeAlarms ModifyAlarm EnableAlarm DeleteAlarm	No

Example scenario

This topic uses the following scenario to show how to implement tag-based authentication.

Assume that you have created two scaling groups for game development. Each scaling group is tagged by environment and team. You need to grant a RAM user specific permissions on the following scaling groups:

Scaling group	Name	Tag
Scaling group 1	asg-001	Tag 1: environment:test, where the tag key is environment and the tag value is test. Tag 2: team:game1, where the tag key is team and the tag value is game1.
Scaling group 2	asg-002	Tag 1: environment:dev, where the tag key is environment and the tag value is dev. Tag 2: team:game2, where the tag key is team and the tag value is game2.

The specific access control requirements are as follows:

Scenario 1: You cannot create scaling groups without tags. Scaling group 1 can be created successfully only if you add the environment:test and team:game1 tags to it during creation.
Scenario 2: When querying scaling groups, you can view only the resources of scaling group 1, which is bound with the environment:test and team:game1 tags.
Scenario 3: You are allowed to manage only resources in scaling group 1 (with the tags environment:test and team:game1), but not resources in scaling group 2 (with the tags environment:dev and team:game2).

Procedure

Note

Before you start, make sure that you have created a RAM user. For more information, see Create a RAM user.

Create two scaling groups.

For more information, see Configure scaling groups. See Example scenario for details about the scaling groups.
Log on to the RAM console.

Create a custom policy.

For more information, see Create a custom policy.

You can set multiple tag conditions for cloud resources in the Condition block of a policy to restrict permissions to perform operations on Auto Scaling resources. Supported tag-based authentication conditions:

Tag-based condition

Description

acs:RequestTag

Checks whether the request includes a specific tag.

If an API request does not include any tag parameters, using acs:RequestTag will cause authentication to fail.

acs:ResourceTag

Checks whether the resource specified in the request contains a specific tag.

If you use acs:ResourceTag in an API request that does not contain a resource ID parameter, authentication will fail.

The following code block shows a complete policy example:

{
    "Version": "1",
    "Statement": [
         {
           "Effect": "Allow",
           "Action": "ess:Create*",
           "Resource": "*",
           "Condition": {
                   "StringEquals": {
                        "acs:RequestTag/environment": "test",
                        "acs:RequestTag/team": "game1"
                   }
              }
         },
         {
            "Effect": "Allow",
            "Action": "ess:Describe*",
            "Resource": "*",
            "Condition": {
                    "StringEquals": {
                    "acs:RequestTag/environment": "test",
                    "acs:RequestTag/team": "game1"
                    }
              }
         },
         {
            "Action": "ess:*",
            "Effect": "Allow",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "acs:ResourceTag/environment": "test",
                    "acs:ResourceTag/team": "game1"
                  }
              }
         },
         {
            "Effect": "Allow",
            "Action": [
                   "ess:Describe*",
                   "ess:List*",
                   "ess:DescribeRegions",
                   "ess:CreateScheduledTask",
                   "ess:ModifyScheduledTask",
                   "ess:DescribeScheduledTasks",
                   "ess:DeleteScheduledTask",
                   "ess:CreateAlarm",
                   "ess:DescribeAlarms",
                   "ess:ModifyAlarm",
                   "ess:EnableAlarm",
                   "ess:DeleteAlarm"
                ],
    "Resource": "*"
      }
   ]
}

Scenario 1: Enforce specific tags during scaling group creation

That is, scaling group 1 can be created successfully only if environment:test and team:game1 tags are bound to it during creation.

The following policy corresponds to this scenario:
```
{
    "Effect": "Allow",
    "Action": "ess:Create*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "acs:RequestTag/environment": "test",
            "acs:RequestTag/team": "game1"
        }
    }
}
```
Scenario 2: Allow users to view only scaling group 1

This means that if you attach the environment:test and team:game1 tags to scaling group 1, only the resources of scaling group 1 are returned when you query for scaling groups.

The following policy corresponds to this scenario:
```
{
    "Effect": "Allow",
    "Action": "ess:Describe*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "acs:RequestTag/environment": "test",
            "acs:RequestTag/team": "game1"
        }
    }
}
```

Scenario 3: Allow users to manage only scaling group 1 and deny access to scaling group 2

For example, scaling group 1 is bound to the environment:test and team:game1 tags, while scaling group 2 is bound to the environment:dev and team:game2 tags.

The following policy corresponds to this scenario:

{
    "Version": "1",
    "Statement": [
        {
            "Action": "ess:*",
            "Effect": "Allow",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "acs:ResourceTag/environment": "test",
                    "acs:ResourceTag/team": "game1"
                }
            }
        },
        {
            "Action": "ess:*",
            "Effect": "Deny",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "acs:ResourceTag/environment": "dev",
                    "acs:ResourceTag/team": "game2"
                }
            }
        },      
        {
           "Effect": "Allow",
           "Action": [
                   "ess:DescribeRegions",
                   "ess:CreateScheduledTask",
                   "ess:ModifyScheduledTask",
                   "ess:DescribeScheduledTasks",
                   "ess:DeleteScheduledTask",
                   "ess:CreateAlarm",
                   "ess:DescribeAlarms",
                   "ess:ModifyAlarm",
                   "ess:EnableAlarm",
                   "ess:DeleteAlarm"
                ],
    "Resource": "*"
      }
   ]
}

Attach the custom policy to the RAM user.

For more information, see Grant permissions to a RAM user.
Verify that the policy takes effect.
- Verify Scenario 1 by creating scaling group 1
  - Scaling Group 1 has the tags environment:test and team:game1, so it can be successfully created.
  - If you create the scaling group without the specified tags, the creation is denied due to insufficient permissions. A different error occurs if Auto Scaling lacks the necessary OpenAPI permissions: the Forbidden.Unauthorized error is returned with the message: The user has not fully authorized the OpenAPI interface for ESS. Please authorize and try again. In this case, grant the required permissions and retry the operation.
- Verify Scenario 2 by querying scaling groups
  - For a scaling group that has the tags environment:test and team:game1, you can still retrieve its information by performing a query without filtering by tags.
  - If you query for a scaling group other than scaling group 1 that is not tagged with environment:test and team:game1, the query returns no results.
  - If you do not specify a scaling group and search only for the environment:test and team:game1 tags, the query returns all scaling groups that have these tags.
- Verify Scenario 3 by deleting scaling groups
  - If scaling group 1 has the tags environment:test and team:game1, you can delete the scaling group.
  - If a scaling group is not associated with the tags environment:test and team:game1, or if it has other tags, a message is displayed indicating that you do not have the permission to delete the scaling group.

Auto Scaling:Use tags to manage scaling group permissions

Background

APIs that do not support tag authentication

Example scenario

Procedure

Related documents