-
Notifications
You must be signed in to change notification settings - Fork 505
feat: Allow audience to be explicitly specified #362
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
Conversation
This is an update of #285 after the refactoring to use the core module for token acquisition. Tested from forked branch by manipulation of dist/index.js (not done for this commit; presumably there's a build process to do it?) /cc @richardhboyd |
Is there anything else needed for this patch to be accepted? |
What else needs to be done for this patch to be accepted? |
Is there any way to merge this please? There hasn't been any other feedback and we are currently maintaining a long lived fork of this project in the interim. There has been no issues found using this feature and it adds zero change out of the box since the default remains the same as before. However we are using the different audience to ensure that dev cannot accidentally deploy to prod (and vice versa) by using different audiences between the two. |
The default audience for the GitHub OIDC uses sts.amazonaws.com, but there are situations when it would be desirable to allow different audience names to be used instead. Allow this to be specified as an argument to the action.
Sorry, I realised that I marked the conversations as complete but then completely failed to push that change to the right branch, so it never made it to the PR for merging :-( @bryantbiggs could I ask you to review please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks correct to me - lets see if the maintainers will merge 👍🏽
Thanks @bryantbiggs -- sorry I left this unfixed so long as I thought I'd pushed to this with your recommendations in place back in Jan |
Any one able to review/merge this simple request? |
Is any maintainer in this repo able to review and merge this change? Alternatively if there are any things that need to be completed prior to this please let me know. |
Is there anyone who can review/merge this request please? |
@clareliguori - Please review :) We have a need for this feature |
@aragbhingre could you approve and merge this please? It's adding a simple field to the defaults and provides real value for those that need to specify a different audience |
@paragbhingre - any chance this can get reviewed and merged? We have customer use cases that would benefit and it looks like a few other people would too! Or @richardhboyd? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the long delay here @alblue,
This PR looks great! I think the Readme here could be improved a bit more to bring more visibility to this feature. Could you provide a short example in Assuming a Role -> Examples
that shows when a user would want to use this feature (such as in the PR the other customer made for CN regions) and add a small blurb? Since the default value is already sts.amazon.com
I don't think we need to add this to our existing examples
Ok great, I'll work on this and submit a new PR. Would you prefer me to rebase this on latest, or add a second commit to this with the updated readme information? |
Just push a second commit to the branch that this PR is based off @alblue! |
great feature! this is very useful, ! hope it will be merged soon.. |
Hi - any chance we can get the change resolved and merge this? Are there any further changes to be made? |
@peterwoodworth - Is this ready for merge? Thank you |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you all so much for your patience here! I am hoping to have the next release out next week
index.js
Outdated
@@ -19,6 +19,7 @@ async function assumeRole(params) { | |||
const isDefined = i => !!i; | |||
|
|||
const { | |||
audience, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is causing our testing to fail since it's not being used - the webIdentityToken should have already covered the audience, right? Do you remember why you added this line here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Peter,
I'm sorry to let you know that @alblue passed away last week (https://www.infoq.com/news/2022/07/alex-blewitt/).
I've been working with him on this (we work on the same company). If you let me know which would be the best way to take over his fork in this issue I can make any required changes on my side.
If you would prefer to take it over on your side that would be OK too, as you probably know your code better than anyone.
Best regards,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @enriquesantosblanco-sanuk - I worked with @alblue. It was devastating news.
Although I cannot help with the specific code, I am happy to assist in ensuing this gets completed if needs be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is devastating news... I'm so sorry, my condolences 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you on behalf of his entire Cloud Platform Evolution team. Knowing that his genius lives on through code is comforting to all that knew him. All the best to you and yours!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @alblue, this submission and your patience is very much appreciated
Allow the audience to be configured instead of defaulting to 'sts.amazonaws.com'.
It's desirable to be able to use different audiences to ensure that changes aren't enabled on the wrong location -- for example, you can use an audience of 'prod' in the production accounts and 'dev' in the development accounts.
By adding audience as an argument to the job, you can set a specific parameter in the with block, and the example has been updated to reflect this.
By the way, it's possible to configure both the role and the OICD provider with an 'either' clause, so you can use one of several audiences -- but that somewhat defeats the point of using a non-default value :)
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:alblue/*",
"token.actions.githubusercontent.com:aud": ["sts.amazonaws.com","alblue"]
}
Furthermore this approach allows you to use the audience to allow for different sets roles to be enabled; you could have a dev audience that is only trusted by the GitHubDev role, and a prod audience that is only trusted by the GitHubProd role. The OICD audience could have both, but you'd then guarantee that the dev audience couldn't assume the GitHubProd role (and vice versa).
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
fixes: #458, #457