You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that credentials can be leaked from GitHub actions accidentally or intentionally by a variety of means As a security-conscious GHA workflow owner When there is a Requirement to use a high-privileged GitHub App in a workflow I need a way to put only short-lived, easy to rotate creds into the workflow context so that if the cred is leaked, the risk of exploitation is time-bound and easier to contain/respond to
Scenario
Summary: A workflow owner already has a way to get the JWT, but wants to use this Action to get the installation token.
How is the JWT obtained? A GH App's Private Key has been stored in a Secrets Store, such that it can be used for signing claims but cannot be downloaded.
What would we want this Action/create-github-app-token to change? Allow the workflow consumer to provide their own JWT, and not have to rewrite the logic for getting an Installation Token.
What's the security benefit? The Private Key never leaves the Secret Store. It's never directly exposed in any way to leakage.
Priority Level
Nice-to-have.
There are a few nuances, but overall, it's not super hard to get the installation token.
Would just be nice to have the abstraction and not reinvent the wheel. Instead of countless organizations writing their own internal Action for local use, or using scripts in Actions contexts.
The text was updated successfully, but these errors were encountered:
Story
Given that credentials can be leaked from GitHub actions accidentally or intentionally by a variety of means
As a security-conscious GHA workflow owner
When there is a Requirement to use a high-privileged GitHub App in a workflow
I need a way to put only short-lived, easy to rotate creds into the workflow context
so that if the cred is leaked, the risk of exploitation is time-bound and easier to contain/respond to
Scenario
Priority Level
The text was updated successfully, but these errors were encountered: