Confused Deputy Problem

Preventing Cross-Account Confused Deputy

The following figure shows the cross-account confused deputy problem.

Figure 1 Cross-account confused deputy

In this example, your account A created the trust agency A to trust a third-party company. Here is how confused deputy occurred:

1. When you use the third-party company's service, you provide the URN of trust agency A to the third-party company.
2. The company uses the URN of the trust agency to obtain temporary security credentials to access resources in your account.
3. Account B also starts using the third-party company's service. Because the URN of trust agency A is not confidential, account B may have guessed the URN of trust agency A and provided it to the third-party company.
4. When account B asks the company to access resources in its (what it claims to be) account, the company uses the URN of trust agency A to access resources in account A.

This is how another account can access your resources without your authorization. Account B can now trick the company into operations on your resources, so the company is now a confused deputy.

{
	"Version": "5.0",
	"Statement": [{
		"Action": [
			"sts:agencies:assume"
		],
		"Effect": "Allow",
		"Principal": {
			"IAM": [
				"AccountA ID"
			]
		},
		"Condition": {
			"StringEquals": {
				"sts:ExternalId": [
					"123456"
				]
			}
		}
	}]
}

The "Condition" element in the trust policy allows the third-party company to call the AssumeAgency API with the ExternalId parameter set to 123456. The third-party company must ensure that the ExternalId of the customer is always passed in AssumeAgency API calls. This ensures that even if account B provides the URN of your trust agency A to the third-party company, ExternalId is always passed by the third-party company in the AssumeAgency API. The following figure shows how ExternalId is passed.

Figure 2 Process of passing ExternalId

1. As before, when you use the third-party company's service, you provide the URN of trust agency A to the third-party company.
2. The third-party company calls the AssumeAgency API and passes the ExternalId to obtain the temporary security credentials of trust agency.
3. Account B also starts using the third-party company's service, and provides the URN of trust agency A to the third-party company.
4. But this time, when account B requests the third-party company to access the so called "its" resources, the third-party company calls the AssumeAgency API and passes the ExternalId (456789) associated with account B. Since you only added your ExternalId (123456) but not the ExternalId (456789) of account B to the trust policy, the AssumeAgency API fails to use the URN of trust agency A.

Preventing Cross-Service Confused Deputy

To prevent unauthorized accounts from accessing your Huawei Cloud resources using trust agencies, Huawei Cloud service principals provide the information about the Huawei Cloud accounts and resources they represent. This information is included in the request context in the form of global condition keys g:SourceAccount and g:SourceUrn. The two condition keys can be used to solve the cross-service confused deputy problem.

In the following example, account A creates a trust agency A, trusts the cloud service B, and attaches the trust agency to the tasks of cloud service B.

{
	"Version": "5.0",
	"Statement": [{
		"Action": [
			"sts:agencies:assume"
		],
		"Effect": "Allow",
		"Principal": {
			"Service": [
				"service.B"
			]
		}
	}]
}

The trust agency URN is not a secret. If attacker account C runs a task in service B and uses trust agency A for task execution, service B may use trust agency A to access your resources. The cross-service confused deputy occurs. The following describes how to use the global condition keys g:SourceAccount and g:SourceUrn to solve this problem.

• g:SourceAccount
  g:SourceAccount specifies the account for which cloud services acquire temporary credentials. If you add the g:SourceAccount condition key when creating a trust agency for service B, service B can only use trust agency A to obtain temporary credentials for account A. If attacker account C also sends a request to service B, IAM will check the condition key and reject the request.

  {
  	"Version": "5.0",
  	"Statement": [{
  		"Action": [
  			"sts:agencies:assume"
  		],
  		"Effect": "Allow",
  		"Principal": {
  			"Service": [
  				"service.B"
  			]
  		},
  		"Condition": {
  			"StringEquals": {
  				"g:SourceAccount": [
  					"AccountA ID"
  				]
  			}
  		}
  	}]
  }

• g:SourceUrn
  g:SourceUrn specifies the resource for which cloud services acquire temporary credentials. If you add the g:SourceUrn condition key when creating a trust agency for service B, service B can only use trust agency A to obtain temporary credentials for the specified resource. If attacker account C also sends a request to service B, IAM will check the g:SourceUrn condition key and reject the request.

  {
  	"Version": "5.0",
  	"Statement": [{
  		"Action": [
  			"sts:agencies:assume"
  		],
  		"Effect": "Allow",
  		"Principal": {
  			"Service": [
  				"service.B"
  			]
  		},
  		"Condition": {
  			"StringEquals": {
  				"g:SourceUrn": [
  					"Specific Resource URN"
  				]
  			}
  		}
  	}]
  }