Service-linked roles

What is a service-linked role?

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

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

• Assumable only by the linked service: An SLR can only be assumed by its linked Alibaba Cloud service. No other identity can use it.

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

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

Why use service-linked roles

Without service-linked roles, when one cloud service needs to access another, you must manually create RAM roles and configure complex access policies and trust policies. This process is tedious and prone to configuration errors, which can lead to service disruptions or security risks. Service-linked roles solve these problems:

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

• Reduces configuration complexity and the risk of misconfiguration. The access policy of an SLR is predefined by the Alibaba Cloud service. This ensures that each service is granted only the minimum permissions required for its tasks, and you do not need to configure permissions manually. This improves account security and ensures stable service operation.

How it works

The following example uses Cloud Config to explain how service-linked roles work:

1. Alibaba Cloud predefines the service-linked role: For Cloud Config, Alibaba Cloud predefines an SLR named AliyunServiceRoleForConfig. This role includes:

   • A trust policy: Allows only config.aliyuncs.com to assume the role. This ensures that only Cloud Config can use it.

   • An access policy: Grants permissions to read resource information from cloud services like ECS and ApsaraDB 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 SLR to obtain temporary credentials.

3. The service uses the role to access other cloud services: Cloud Config uses the SLR's identity and permissions to securely access other services, such as ECS and ApsaraDB RDS, and read information like resource lists and configurations.

4. The service completes its function: After obtaining the required cloud resource information, Cloud Config generates compliance reports.

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

Differences between SLRs and service roles

Both service-linked roles and service roles are assumed by cloud services and grant them the permissions needed to function. However, they differ fundamentally in how they are used.

Permissions to manage service-linked roles

To create or delete a service-linked role, a RAM user needs specific permissions. These permissions are typically granted through the corresponding service's administrator policy, such as AliyunResourceDirectoryFullAccess.

You can also configure a custom policy to grant a RAM user permissions to manage SLRs for a specific service. The following sample policy allows a RAM user to create and delete SLRs for the Resource Management service. You can find the value for ram:ServiceName in the Service identifier column of 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"
        }
      }
    }
  ]
}

Create a service-linked role

• Creation by the cloud service: In most cases, a cloud service automatically creates an SLR 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 SLR. For details about automatic SLR creation, refer to the documentation for the specific service: Cloud services that support service-linked roles.

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

Delete a service-linked role

• Deletion by the cloud service: A cloud service automatically deletes its associated SLR when you perform certain actions, such as deleting all related resources or disabling a feature.

• Manual deletion: You can also delete a service-linked role manually. For instructions, see Delete a RAM role. Before manual deletion, RAM checks whether the role is still being used by any cloud resources:

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

  • If the role is still in use, the deletion fails. The prompt message shows which cloud resources are using the role. You must manually clean up these resources before you can delete the role. Deletion conditions vary by service. For details, refer to the specific service's documentation in Cloud services that support service-linked roles.

Assume a service-linked role

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

Monitor SLR creation and usage

You can use ActionTrail to audit the lifecycle and usage of service-linked roles.

• Query by event name:

  • CreateServiceLinkedRole: Queries for events related to the creation of SLRs.

  • DeleteServiceLinkedRole: Queries for events related to the deletion of SLRs.

  • AssumeRole: Queries for events where a cloud service assumes an SLR. 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 the Operator field for a specific service-linked role name. This allows you to query all actions performed by that SLR.

FAQ