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

[gr2m]

Just sharing some thoughts

A good first step might be to create an @octokit authentication strategy that accepts a JWT. It should implement the installation authentication part of @octokit/auth-app as well as JWT authentication.

It should clearly document the tradeoff: increased security by not requiring the private key at the cost of the inconvenience that the JWT is only valid for 10 minutes without the ability to create a new one.

If we decide to use that strategy within this action, it should be an official authentication strategy hosted in the @octokit org on GitHub.

Another thing we could do is to extract the logic to create installation access tokens form @octokit/auth-app (source) into a new @octokit/app-methods package, and then use that in actions/create-github-app-token. I don't think we need a fully fledged strategy for the scope of this action. We already have https://github.com/octokit/oauth-methods.js and https://github.com/octokit/webhooks-methods.js, adding https://github.com/octokit/app-methods.js/ would therefore be consistent

Last thought is that we should consider re-using the private-key input for a JWT. It would be confusing, but the alternative would be to make the private-key input optional which would degrade the DX for the most common use case.

[revdarragh]

@gr2m I appreciate your continued thinking on the topic. I'd like to share one point in response:

It should clearly document the tradeoff: increased security by not requiring the private key at the cost of the inconvenience that the JWT is only valid for 10 minutes without the ability to create a new one.

I don't agree with this characterization of "without the ability to create a new one".

• True, strictly speaking, this Workflow specifically wouldn't have a way to create the new JWT
• However, the GH Action Use Case Owner (me) would run a step just prior to using this Workflow to generate their own claim and get it signed with the securely stored key.
• So, in practice, the flow of the GHA Use Case would go like this
  • Fetch credentials for authenticating to secret store (or use trust-based, no-preshared-secret integration)
  • Create claim data.
  • Call the "/sign" endpoint of the private key, where it is stored in the secret store (e.g. Vault Transit Engine)
  • Provide the complete JWT to this Action step, to complete authentication with github
• It works for me - I've implemented this flow (in a private system)... but I had to do it with custom code. I wish that the public Action supported the flow so that it could be used by everyone and the custom code could be deprecated.

[revdarragh]

If you like, please feel free to get a pull request started

Unfortunately, I don't have the coding skills to contribute the change directly. I would if I could!