-
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
Use role-to-assume without OIDC in destination account #279
Comments
big +1, this can come in handy |
This can be easily achieved using a compound action. |
Yes, thank you for this. It is a viable option, but the point of the ODIC action is to eliminate the use of IAM Tokens and therefore a security requirement to rotate and secure them. |
@rosswickman The compound action would also only use temporary tokens. |
@foxylion Ah. I missed that. I see what is happening.
Are the sts temp session creds provided by the ODIC role and not static secrets. |
I'm not sure I understand the explicit request on another look at this. Our action uses the credentials you have available to make the call that you want to be making. Please upgrade to the latest version |
Comments on closed issues are hard for our team to see. |
I'd like to add a feature request for the addition of a
with.arg
for something likerole-to-leverage
where this role is the role in a single (orchestration) account where the OIDC is deployed that has the principal and condition to use the IDP.Prior to the implementation of OIDC, an IAM user in the orchestration account could directly assume a role in a different account.
Now in order to implement the OIDC, the IDP needs to be present in every account.
It would beneficial to use the
role-to-assume
as a role in a destination account that can be assumed by therole-to-leverage
which is in the orchestration account.This implementation allows the single modification/termination of a role that has access to 100s of accounts instead of having an individual role/idp pair in 100s of accounts that continue to work in GitHub actions until modified.
This would be the
role-to-leverage
permissions as is my current IAM userAnd this is the Action Workflow that currently leverages it
Thanks
The text was updated successfully, but these errors were encountered: