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

Creating a Trust Agency (by a Delegating Party)

By creating a trust agency, you can share your resources with another account, or delegate an individual or team to manage your resources. You do not need to share your security credentials (the password and access keys) with the delegated party. Instead, the delegated party can log in with its own account credentials and then switches the role to your account and manage your resources.

Prerequisites

Before creating a trust agency, complete the following operations:

Procedure

  1. Log in to the new IAM console.
  2. On the IAM console, choose Agencies in the navigation pane, and click Create Trust Agency in the upper right corner.

    Figure 1 Creating a trust agency

  3. Enter a trust agency name.

    Figure 2 Setting the trust agency name

  4. Select Account for Agency Type and enter the ID of the delegated account. After obtaining the account ID on the My Credentials page, the delegated user can provide the account ID to the delegator.

    • Account: Delegate resource access to another account. By default, all principals in an account that have the permissions to assume trust agencies can switch to the trust agency. You can use the g:PrincipalUrn condition key to allow only a specific principal (such as an IAM user or trust agency) in the account to assume trust agencies. For details about the g:PrincipalUrn condition key, see Global Condition Keys.
    • Cloud service: Delegate resource access to another cloud service. For details, see Cloud Service Delegation.

  5. Set Maximum Session Duration to configure the maximum session duration of the temporary access credentials obtained by programmatic access.
  6. Choose whether to select External ID. The external ID of the delegated party must be unique.

    The external ID can be any identifier (for example, the invoice number) known only to you and the delegated party. Do not use easily-guessed information, such as the name or phone number of the delegated party. If you select External ID, the entered ID will be added to the trust policy for check to ensure that the delegated party performs correct operations. For details about using external IDs, see Preventing Cross-Account Confused Deputy.

  7. Determine whether to enable MFA.

    After MFA is enabled, the delegated party needs to enter the verification code sent to the virtual MFA device on the login verification page to verify its identity.

  8. Edit the trust agency by referring to Deleting or Modifying an Agency (by a Delegated Party).
  9. Enter a brief description.
  10. Click OK to enter the page for assigning permissions to a trust agency.
  11. Assign permissions to an IAM user by referring to Assigning Permissions to an IAM User.

    For security purposes, it is a best practice to grant least privilege.

  12. Click OK. The trust agency is created.

    The delegating account notifies the delegated account of its account name, the name and URN of the trust agency, the permissions assigned to the trust agency, and the external ID (if any). The delegated account can then switch role or call AssumeAgency API to switch to the delegating account for resource management.

Example Policies

When delegating an account to manage Huawei Cloud resources, you need to configure the trust policy and identity policy of the trust agency. The trust policy specifies who can assume the trust agency, and the identity policy specifies what operations the assumed-agency session can perform after the assumption. Both trust and identity policies are in JSON format. For the JSON elements supported by the policies, see JSON Element Reference.

Assume that account A is the delegating party and account B is the delegated party. The following trust policy example allows IAM users in account B to assume the trust agency of account A after passing multi-factor authentication (MFA). Replace <account-id-b> with the actual account ID of account B.
{
    "Version": "5.0",
    "Statement": [
        {
            "Principal": {
                "IAM": [
                    "<account-id-b>"
                ]
            },
            "Effect": "Allow",
            "Action": [
                "sts:agencies:assume"
            ],
            "Condition": {
                "Bool": {
                    "g:MFAPresent": [
                        "true"
                    ]
                }
            }
        }
    ]
}

Note that, although the trust policy allows the trusted principal to assume the trust agency, the IAM users in account B must have sts:agencies:assume in the identity policy. After the required permissions are granted, the IAM users in account B can assume the trust agency through the console or by calling the AssumeAgency API to obtain the temporary security credentials of the assumed-trust agency session. For more information about temporary security credentials, see Overview.

When you use the AssumeAgency API, if the source_identity parameter of the source identity information is passed, you also need to include the sts::setSourceIndentity permission in the trust policy. If the tags parameter of the session tag is passed, you also need to include the sts::tagSession permission in the trust policy. The example trust policy is as follows:
{
    "Version": "5.0",
    "Statement": [
        {
            "Principal": {
                "IAM": [
                    "<account-id-b>"
                ]
            },
            "Effect": "Allow",
            "Action": [
                "sts:agencies:assume",
                "sts::setSourceIdentity",
                "sts::tagSession"
            ],
            "Condition": {
                "Bool": {
                    "g:MFAPresent": [
                        "true"
                    ]
                }
            }
        }
    ]
}

If you need to add sts::setSourceIndentity and sts::tagSession to the trust policy, edit the trust policy after creating the trust agency.

If you want only a specified IAM user in account B to be able to assume the trust agency, you can use the g:UserId condition key. The following is an example trust policy:
{
  "Version": "5.0",
  "Statement": [
    {
      "Principal": {
        "IAM": [
          "<account-id-b>"
        ]
      },
      "Effect": "Allow",
      "Action": [
        "sts:agencies:assume",
        "sts::tagSession",
        "sts::setSourceIdentity"
      ],
      "Condition": {
        "Bool": {
          "g:MFAPresent": [
            "true"
          ]
        },
        "StringEquals": {
          "g:UserId": [
            "<user-id-1>"
          ]
        }
      }
    }
  ]
}

Replace <user-id-1> with the actual IAM user ID in account B. You can also add more condition keys to the trust policy to control the conditions for switching trust agencies. For more information, see Global Condition Key and iam_01_1289.html#iam_01_1289__li13495143171719.

After the trust agency is created, the permissions of the IAM user in account B depend on the permissions granted by the identity policy attached to the trust agency. For example, you can attach the following identity policy to allow the session after switching the trust agency to list specified OBS buckets.
{
    "Version": "5.0",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "obs:bucket:ListBucket"
            ],
            "Resource": [
                "OBS:*:*:bucket:example_bucket"
            ]
        }
    ]
}