Vault: auth/aws: Support binding to IAM Groups

[joelthompson]

Separating out from #3179

There's a use case that came up on the mailing list that would be solved by supporting binding to IAM groups in the AWS auth backend.

Here's my current thinking and open questions about what the "right" behavior would be:

When binding a role to an IAM group:

• Enforce AWS unique ID resolution to make the rest of the code simpler (it really only exists for backwards compatibility with the existing types due to some shortsightedness on my part)
• Call iam:GetGroup to look up the unique ID of the group and store the group unique ID

When logging in:

• Go through normal process of authenticating the user
• When authorizing, if we detect that the bound IAM principal is a group, then:
  
  
  
  • Ensure the authenticated principal is a user (since groups can only contain users)
  
  
  • Call iam:ListGroupsForUser (and paginate through the results) to see if the authenticated user is a member of the bound group
  
  
  • Matching should be done based on the unique ID of the group -- iam:ListGroupsForUser contains the group ID for each group the user is a member of
  
  
• Wildcard matching -- how to handle (once #3213 is merged)?
  
  
  
  • One option is to simply disallow wildcards matching groups (easier)
  
  
  • The other option would be, if the authenticating user's ARN doesn't match the wild card, then to enumerate each group that user is a member of and see if it matches the wild card
  
  
  • This naive approach would be terribly inefficient, e.g., if I have a bound ARN of arn:aws:iam:::123456789012:* and the authenticating user is arn:aws:iam::987654321098:user/Joe then there could never be a match to a group (since AWS doesn't allow cross-account group membership)
  
  
  • Maybe a more efficient option would be to look up group membership iff the bound IAM principal ARN starts with arn:aws:iam::<authenticated principal's account ID>:group and contains a wildcard at the end? Would need to spend more time thinking this through.
  
  

When renewing tokens:

• Don't check to ensure that the authenticated user is still a member of the bound group (similar to the declared behavior of the LDAP auth backend)
• What's the right behavior when the bound IAM principal has changed?
  
  
  
  • One option is to simply refuse to renew
  
  
  • Another option would be to see if the authenticated user still matches the bound IAM principal. This could involve looking up group memberships anew (which we wouldn't be doing under normal circumstances)
  
  

The biggest thing stopping me from implementing this today is testability because this now introduces even more interactions with AWS APIs, and in more complicated places. I just don't think this (IAM group support) can be done in a maintainable way without having some real mocking of AWS APIs (something I'd guess the AWS secret backend could also benefit from). I recall that the Terraform AWS provider had some basic mocking that might prove useful here; has there been any discussion about sharing that out into a more common HashiCorp library? If not, I'll probably work on this first; a couple links for future reference.

[jefferai]

There hasn't been any discussion from our end, but I do encourage you to reach out to the TF devs about it if it would be useful. (I can make introductions if that would help.)

[joelthompson]

Cool, I'd definitely love to chat with the TF folks! Maybe HashiConf?

[jefferai]

Sure, depends on what your timeline is -- if you want to get a shared framework in for 0.8.2 should probably chat ahead of then, but otherwise that would be fine.

[joelthompson]

I don't have any timelines, and thinking a little more broadly, I also wonder if there'd be interest from the Packer and/or Nomad teams as well in something like this, and/or if they also have code that could be pulled into a shared library. Feels like HashiConf would be the perfect time to have a quick chat about this. If you could make introductions, that'd be awesome!

[jefferai]

Sure! Hit me up then and I'll find people for us to talk to.

[ttacon]

Hi there! Just stumbled upon this ticket while looking into using this functionality. I was wondering if there was any progress on this or any roadmap for it? Thanks!

[paddie]

@joelthompson @jefferai This would actually make it a lot nicer from a user management perspective. We have a bunch of users that exist at the root users/ level, alongside a bunch of user-instance credentials that we don't want to allow similar access to assume roles.

Supporting Groups would allow us to not move/migrate all users over to a separate users/devs/* path to differentiate them.

[thenoid]

This would be magnificent

[ivan85viv]

That would be really nice if its implemented and would definitely help