steps for aws iam auth cross account access ?

[ernest...@twosigmaiq.com]

I have a lambda running in account A and wants to authenticate to Vault severs deployed in account B.

My lambdas in account B can auth with Vault with no problems. Lambdas in account A get this error:

{"errors":["error looking up full ARN of entity \u0026{aws <AccountA> assumed-role LambdaRole.default_role mylambda}: error creating IAM client: unable to fetch client for account ID <AccountA> -- default client is for account <AccountB>"]}

I assume the problem is that I haven't setup cross account authentication for my vault servers in account B to access and auth lambdas from account A. I am using aws iam authentication, NOT ec2.

 Questions:

1. Does these instructions (https://www.vaultproject.io/docs/auth/aws.html#cross-account-access) also applies to iam authentication?

2. The parameters accepted in "auth/aws-ec2/config/sts/<account_id>" are the same as those accepted in /auth/aws/config/client ? 

   Where do I name the aws role vault should assume in this config?

thanks,

Ernesto

[Joel Thompson]

Hi Ernesto,

You are correct, not having set up the sts config would cause this issue. (Note that you could just set resolve_aws_unique_ids to false when setting up the role, and I think that would bypass the need to do this, but I would not recommend it -- see the documentation of this parameter at https://www.vaultproject.io/api/auth/aws/index.html#resolve_aws_unique_ids).

On your questions:

1. Yes, those instructions also apply to iam authentication when doing cross-account authentication and not disabling resolve_aws_unique_ids

2. The parameters are documented at https://www.vaultproject.io/api/auth/aws/index.html#create-sts-role and are different parameters. The name of the role you would assume is up to you; however, you need to ensure that the role has sufficient permissions. There's a recommended policy documented at https://www.vaultproject.io/docs/auth/aws.html#recommended-vault-iam-policy  -- the role in account B won't need sts:AssumeRole (it will need to trust the role Vault is using in account A), but the role Vault is using in account A WILL need that sts:AssumeRole permission.

Hope this helps!

--Joel

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/653433c1-27c2-49a3-88de-6f40b3fa5faf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ernesto Cejas]

Yes, it definitely helped. 

Thanks!

You received this message because you are subscribed to a topic in the Google Groups "Vault" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vault-tool/-swIXz73Ht8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAOXnK5SHPVBGxubHXJapENFJtnRh9FH6aBOvsAN4SDPFmQB4qA%40mail.gmail.com.