Resource Access Management:Service-linked roles

What is an SLR?

A service-linked role (SLR) is a unique type of Resource Access Management (RAM) role that is linked directly to an Alibaba Cloud service. The service can assume this role to perform actions in other services on your behalf.

• An SLR's trust policy is predefined and allows only the linked cloud service to assume it. No other principals, such as a RAM user or another role, can assume an SLR.

• An SLR's access policies are also predefined by the cloud service. You cannot modify the policies or attach additional ones. This ensures that the service only has the permissions it needs to function (principle of least privilege).

How it works

The following example shows how Cloud Config uses an SLR:

1. When you activate Cloud Config, the service creates its SLR—AliyunServiceRoleForConfig—in your account.

   • Trust policy: Allows only config.aliyuncs.com to assume the role, which ensures that only Cloud Config can use it.

   • Access policy: Grants permissions to access resources from Alibaba Cloud services such as ECS and ApsaraDB RDS.

2. The service assumes the SLR. Cloud Config (acting as the service principal config.aliyuncs.com) assumes this SLR to obtain temporary credentials.

3. The service performs actions. Using the SLR's credentials, Cloud Config makes read-only API calls to services like ECS and ApsaraDB RDS to retrieve configuration data and generate compliance reports.

In this way, Cloud Config can securely and easily access other services without your having to configure complex access policies manually.

Manage SLRs

This section describes the permissions required to manage SLRs and the procedures for creating and deleting them.

A RAM user needs the ram:CreateServiceLinkedRole and ram:DeleteServiceLinkedRole permissions to create and delete SLRs, respectively. These permissions are typically included in the full-access system policy for the corresponding service (such as AliyunResourceDirectoryFullAccess).

Alternatively, you can create a custom policy to grant permissions for managing SLRs for a specific service. The following policy allows a RAM user to create and delete SLRs for the Resource Management service only. For ram:ServiceName values, see the "Service identifier" column in Services that work with service-linked roles.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ram:CreateServiceLinkedRole",
        "ram:DeleteServiceLinkedRole"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ram:ServiceName": "resourcemanager.aliyuncs.com"
        }
      }
    }
  ]
}

Create an SLR

• Automatic creation: In most cases, the linked service creates the SLR for you automatically the first time you use a feature that requires it. This might happen when you enable a service, create a resource, or perform another action in the service's console.

• Manual creation: If the SLR was not created automatically, you can create it manually through the RAM console, API, or CLI. For instructions, see Create an SLR.

Delete an SLR

• Automatic deletion: Some services may automatically delete the SLR when you disable the service or delete all of its associated resources.

• Manual deletion: You can manually delete an SLR using the RAM console, API, or CLI. When you attempt to delete an SLR, RAM checks if it is still in use.

  • If the role is not in use, the deletion succeeds.

  • If the role is in use, the deletion fails and an error message indicates which resources are still using the role. You must remove those dependent resources before you can delete the SLR. For the specific cleanup steps for each service, see the service's documentation.

Assume an SLR

Only the linked cloud service can assume its SLR. You cannot directly assume an SLR from the console or by calling AssumeRole as a user or another role.

Monitor SLRs with ActionTrail

You can track the creation, deletion, and usage of SLRs by reviewing your ActionTrail logs.

• Audit SLR lifecycle and assumption

  To track when an SLR is created, deleted, or assumed, search for the following event names in the ActionTrail console:

  • CreateServiceLinkedRole: Records the creation of an SLR.

  • DeleteServiceLinkedRole: Records the deletion of an SLR.

  • AssumeRole: Records when a service assumes an SLR. In the event details, the userIdentity.principalId field shows the service principal (such as tag.aliyuncs.com), and the requestParameters.RoleArn field shows the ARN of the SLR that was assumed.

    {
      ...
      "requestParameters": {
        ...
        "RoleArn": "acs:ram::ACCOUNT_ID:role/aliyunservicerolefortag",
        "RoleSessionName": "tag_operate",
      },
      ...
      "userIdentity": {
        ...
        "principalId": "tag.aliyuncs.com",
        "userName": "tag.aliyuncs.com"
      },
      "eventName": "AssumeRole"
    }
    

• Audit SLR activity

  To see the actions performed by an SLR after it has been assumed, search for the SLR name in the Operator filter.

FAQ