Service-linked role

Overview

A service-linked role (SLR) is a type of RAM role predefined by Alibaba Cloud to enable cross-service access. It has the following features:

• Linked to a specific cloud service: An SLR is a special type of RAM role that is linked to a specific Alibaba Cloud service.

• Assumed only by the linked service: An SLR can be assumed only by the Alibaba Cloud service to which it is linked. No other identity can use it.

• Predefined by Alibaba Cloud: The role, its permissions, and its trust policy (which specifies the cloud service that can assume the role) are all predefined by the associated cloud service.

• Maintenance-free: You do not need to manually configure or maintain an SLR.

Benefits

Without SLRs, you must manually create RAM roles and configure permission and trust policies each time a cloud service needs to access another. This is error-prone and can lead to service failures or security risks. SLRs solve these problems:

• Simplifies cross-service authorization. For example, Cloud Config needs permission to read your cloud resource information, such as resource lists and configurations, to generate compliance reports. This requires access to other cloud services like ECS and RDS. By creating and assuming an SLR, Cloud Config obtains the required permissions.

• Reduces configuration complexity and operational risk. The permission policy of an SLR is predefined by the associated cloud service to grant only the minimum permissions required. This eliminates manual permission configuration, enhancing security and operational stability.

How it works

The following example uses Cloud Config to show how SLRs work:

1. Alibaba Cloud predefines the service-linked role: Alibaba Cloud predefines a service-linked role for Cloud Config, named AliyunServiceRoleForConfig. This role includes:

   • A trust policy that allows only config.aliyuncs.com to assume the role, ensuring that only the Cloud Config service can use it.

   • A permission policy that grants permissions to read resource information from cloud services such as ECS and RDS.

2. Cloud Config assumes the role: When Cloud Config needs to read your cloud resource information to generate a compliance report, it assumes its service-linked role to obtain temporary security credentials.

3. Cloud Config accesses other cloud services: Cloud Config uses the identity and permissions of the service-linked role to securely access other cloud services like ECS and RDS to read resource lists and configurations.

4. Completes the task: After obtaining the required cloud resource information, Cloud Config generates the compliance report.

Cloud Config can then securely access other services without requiring you to manually configure permission policies.

Service-linked roles vs. service roles

Like service roles, SLRs are assumed by a cloud service to obtain the necessary permissions. However, they differ in how they are used:

Required permissions

A RAM user needs specific permissions to create or delete an SLR. These permissions are typically included in the administrator policy for the corresponding cloud service, such as AliyunResourceDirectoryFullAccess. If a RAM user has administrator permissions for a cloud service, they can usually create an SLR for that service.

You can also create a custom policy to grant a RAM user permissions to manage SLRs for a specific service. The value for ram:ServiceName is listed in the Cloud Service Identifier column in Cloud services that support service-linked roles.

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

Creating a service-linked role

• Created by a cloud service: In most cases, a cloud service automatically creates a service-linked role when you perform a specific action, such as creating a cloud resource or enabling a feature. Alternatively, the service may prompt an administrator for authorization to create the role. For details about automatic SLR creation, see the documentation for the corresponding cloud service in Cloud services that support service-linked roles.

• Created manually: You can also create a service-linked role manually. For instructions, see Create a service-linked role.

Deleting a service-linked role

• Deleted by a cloud service: A cloud service automatically deletes its associated service-linked role when you perform a specific action, such as deleting all related resources or disabling a feature.

• Deleted manually: You can also delete a service-linked role manually. For instructions, see Delete a RAM role. Before you manually delete an SLR, Resource Access Management (RAM) checks whether the role is still in use by any cloud resources:

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

  • If the role is still in use, the deletion fails. The error message shows which cloud resources are using the role. You must remove these resources before you can delete the role. Deletion conditions for SLRs vary by cloud service. For details, see the documentation for the specific cloud service in Cloud services that support service-linked roles.

Assuming a service-linked role

A service-linked role can be assumed only by its linked cloud service. Other identities, such as RAM users or other RAM roles, cannot assume the SLR.

Monitoring service-linked roles

You can use ActionTrail to audit the lifecycle and usage of SLRs.

• Query by event name:

  • CreateServiceLinkedRole: Query creation events for SLRs.

  • DeleteServiceLinkedRole: Query deletion events for SLRs.

  • AssumeRole: Find events where a cloud service assumed an SLR. In the event details, the userIdentity section contains the cloud service name, and requestParameters contains the ARN of the assumed SLR. For example:

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

• Query by event type:

  Set the event type to AliyunServiceEvent and filter by Operator Name using an SLR name. This shows the operations performed by that SLR.

FAQ