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 service-linked roles, you would need to manually create RAM roles and configure complex permission and trust policies whenever a cloud service needs to access another. This process is tedious and prone to misconfiguration, which can lead to service failures or security risks. Service-linked roles solve these problems:

• Simplifies cross-service authorization on Alibaba Cloud. 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 a service-linked role, Cloud Config obtains the required permissions to operate.

• Reduces configuration complexity and operational risk. The permission policy of a service-linked role is predefined by the associated cloud service, ensuring that the service receives only the minimum permissions required to complete its tasks. This eliminates the need for manual permission configuration, which enhances security and ensures operational stability.

How it works

The following example using Cloud Config explains how service-linked roles 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.

This way, Cloud Config can securely and conveniently access other services without requiring you to manually configure complex permission policies.

Service-linked roles vs. service roles

Similar to service roles, service-linked roles are assumed by a cloud service and grant the service the necessary permissions. However, they are fundamentally different in how they are used:

Required permissions

A RAM user needs specific permissions to create or delete a service-linked role. These permissions are typically included in the administrator permission 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 can be obtained from 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 service-linked roles.

• Query by event name:

  • CreateServiceLinkedRole: Query for events related to the creation of service-linked roles.

  • DeleteServiceLinkedRole: Query for events related to the deletion of service-linked roles.

  • AssumeRole: Find events where a cloud service assumed a service-linked role. In the event details, the userIdentity section contains the cloud service name, and the requestParameters section 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 a specific service-linked role name. This allows you to query the operations performed by that SLR.

FAQ