AWS auth backend doesn't allow binding to the root principal when resolving unique IAM IDs is enabled

[joelthompson]

Related to discussions in #3179 and the change in #3181

When creating or updating a role with the AWS auth backend and iam auth_type, if you specify bound_iam_principal_arn=arn:aws:iam::123456789012:root without also specifying resolve_aws_unique_ids=false will cause a failure to create/update the role because the root user doesn't have a unique ID, and the unique ID resolution can't handle root users.

This should either be fixed or just explicitly disallow binding to the root account (given their use would be a pretty strong anti-pattern).

/cc @jefferai

[jefferai]

Hi Joel, sorry for the late response -- was banging away on 0.8.1 and then took a day off.

If fixing this requires a breaking change I'm fine with that -- it's a brand new thing in 0.8.1 and if it doesn't work properly breaking to fix it seems fine.

Regarding whether we should: in any decently-run organization you should never use root credentials. In Vault, you should only generate them as needed. However, I'm not sure we want to go beyond being proscriptive, and here I'm thinking of the dev case (where we go so far as to allow you to actually specify the root token ID to make it easy to dev). In particular, with things like cross-account billing, it's not totally unreasonable that each dev or dev group could have their own sandbox for use in doing things like testing out Vault.

I'm leaning towards allowing it but ideally returning a warning in the response (when configured and/or when logging in) saying, basically, "be sure you know what you're doing here". @vishalnayak @briankassouf @calvn thoughts?

Edit: I said "cross-account auth" before but meant "cross-account billing", which I think they call consolidated billing. As an example, the Vault team has its own AWS account for dev/test but billing goes to HC as a whole.

[joelthompson]

No worries, hope you enjoyed the day off :)

I was actually going to use the consolidated billing as an example of why you wouldn't use creds for the root user.

Let's separate out the literal root user from other principals that have full access to the AWS account. The root user is a special principal that has complete and unfettered access to the AWS account. You can give other principals unfettered access, and they can do everything except restrict the root account's permissions. So even if each group gets a sandbox account, you don't need to hand out the credentials to the root account. We certainly don't. You instead just hand out credentials to a principal that has full access. The root account should be escrowed by the organization that's paying for the AWS bill as a way of getting back into the account. For example, if I went rogue and started to use one of our corporate AWS accounts I have access to in order to spin up a bunch of EC2 instances and mine bitcoin, the organization should be able to get in and recover control over the account. If you hand out the credentials to the root user, it's much harder to do.

Additionally, users should be using similar mechanisms in dev as they'll be using in prod, and the root credentials for the prod account should never be used in regular operations, so they shouldn't be using root in dev.

The discussion here is about the literal root user. There's nothing preventing Vault users from using IAM Users or Roles that have a policy giving them full access to AWS. Given that there hasn't been a use case for supporting the root user thus far, I'd want to be careful about supporting it. There's a careful balance between giving users flexibility to meet their needs and giving them so much rope they end up hanging themselves, and supporting the literal root user feels to me like it crosses the line into too much rope.

[jefferai]

That's all fair. I think the root account works differently than I had thought it does (what? AWS is super complicated?) I was mostly concerned about the dev case but it sounds like it's possibly significantly more dangerous (monetarily speaking) than dev with Vault and root tokens.

Let's rip it out, remove it from the changelog, and pretend it never happened :-) Given that it didn't really work properly to begin with, I doubt it will be much missed.

[joelthompson]

Yeah, I was thinking that a more apt comparison to the root account would be to the Vault unseal keys. With them, you can generate the root tokens, and the unseal keys are the ultimate root of access in Vault.

And sounds good!