Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Role ARN to AWS IAM Authentication Entity Alias Names. #22461

Open
thegatsbylofiexperience opened this issue Aug 19, 2023 · 2 comments
Open

Comments

@thegatsbylofiexperience
Copy link
Contributor

thegatsbylofiexperience commented Aug 19, 2023

Is your feature request related to a problem? Please describe.
Hi,

Currently the AWS IAM Auth plugin has 3 possible Entity Alias Names.
None are used anywhere else in configuration for authentication.

The bound_principal_arns uses the Role ARN not the assumed role ARN.

  1. A random UUID (role_id -- default).
  2. The AWS Role Unique Id (unique_id).
  3. The Assumed Role ARN (full_arn).
  • 1 is not predictable at all.
  • 2 is, but it would be better as the Role ARN which is what it is linked too. It is a pain to get and one already needs the role ARN.
  • 3 is not predictable with some workloads (i.e. EC2 and Code Build). The session name can be randomised and thus not of use if you need predictability.

Giving users the ability to specify the role arn as the entity alias name is much more useful.

Describe the solution you'd like
Adding the role arn as a entity alias name would be what I would like.
It is an extra option for config that is trivial to implement.

I already implemented it here -> #22460 .

So if you could please review that PR I would be grateful.

This is a quality of life change that I think will help people and not harm.

Describe alternatives you've considered
Not considered any other options. this is a good functional change that makes user quality of life easier.

Explain any additional use-cases
None.

Additional context
None.

Thanks for your time.

@austingebauer
Copy link
Contributor

Hi @thegatsbylofiexperience. I'm taking a look at this and have a few questions to start.

  • Can you confirm that you are assuming a role and then authenticating with Vault as that principal?
  • Can elaborate more on what predicability will specifically solve for you in this case? Is it related to configuring entity aliases?
  • Do you know if there is a way to get predictable role session names for EC2 or code build?
  • Are you setting resolve_aws_unique_ids to true or false?

The bound_principal_arns uses the Role ARN not the assumed role ARN.

That's true but it's not the default mode. There is good reason for this being true by default as explained in resolve_aws_unique_ids for the delete-and-recreate with same name scenario.

@thegatsbylofiexperience
Copy link
Contributor Author

Hi @austingebauer ,

Thanks for taking a look at this.

  • Yes.
  • Yes, Hashicorp is already aware of the use case and why I need it. Please speak with Yulei Liu.
  • AFAIK we are the mercy of AWS to designate the ec2 id and Code Build is a UUID, if I could predict a random u128... well, I wouldn't need to work would I?
  • Resolution of role unique ids doesn't really help here. It speeds up lookup of authenticated ARNs in some scenarios.

That's true but it's not the default mode. There is good reason for this being true by default as explained in resolve_aws_unique_ids for the delete-and-recreate with same name scenario.

Frankly. The implementation here is complex and does not allow for differences in a setup. This is all dependent on how you AWS workspace is configured -- i.e. what controls around role creation do you have in place.

That being said the implementation leaves a lot to be desired. Vault can only do the lookup/caching of Role Unique Ids AND only under certain circumstances do you allow for the lookup to be added to the cache.

I understand why the default is the way it is. But IF you were to allow whitelisting of role unique ids too, it would help companies who are not the original authors of this code (Blackrock from memory).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants