AWS backend stsAssume with "External ID"

[nauckunas]

Feature Request: Security improvement for AWS backend "External ID" parameter for stsAssume operation. More about "External ID" https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html

Expected Behavior: Possibility to assume role with "External ID" parameter.

[joelthompson]

Hi @nauckunas -- can you give a little more detail about the use case you have an mind? The external ID is generally only useful to solve the confused deputy problem; it doesn't really provide much more value beyond that.

From the AWS docs:

Example Corp must provide the ExternalId value to each customer. What is key is that it must be generated by Example Corp and not their customers.

Is your use case that the Vault server itself is multi-tenant/federated and the attackers you're trying to protect from would be Vault operators? In this case, Vault would need to generate the ExternalId since Vault is functioning as "Example Corp".

Or is your use case that a single instance of Vault is supporting a multi-tenant application (e.g., Vault is used by "Example Corp" to get AWS credentials), in which case Vault itself or some external application could generate the external ID?

I feel like just having Vault itself generate the external ID a role is created would be the most secure and solves both use cases, but it would require you to create the role in Vault first, read the external ID out of the role, and then give it back to the client to update the trust policy on the role with the external ID, so it could be more work on the client end to fully integrate it.

[nauckunas]

Hi @joelthompson, It make sense to use External ID if you are involved in multiple accounts that you are not the owner of. So in-case AWS account A provides "roleA" that can be assume on his account. And then AWS account B provides arn of AWS account A. In that case you think you are assuming role of AWS B account but instead it would be AWS A. Additionally some AWS account owners might have requirement to have "External ID" set for cross-account roles.

[flyinbutrs]

@joelthompson - another +1 on this from me. My thought process is as follows:

• I'm using vault in an isolated account to regulate all cross account access within my company.
• That account is as locked down as possible, but theoretically, if someone were to get onto one of my vault systems, they could use STS via the IAM role attached to the vault instance.
• If the external IDs were stored in vault itself, once entered, the vault would be the only place in that account able to make STS calls to other accounts.

[kbroughton]

I don't think this statement is true: "If the external IDs were stored in vault itself, once entered, the vault would be the only place in that account able to make STS calls to other accounts."

As per AWS docs at https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html "ExternalID is not treated as a secret". If successful, the externalID shows up in CloudTrail logs of both accounts and is not obfuscated like a secret. (If unsuccessful, the request only appears in the issuer of the request's account).

That said, it is still a security improvement to support externalID. But if you want the benefit you described you might be better off with a user credential which obeys all the expected rules of a true secret.

[danil-smirnov]

This issue effectively blocks us from using Vault as we have AWS roles restricted by External Id. Please provide a way to pass External Id when assuming a role with aws engine.

[yesteph]

+1

First, Vault is a great tool!

We use an on-premise vault cluster to manage credentials for a set of multiple clouds (local OpenStack, AWS, GCP, Azure) tenants managed by customers. We need to provision resources in the customer tenants with Terraform providers configured by /aws/roles from Vault. The roles assumed by vault will be created by the customer and we want to use the external_id check as recommended by AWS.

By the way, Terraform manage the external_id for its provider but not Vault ....(sad).

Thanks you!

[sms-astanley]

Just wanted to add on in hopes that this issue gets picked up. We pay for vault enterprise licenses and are unable to utilize the AWS secrets engine because of this issue. We work with delegated access to AWS and can not use the iam_user method. We have to use STS credentials and all of our cross account roles use external_id to prevent their use from the AWS console. This is a pretty big issue for us.

[jpedrick]

I would find this helpful for dynamic policies. I would like the external_id filled in with the vault username so I could have one policy dynamically control access to pre-existing S3 resources depending on username.

[iniinikoski]

Just wanted to add on in hopes that this issue gets picked up. We pay for vault enterprise licenses and are unable to utilize the AWS secrets engine because of this issue. We work with delegated access to AWS and can not use the iam_user method. We have to use STS credentials and all of our cross account roles use external_id to prevent their use from the AWS console. This is a pretty big issue for us.

Feeling your pain. HCP Vault customer here. Also, hoping Hashicorp would address this.

[jpedrick]

I'm also wondering why they don't supply an STS::GetFederationToken interface to generate temporary credentials for managed iam users. I'm picturing being able to store/create multiple IAM user credentials, with periodic/automatic rotation, then creating a federation api with attached policies.

vault write aws/roles/<my-user-policy> iam_user=<existing vault managed iam user credentials> policy=@somepolicy.json policy_arns=<existing policies> type=user_federation_token Then:

vault read aws/sts/<my-user-policy> ttl=15m Then AWS manages the lifetime of the credentials and I would never worry about my users accidentally leaking their long lived IAM credentials, since they wouldn't ever have access to them.

[arpits7]

@joelthompson Any the update on this issue?