Support AWS role chaining for AWS secret engine

[harsimranmaan]

Is your feature request related to a problem? Please describe.
First of all, Vault is awesome :).

I have been trying to configure Vault AWS secret engine with x-account IAM trust to get credential_type assumed_role. The setup works fine for 1 level of indirection but does not work for 2+ levels.

Here's the setup

Vault runs in AWS account A with IAM role - vault
vault role is allowed to assume vault-secret role in Account B
account B has a role called vault-secret. It has a trust relationship to allow A-vault to assume it. It can also assume any role in account B
account B has several IAM roles. Some of these can be assumed by vault-secret role so that Vault could issue ephemeral creds for these roles.

Describe the solution you'd like
I'd like the above setup to work. When creating the aws secret mount/role, an admin should be able to specify what role Vault should assume in order to get temporary creds for an aws role.

Describe alternatives you've considered
An alternative is to remove the indirection, ie, allow A-vault to assume any role in account B and update the corresponding roles in account B to setup trust relationship with A-vault directly instead of B-vault-secret.

This works but it is operationally very expensive to manage, if there are a few hundred accounts like B with thousands of IAM roles managed by different deployment lifecycles. Creating initial setup is not that hard, the challenge arises when doing operations to alter Vault at a future date, eg: 1 Vault might now split into 2 vaults, each having a different IAM role. This would require changing all IAM roles in B to update the trust relationship.

Having the ability to use chained roles would mean that only 1 IAM role B-vault-secret would need to trust the Vault IAM directly. Any updates to the Vault IAM would not require updating every IAM role across every account.

Explain any additional use-cases

Additional context
Configuring static IAM credentials is not desired.

I am happy to do the work if this is something that can be included in the core offering.

[dr-yd]

Since there has been no reply, I assume that the issue description is correct and this is currently not possible. Thus, an additional circumstance / use case:

• Vault is managed by a company A which administrates (aspects of) multiple other companies' organizations.
• Appropriate permissions for Vault to assume administrative roles in each management account exist.
• In each organization's leaf accounts, administrative roles with trust relations to the management account as described above exist.
• Leaf accounts are organized on a per-project and per-environment basis, where each client company has multiple projects and each projects has multiple environments.
• The managing company's infrastructure repos define the contents of these accounts, with one repo per account and one branch or similar per environment.
• Each branch's pipelines (e.g. "development" in the project "website") should be given access to the appropriate leaf account only (e.g. the website workload staging account).

As-is, Vault can only grant administrative access to the entire organization, or multiple administrative roles in the management account have to be created.

I would describe this as a fairly common use case where the current situation produces substantial management overhead.

[zerog2k]

I'd also like to see this role chaining ability.
We have vault instances which allow aws role assumption for multiple accounts - each account having their own aws secret engine path and configuration within a given vault instance.

Right now it seems that this is only 1-deep, meaning unless you use static user IAM credentials configured on each aws secret engine path, you are forced to use whatever security context (iam profile/creds) the vault instance is using to trust to the roles being assumed by all other aws secret engine configurations.

With the ability to configure an aws secret engine with a role to be assumed for that secret engine when assuming the roles under it, then you can have a much more configurable (and later separable, portable) configuration:
vault's profile/creds used to assume the role for the aws secret engine root role, which then does the role assumption for the target roles under that aws secret engine path.

It really unlocks the value of using vault in flexible ways.