-
Notifications
You must be signed in to change notification settings - Fork 59
Support using a remote HSM or JWT signing service in lieu of private keys #712
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
Support using a remote HSM or JWT signing service in lieu of private keys #712
Conversation
To enable the use of Azure Key Vault keys, or other HSMs, this allows for a callback to be provided in lieu of a GitHub App's private certificate. Does not contain test updates.
|
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with |
gr2m
left a comment
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 Jeff!! I think it's a great change! The request to accept a JWT instead of a private key came up several times across octokit and its dependents.
I like the approach of using a callback instead of passing a fixed JWT. That way @octokit/auth-app can re-create the JWT as needed.
I'd recommend to verify that usage with Octokit keeps working as before. It should be able to create installation tokens upon first request and auto-renew it when it expires.
Maybe consider renaming externalSignJwt to something simpler, like createJwt? The method should also accept a timeDifference argument to account for time skew between client and server, see
Lines 69 to 79 in 3b732be
| state.log.warn(error.message); | |
| state.log.warn( | |
| `[@octokit/auth-app] GitHub API time and system time are different by ${diff} seconds. Retrying request with the difference accounted for.`, | |
| ); | |
| const { token } = await getAppAuthentication({ | |
| ...state, | |
| timeDifference: diff, | |
| }); | |
| endpoint.headers.authorization = `bearer ${token}`; | |
| return request(endpoint as EndpointOptions); |
|
Sounds good, I'll get this cleaned up a bit. We've been using it in production with rest.js on jobs that run 24/7 and renew just fine but I'll integrate the updates I can make here to bake it a bit more. |
- renames to shorter "signJwt" method - adds "timeDifference" (number, seconds) to pass along for any errors related to skew
|
@gr2m k, minor updates addressed for now. Hopefully straightforward to rebase vs merge at some point.
Since the universal JWT module itself has a built-in -30s buffer in its logic, I don't love it, but added a comment in the README example to as much. It's probably not worth refactoring multiple libraries to consider passing |
|
Also just to confirm, wrote a hello world octokit app that calls App ran fine. |
| appId: APP_ID, | ||
| // @ts-ignore | ||
| privateKey: undefined, | ||
| privateKey: undefined as string, |
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 shouldn't be needed. The // @ts-ignore should make it be ignored
wolfy1339
left a comment
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.
LGTM
|
🎉 This PR is included in version 8.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Resolves #711 711
To use
@octokit/auth-app.js, you must always provide a fullprivateKeyoption. This can expose a GitHub App's private key to runtime environments which is much less secure than keeping the private key in a HSM or remote key signing service.The GitHub docs on storing private keys specifically suggests using sign-only keys stored securely.
This change is a basic update to allow for this alternate path from a
privateCertificatefor this more advanced and secure approach.I'm looking for feedback on this pull request, especially around variable names, approach on the types for the Strategy, etc. Since most users will continue to use
privateKey, unless the external JWT signing option is truthy, I've kept the "privateKey required" type helpful error message in place.Before the change?
After the change?
universal-github-app-jwtdependency and an in-memory keyPull request checklist
Does this introduce a breaking change?