Updated on 2025-11-07 GMT+08:00

Overview

A trust agency is an IAM identity with specific permissions that you can create in your account. Similar to IAM users, trust agencies can be bound to identity policies. Identity policies determine what an identity can and cannot do on Huawei Cloud. However, a trust agency is not attached to only one user. Instead, it can be used by anyone who needs it. Unlike IAM users, trust agencies do not have long-term credentials (such as passwords or permanent access keys) associated with them. When you switch to a trust agency, the trust agency provides temporary security credentials for your assumed-trust agency session.

You can use trust agencies to delegate access to IAM users, applications, or cloud services that need to access your Huawei Cloud resources. For example, you may want to grant access to IAM users in your account, or to IAM users in another account, or you may want to allow mobile applications to use Huawei Cloud resources without embedding permanent access keys in the applications. In these scenarios, you can use trust agencies to manage access to Huawei Cloud resources.

When you create an account, no trust agencies are created by default. When you use Huawei Cloud services, these services may automatically create service-linked agencies. A service-linked agency is a special agency whose principal is a cloud service. Cloud services can assume service-linked agencies to perform operations on your behalf. For details about service-linked agencies, see Service-linked Agency.

Types of Trust Agencies

A trust relationship can be established between your account and another account or a cloud service.

  • Account delegation: You can delegate another Huawei Cloud account or more professional third-party accounts to perform resource O&M on your behalf according to the granted permissions.
  • Cloud service delegation: You can create a trust agency to delegate a cloud service to perform O&M on your resources.

    There is a special type of trust agency called service-linked trust agency. It is directly linked to a cloud service. It is similar to but different from a service trust agency. When using service trust agencies, you may encounter the following:

    • You need to create a service trust agency and assign the least privilege access to it, but you may not know the minimum permission set required by it.
    • You have full permissions for a service trust agency and may configure an inappropriate or accidentally delete an identity policy, affecting the service usage.
      With service-linked trust agencies, you can resolve these issues. The following table lists the differences between a service trust agency and a service-linked trust agency.
      Table 1 Differences between a service trust agency and a service-linked trust agency

      Agency Type

      Create

      Delete

      Permissions

      Restricted by SCP

      Visible to Users

      Service trust agency

      Created by users or cloud services on behalf of users

      Deleted by users

      Granted by the user-configured identity policies

      Yes

      Yes

      Service-linked agency

      Created by cloud services on behalf of users

      Deleted by cloud services on behalf of users

      Cannot be granted by user or modified by user-configured identity policies. Cloud services predefine the least permissions.

      No

      Yes

Agency Chaining

Agency chaining is when you use an agency to assume a second agency. You can use APIs, CLI, or SDKs to switch agencies. For example, agency A has the permission to assume agency B. You use the permanent access key of IAM user A to call the AssumeAgency API to assume agency A. This returns the temporary security credentials of agency A. With agency chaining, you can use those temporary security credentials to enable IAM user A to assume agency B.

When you assume an agency, you can pass a session tag and set the tag as transitive. Transitive session tags are passed to all subsequent sessions in an agency chain. For more information about session tags, see Passing Session Tags.

An agency chain limits the assumed-agency session of your API, CLI, or SDK to a maximum of one hour, regardless of the maximum session duration configured for a single agency. When you use the AssumeAgency API to switch to a trust agency, you can use the duration_seconds parameter to specify the duration of the assumed-agency session. You can specify a value of up to 43,200 seconds (12 hours), depending on the maximum session duration setting of your trust agency. However, if you use the agency chaining to switch to another trust agency and provide a duration_seconds value greater than one hour, the switch will fail.

Trust Policy

Generally, identity policies are assigned to IAM identities for authorization. In resource-based authorization, permissions are assigned to a resource to define which principals can perform what operations on the resource. The trust policy is a typical resource-based policy in trust agencies.

When a trust agency is used as an identity, you can attach identity policies to the trust agency for permission control. When a trust agency is used as a resource, you can grant the trust agency permissions to an account or a cloud service. In an agency, you specify an account or a cloud service to establish a trust relationship. In a trust agency, you use policy language to describe the trust relationship between accounts or between an account and a cloud service. In a trust policy, you can specify either an account or a cloud service as the trust principal. When you specify your account as the trust principal, authorization is performed within the account. When you specify another account or a cloud service as the trust principal, authorization is performed across accounts. In addition, you can use global condition keys such as "g:SourceAccount" to avoid security issues such as confused deputy. When a trust agency is used as a resource, it must have trust policies attached so that you can obtain the temporary security credential of the trust agency.
{
	"Version": "5.0",
	"Statement": [{
		"Principal": {
			"IAM": ["<Account Id Of Account B>"],
			"Service": ["service.OBS"]
		},
		"Action": ["sts:agencies:assume", "sts::tagSession", "sts::setSourceIdentity"],
		"Condition": {
			"DateGreaterThan": {
				"g:CurrentTime": "2024-01-01T12:00Z"
			},
			"DateLessThan": {
				"g:CurrentTime": "2024-01-01T15:00Z"
			}
		},
		"Effect": "Allow"
	}]
}

In this example, account A uses a trust agency to establish a trust relationship for account B and OBS. Principals with trust agency permissions in account B and OBS can switch to the trust agency of account A from 12:00 on January 1, 2024 (UTC) to 15:00 on January 1, 2024 (UTC). You can also set assumed-agency session tags and source identity information to define the delegated party that switches to the trust agency to access Huawei Cloud.

In the example trust policy, <Account Id Of Account B> represents account B, service.OBS represents OBS, g:CurrentTime indicates the condition key for controlling the switch window, sts:agencies:assume indicates the action for granting permissions to switch to the trust agency, sts::tagSession indicates the action for granting permissions to set session tags, and sts::setSourceIdentity indicates the action for granting permissions to set source identity information.

In conclusion, trust agencies can establish trust relationships for multiple principals and multiple types of principals through trust policies, and can use actions and condition keys to perform fine-grained access control on trust agency switch operations performed by delegated parties. In comparison, an agency cannot establish trust relationships for multiple principals and multiple types of principals, nor can it perform fine-grained access control on trust agency switch operations performed by delegated parties. If you still need to use such agencies, see Agencies.