-
Notifications
You must be signed in to change notification settings - Fork 464
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
Assuming two roles in the same region in the same account fails #236
Comments
Hi @dbogen , thanks for reporting this! So I think I may know what's going on - this action does reset the session token to account for multiple runs, but the check only triggers when you're providing an AWS_ACCESS_KEY and AWS_SECRET_KEY, vs. relying on an instance role. I'm still undecided whether this action should always reset these before running - it may sometimes be desired to assume a role with temp creds - but in the meantime, can you try explicitly resetting these vars and then checking the caller identity in your workflow to see if that will get you back to a state which is using the instance role? I.e, add these 2 steps after your Copy from source S3 bucket step:
|
Thanks for the response, @allisaurus . Resetting those credentials in a separate step is the workaround I ended up using so, yes, that works. However, it would be great to have a flag (something like, |
Similar problem here. In our case, we use the role associated with the EC2 instance is the only one permitted to assume the other roles that we need. But, after assuming the first role, there doesn't seem to be any way to drop the credentials and go back to the the role associated with the EC2 instance. |
This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
I think providing a flag to clear out these environment variables is probably a reasonable compromise to both allow the intent of the described behavior while preserving the role chaining which currently happens. |
A combination of |
** Note ** |
If I use this action to assume a role in a given region in a given account, perform some actions, and then try to assume a different role in the same region and the same account, it looks like the action defaults to using the first role to assume the second role.
In this case, I'm trying to use the first role (source role) to copy from a source S3 bucket to a local store, assuming the second role (target role), and using that second role to copy to a target S3 bucket.
My action looks generally like this:
When running that action, the source role assumption succeeds and I'm able to copy files from the source S3 bucket.
The target role assumption fails with the following error:
That error is true; the source role is not authorized to assume the target role.
My assumption was that the action would use the self-hosted runner's instance profile and associated role to assume the second role (which is how it assumed the first role), rather than using the first role to assume the second role.
Is there a workaround to assume a second role in the same region and account where a first role was assumed? Should I instead be passing some sort of flag to tell the action unset all the environment variables it previously set before it tries to assume a new role?
The text was updated successfully, but these errors were encountered: