External ID
https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/
When you need to grant access to your AWS resources to a third party, AWS recommend you do so using an IAM role with external ID.
AWS does not treat the external ID as a secret. The external ID for a role can be seen by anyone with permission to view the role.
To provide an external ID when you assume a role, use the AWS CLI or AWS API to assume that role.
If you want to provide a third party with access to your AWS resources - a recommended best practice is to use IAM roles.
The external ID is a piece of data that can be passed to the AssumeRole API of the Security Token Service (STS). You can then use the external ID in the condition element in a role’s trust policy, allowing the role to be assumed only when a certain value is present in the external ID.
For example, you want to use an offering from a member of the AWS Partner Network (APN) that monitors your AWS account and provides advice to optimize costs. In order to track your daily spending, the APN Partner will need access to your AWS resources. Though you could provide that Partner with the credentials of an IAM user, AWS highly recommend you use a role.
So instead, the Partner requests a role ARN (Amazon Resource Name) from each customer.
But if another AWS customer were able to guess or obtain your role ARN, that customer could then use your role ARN to gain access to your AWS resources by way of the Partner.
Confused Deputy Scenario
AWS1 is your AWS account.
AWS1:ExampleRole is a role in your account. This role’s trust policy trusts the Partner (Example Corp) by specifying Example Corp’s AWS account as the one that can assume the role.
When you start using Example Corp’s service, you provide the ARN of AWS1:ExampleRole to Example Corp (step 1 in the following diagram).
Example Corp uses that role ARN to obtain temporary security credentials to access resources in your AWS account (2).
In this way, you are trusting Example Corp as a “deputy” that can act on your behalf. Another AWS customer also starts using Example Corp’s service, and this other customer also provides the ARN of AWS1:ExampleRole for Example Corp to use (3). (We assume here that the other customer learned or guessed the ARN of AWS1:ExampleRole, which isn’t a secret.)
When the other customer asks Example Corp to access AWS resources in “its” account, Example Corp will use AWS1:ExampleRole to access resources in your account (4).
This is how the other customer could gain unauthorized access to your resources. Because this other customer was able to trick Example Corp into unwittingly acting on your resources, Example Corp is now a “confused deputy.”
Prevent this with External IDs
You address the confused deputy problem by including the external ID condition in the role’s trust policy.
The external ID corresponds to a unique customer identifier that is generated by Example Corp.
The external ID value must be unique among Example Corp’s customers, and this is why you get it from Example Corp (you don’t come up with the external ID value on your own).
In our scenario, Example Corp’s unique identifier for you is “12345”, and its identifier for the other customer is “67890”. (Generally, these identifiers are universally unique strings (GUIDs.))
Example Corp gives the external ID value of “12345” to you, and you then add to the role’s trust policy a Condition element that requires the external ID to be 12345, like this:
The Condition element in this policy allows Example Corp to assume the role only when the AssumeRole API call includes the external ID value of “12345”. Example Corp makes sure that whenever it assume a role on behalf of a customer, it always includes that customer’s external ID value in the AssumeRole call, as a means of asserting the circumstances in which it is acting.
Last updated
Was this helpful?
