Vault AWS Auth - IAM Roles

[james....@hootsuite.com]

Hi,

I would like to assign Vault roles to my AWS auth based on either my UserId or the RoleSessionName and I'm not sure how (or if) it's possible. 

For example, I've auth'd against AWS:

$ aws sts get-caller-identity --profile example

{

    "Account": "1234567890",

    "UserId": "AROAINNNNNNNN:james....@example.org",

    "Arn": "arn:aws:sts::1234567890:assumed-role/ExampleRole/james....@example.org"

}

I have the following auth/aws role:

$ vault read auth/aws/role/ExampleRole

Key                               Value

---                               -----

auth_type                         iam

bound_iam_principal_arn           arn:aws:iam::1234567890:role/ExampleRole

bound_iam_principal_id            AROAINNNNNNNN

bound_iam_role_arn                n/a

inferred_entity_type              n/a

period                            0

policies                          [example_policy]

resolve_aws_unique_ids            true

role_tag                          n/a

....

And when I auth, I get the following:

$ export AWS_PROFILE=example

$ vault login -method=aws

Key                                Value

---                                -----

token                              a...

token_accessor                     b...

token_policies                     [default example_policy]

token_meta_client_user_id          AROANNNNNNNNNNNNNNNNN

token_meta_inferred_aws_region     n/a

token_meta_inferred_entity_id      n/a

token_meta_inferred_entity_type    n/a

token_meta_account_id              1234567890

token_meta_auth_type               iam

token_meta_canonical_arn           arn:aws:iam::1234567890:role/ExampleRole

token_meta_client_arn              arn:aws:sts::1234567890:assumed-role/ExampleRole/james....@example.org

The backend that permits me to assume ExampleRole enforces that the SessionName is always my email address. 

Ideally I would want to do something akin to:

$ vault write auth/aws/role/example-james.atwill auth_type=iam \

   'bound_iam_principal_arn=arn:aws:sts::1234567890:assumed-role/ExampleRole/james....@example.org' \

   policies=user-policy-james.atwill 

   max_ttl=25h ttl=23h

Is something like this possible / would it be hard to implement? 

   JAmes

[Joel Thompson]

Hi James,

No, sorry, something like that is not currently possible.

I don't think it would be too difficult, and there is actually one special case in which the RoleSessionName is used to make authorization decisions -- when using ec2_instance inferencing.

Where this would get tricky is not on the implementation side but on the end-user management side -- the policies aren't templated, so you'd need one Vault role per individual, and that adds a lot more management overhead to keep the Vault roles and policies up to date with individuals in your org.

What I think the more interesting story here would be (and the more natural one) would be to tie this into Vault's Identity store (https://www.vaultproject.io/docs/secrets/identity/index.html) and give policies to you based on your identity. That's still not possible right now because it's still only keying off of the role unique ID rather than the full session name, and it might take a little work to figure out how to solve this particular use case.

Maybe this is a silly question, but how are you authenticating to get your AssumedRole credentials (that is enforcing your RoleSessionName is your email address)?  Could you just provide those credentials to Vault via a different backend to get specific policies? This also seems like a more natural way to get your Vault token.

--Joel

id: 7898659753248090

--
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/78c1410d-f4c7-49ea-8a41-94932f3aeaf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[james....@hootsuite.com]

Hi Joel,

Thanks for your quick response! I'll dig more into the identity backend; I was hoping there would be a mechanism similar to ec2 inferencing,

We're looking at saml2aws ( https://github.com/Versent/saml2aws ) which takes care of MFA and assume role. I was thinking it would be nice to leverage the existing IAM credentials to authenticate into Vault too. The role/policy <-> identity mapping is solvable with a bit of automation on our side.

  JAmes

[Joel Thompson]

Hi James,

One note I want to add about Identity is that, while I'm not too familiar with it, I don't think you could accomplish what you want even with Identity, as I believe the backend only exposes the unique principal ID to the Identity backend, and it drops the RoleSessionName entirely. My point was more that I think that's the right way of accomplishing your use case, so somebody were going to update the auth backend to meet your use case, I think that would be the right way to do so.

If your SAML IdP is just authenticating to a backend directory that speaks LDAP (e.g., AD) or RADIUS, you might be able to just use those as an authentication backend and I imagine they probably have better integration with Vault's identity than the AWS authentication backend does. If you need AWS creds, you might then be able to use Vault's AWS secret backend.

Anyway, not saying this is what you should do, just that it might work for you. As it sounds like you're still exploring, if you decide this is something you'd want, file a feature request in the GitHub issue tracker (or submit a PR!).

--Joel

id: 7898659753248090

--
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/2d591bc6-dd58-4a6f-bcf1-89e54d5d53c8%40googlegroups.com.

[james....@hootsuite.com]

Hi Joel,

I understand. I'll need a different route for now, but when/if this feature is added, I'm most futureproof if I hook policies to Vault identities and map my alternative auth backend to those entities. I can then add IAM inferencing more easily when/if it becomes a thing.

Thanks again for everything!

  JAmes