be able to fetch Installation Token using a BYO JWT

[revdarragh]

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

• 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.

[gr2m]

just so that I understand, you would like an alternative API that accepts a JWT instead of the app Client ID and private key?

That's an interesting idea. But note that JWTs are very short lived, only 10 minutes I think.

[revdarragh]

Yes I want to provide a JWT. (The app ID is referenced inside the claim data, while the Private Key is stored within a security-hardened secrets store such as Hashicorp Vault)

In my view, the short-lived expiration isn't a concern, because all of this is happening within one GH Actions flow.

1. In one Step, I would be creating the claim and signing the token (using my securely-stored Private Key). No authentication / calls sent to the GitHub server yet.
2. In a next step, I would do all the GitHub server authentication.

• submit the JWT to get an Access Token
• submit the Access Token to get the Installation Token

Why is this compelling

• For 1, the secret store provider or community members themselves would write the Action logic.
• For 2, ideally the community would be able to use this GitHub-specific project here for the Action logic, and not have to reinvent the wheel.

[gr2m]

• submit the JWT to get an Access Token

• submit the Access Token to get the Installation Token

It's just one step, the JWT is used to retrieve the installation access token.

Since this will be just a single request, maybe you can use a simple action like this?
https://github.com/octokit/request-action#readme

I do like your use case and agree with the additional security, I just don't want to commit to adding the feature outright, I'll review it with @parkerbxyz on Thursday.

If you like, please feel free to get a pull request started, it would make a great base of discussion for us to see what the additional complexity to support a direct JWT input would entail