Support AWS EC2 Auth Bound By Instance ID and Security Group

[rorybrowne]

Feature Request:

Hello; I'd like to request that the AWS auth backend support binding to EC2 Instance IDs, and Security Groups.

This would be similar to the various parameters listed in https://www.vaultproject.io/api/auth/aws/index.html which permit binding by AMI, A/c id, region, vpc, subnet, etc, except that they'd take (preferably a list of) instance ids and security group ids.

For example I only want specific instances to be able to get the TLS cert for payments.mysite.com, where as I'm happy for anything with the media SG to be able to retrieve the media.mysite.com Cert.

Environment:
Vault v0.9.0 ('bdac1854478538052ba5b7ec9a9ec688d35a3335')

[joelthompson]

Hey @jefferai -- was thinking that there are probably two parts to this. The first would probably be to convert each of the bound_* parameters to be a comma-separated list (and would also be functionally equivalent to other feature requests such as #3330). The second would be to add support for binding by instance IDs or SGs. Thoughts on this? Looking at the bound_* parameters, none of them could already have a semantically valid comma in them. The only downside I can think of would be that adding or removing an item from any list would require clients to read out the current list, make the addition or removal, and then writing the new list back, rather than just specifying an add or remove operation. Thoughts on this?

[rorybrowne]

Thanks @jefferai for adding this to the next-release; I appreciate that. Looking at the pattern of releases, would it be reasonable to expect this functionality in the next month or so?

If I was to break this down, the only part we'd truly 'need' is the ability to set a bound_instance_id parameter; everything else we can hack around using multiple roles.

[joelthompson]

I opened #3816 to only bind by EC2 instance ID and not security group, but it does allow a list of instance IDs. I'd want to think a bit more about security groups since those can change on running instances (IAM instance profiles can as well now, but that used to not be the case) and Vault doesn't currently re-validate the bindings upon token renewal, so I'd be more worried about creating unexpected behavior granting access longer than expected if Vault allowed binding by security group. @rorybrowne -- you stated that you only truly needed binding by instance IDs, so I'm guessing this would be good for you?

[DaniGuardiola]

@joelthompson binding by security group would be very useful for my company's use-case, I can help brainstorm the idea.

• You say Vault doesn't currently re-validate the bindings upon token renewal. Can this be changed? Is it too complex?

• In the unlikely case that a security group is changed on the fly, Vault's behavior should probably (in my understanding) be to revoke the original security-group-binded role token. Would it be too crazy to periodically pull instance data for each instance that has an security-group-generated active token?

For example every minute or every 30 seconds. That would be good enough for me. I don't think I'll ever change the security group on the fly with the purpose of revoking vault permissions, so as long as I'm confident that access is revoked in a short time, it would fit just fine.

Having to create an IAM role and bind it to each instance on top of adding the corresponding security group is a bit of a hassle, and it also adds complexity (extra steps) for an orchestrator setup moving forward -in my case. So this idea would be awesome.

[rorybrowne]

Apologies; I started writing a response to this and didn't get finished.... For us security groups are a nice-to-have. We can template the instances that are in a particular security-group into the list of instances.

Thank you Joel; this is a significant unblocker for us.

[joelthompson]

Hey @DaniGuardiola, I added binding by instance IDs but not security groups. Can you open another issue to discuss the desire to bind by security groups? That way we can continue discussions there about the best way forward for you.