IAM Instance profile in path

[martinssipenko]

When using the new IAM auth_type with AWS IAM Instance Profile, which is attached to an IAM role that is in path /some/, the ARN of the role is arn:aws:iam::123456789012:role/some/MyRoleName, but when using this role for bound_iam_principal_arn argument, error is getting returned. (IAM Principal "arn:aws:sts::123456789012:assumed-role/MyRoleName/i-1234567" does not belong to the role "xxx")

I did try dropping the path part from ARN and it worked, however, this is not the ARN of the role anymore.

is this a bug or an expected behaviour? If this is expected, I'm happy to send a pull request that would explain this in documentation.

[jefferai]

@joelthompson Any thoughts here?

[joelthompson]

This is because GetCallerIdentity doesn't return the role path (which is very annoying). I think the right way of solving this is the thing we were already discussing offline -- looking up the internal entity ID and then matching against that (as it does get returned by GetCallerIdentity).

I've got most of that PR ready, I should have something in the next couple days.

[nocode99]

I think I'm experiencing a similar behavior with ECS. I attach an IAM task role to an ECS task and tried authenticating to vault coming up with a similar error. I tried with both host networking enabled and disabled and got the same message.

* IAM Principal "arn:aws:sts::1111111111:assumed-role/ecs-cluster/i-13b5f2486f10d5c48" does not belong to the role "my-app"

[pwae]

i'm seeing similar behaviour here when using the ec2 auth type and matching against the bound_iam_role_arn as well.

I have a role (and instance profile) which have paths in them. when vault calls GetInstanceProfile, it's ending "path/name" as the query, which throws the below error in the AWS API.

{"errors":["IAM role ARN could not be fetched: ValidationError: 1 validation error detected: Value 'some/name' at 'instanceProfileName' failed to satisfy constraint: Member must satisfy regular expression pattern: [\\w+=,.@-]+\n\tstatus code: 400, request id: xxx-xxx-xxx-xx"]}

The issue for this seems to be related to the fact that the below like of code, just splits after :instance_profile/ and not necessarily just the last component of the string (i.e. last after /)

https://github.com/hashicorp/vault/blob/master/builtin/credential/aws/path_login.go#L475

[jefferai]

I believe #2802 should fix this. Please comment if not.

[joelthompson]

No, #2802 won't fix this. I have a PR about ready (just need to put it through our internal OSS review process) that will fix this.

[jefferai]

@joelthompson Any idea on an ETA for that? Would be good to get it into 0.7.3 if possible.

[joelthompson]

Hi @jefferai -- I just opened #2814 which should address this issue.

[joelthompson]

I think this should be closed now with the 0.7.3 release, it just didn't get auto-closed.

@martinssipenko -- can you confirm the newest release works for you?

[martinssipenko]

Just tested this with Vault v0.7.3 ('0b20ae0b9b7a748d607082b1add3663a28e31b68'), and the issue still exists.

vault auth -method=aws header_value=vault.rocks
Error making API request.

URL: PUT https://vault.rocks:8200/v1/auth/aws/login
Code: 400. Errors:

* IAM Principal "arn:aws:sts::123456789012:assumed-role/MyRoleName/i-1234567" does not belong to the role "xxx"

Removing the path from ARN, when setting bound_iam_principal_arn works as workaround.

[martinssipenko]

Actually, I read the documentation again and it now states that you MUST leave out the path component in bound_iam_principal_arn for roles only, but not IAM users. That is, if your IAM role ARN is of the form arn:aws:iam::123456789012:role/some/path/to/MyRoleName, you must specify a bound_iam_principal_arn of arn:aws:iam::123456789012:role/MyRoleName for authentication to work.

So I guess the issue could be closed, but perhaps there is a better way of doing this? Maybe it would be possible to fix this by dropping the path from ARN?

@joelthompson @jefferai what do you think?

[joelthompson]

@martinssipenko -- are you using the same role you created with 0.7.1 or 0.7.2? If so, update your role to set resolve_aws_unique_ids to true and try again. (This defaults to true on new roles in 0.7.3, but will be false on roles created in 0.7.1 or 0.7.2.)

[martinssipenko]

I deleted and created the role, added the iam:GetRole to my Vault instance and it works now.

[ahaynssen]

@joelthompson I'm still hitting this on vault 1.7.1 and can not figure out what i'm doing wrong...

I'm trying to go cross-account and have added
vault write auth/aws/config/sts/11112222333444 sts_role=arn:aws:iam::11112222333444:role/<role with assume priv>

vault role:
vault write auth/aws/role/jumpbox auth_type=iam policies=admin ttl=1h bound_iam_principal_arn="arn:aws:iam::11112222333444:role/jumpbox"

From the EC2 I'm always getting:
* IAM Principal "arn:aws:sts::11112222333444:assumed-role/jumpbox/<instance-id>" does not belong to the role "jumpbox"

I've followed a few different examples without success. I could move these to ec2 auth but I'd like to use iam for lamdba, etc.

[ghost]

Hello, @joelthompson. Just like the above commenter I am also still hitting this issue despite changing resolve_aws_unique_ids to true. I have also recreated new roles and get the same error: * IAM Principal "arn:aws:sts::218805389557:assumed-role/vault-aws-authentication/i-077c2770f56481940" does not belong to the role "dev-role"

If it help - I am following the steps outlined here: https://github.com/hashicorp/vault-guides/blob/master/identity/aws-second-sample/AWS-auth-method-testing.md

[blidec]

Hello, @joelthompson. Just like the above commenter I am also still hitting this issue despite changing resolve_aws_unique_ids to true. I have also recreated new roles and get the same error: * IAM Principal "arn:aws:sts::218805389557:assumed-role/vault-aws-authentication/i-077c2770f56481940" does not belong to the role "dev-role"

If it help - I am following the steps outlined here: https://github.com/hashicorp/vault-guides/blob/master/identity/aws-second-sample/AWS-auth-method-testing.md

One of the less common scenarios - if you've added your iam role to Vault, but then recreated your iam role from AWS side, you'll need delete and re-add it back to Vault. It took me quite sometime to realize it's using RoleID in the authentication. In my case the iam role and Vault are in two different AWS account. Not sure if this also applies if they are in the same account.

To see the actual RoleID registered in Vault (bound_iam_principal_id): vault read -namespace= auth/aws/role/<vault_role>