Proposal: Switch from GitHub Personal Access Tokens to SSH Keys for Exchange Packs #26
Comments
|
What does CircleCI recommend? I think this it it, just confirming
… On May 21, 2020, at 8:13 AM, Nick Maludy ***@***.***> wrote:
Background
Currently we have ~165 packs in the Exchange. Every pack is setup in CircleCI and has an automated deploy phase that runs when a change is merged into master. This deploy phase updates the exchange index repository with new metadata about the pack along with the most up-to-date version based on the version in pack.yaml.
This whole process runs inside of the CircleCI workflow. CircleCI is able to push to the repositories because it has access to a GitHub Personal Access Token (PAT) that we, StackStorm maintainers, generate and attach to the CircleCI project for this pack.
Problem
GitHub PAT expire after one year. Once expired, the deploy phase of a pack will fail and will require human intervention to go rotate the key. At 165 packs / 52 weeks per year, that's ~3 PATs that need rotated every week.
I've been looking into to automating this key rotation and found that the API to request to Personal Access Tokens is deprecated and going away on November 13, 2020: https://developer.github.com/v3/oauth_authorizations/#create-a-new-authorization .
Solution Proposal
The suggested path to replace the PAT based on the deprecation message is their new Web Application Flow geared towards web-app development where a user can interactively login. This is not what we want.
Taking a step back i did some more research on GitHub and i believe we may have been using the wrong "tool" in the first place. GitHub supports the idea of a Deploy Key which are SSH keys that are unique and provide access to only a single repository. They can be given write permission to the repository in case code updates need to be made. They can also be added to a repository via the GitHub API Add a new deploy key. Another property of deploy keys is that they last forever (we can make our own policy to rotate if we like).
My proposal is to switch out our current Personal Access Token secrets in exchange for SSH Deploy Keys.
Positive points for SSH deploy keys:
They are just regular SSH keys, we manage the private key and add the public key to the repo (GitHub doesn't know about our private key).
Deploy keys last forever, so we should have much lower maintenance overhead.
Security is still high because Deploy Keys only have access to a single repository, ie. keys are unique-per-repository. This reduces our "blast radius" in case a key is compromised.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@punkrokk It looks like CircleCI recommends "both". Basically use whatever works for you. It looks like we chose the "Machine User" approach and instead of using a shared password, we use unique Personal Access Tokens for each repo. This is just my guess, i'm not actually able to see this stuff with the permissions i have. CircleCI does recommend deploy keys, and i'm sure there are some "gotchas" that we'll need to engineer. However, i think the upside is not having these keys expire, and also being able to automate their renewal via the API is a big plus. |
|
It turns out that PATs are only revoked if they have not been used for a year. (see https://github.community/t/api-access-token-expiry/14522) Also, PATs are also required to access the Github APIs. Unauthenticated rest API access has an extremely low limit, and graphql API calls require authentication. So, switching to ssh keys does not buy us anything as long as we are running things in CircleCI. If we move some or all of the workflows to GHA, then it might make sense to add keys for pushing to the index. See: #63 |
|
This is no longer needed now that we've switched the Exchange from CircleCI to Github Actions. |
Background
Currently we have ~165 packs in the Exchange. Every pack is setup in CircleCI and has an automated
deployphase that runs when a change is merged into master. This deploy phase updates the exchange index repository with new metadata about the pack along with the most up-to-date version based on the version inpack.yaml.This whole process runs inside of the CircleCI workflow. CircleCI is able to push to the repositories because it has access to a GitHub Personal Access Token (PAT) that we, StackStorm maintainers, generate and attach to the CircleCI project for this pack.
Problem
GitHub PAT expire after one year. Once expired, the deploy phase of a pack will fail and will require human intervention to go rotate the key. At 165 packs / 52 weeks per year, that's ~3 PATs that need rotated every week.
I've been looking into to automating this key rotation and found that the API to request to Personal Access Tokens is deprecated and going away on November 13, 2020: https://developer.github.com/v3/oauth_authorizations/#create-a-new-authorization .
Solution Proposal
The suggested path to replace the PAT based on the deprecation message is their new Web Application Flow geared towards web-app development where a user can interactively login. This is not what we want.
Taking a step back i did some more research on GitHub and i believe we may have been using the wrong "tool" in the first place. GitHub supports the idea of a Deploy Key which are SSH keys that are unique and provide access to only a single repository. They can be given
writepermission to the repository in case code updates need to be made. They can also be added to a repository via the GitHub API Add a new deploy key. Another property of deploy keys is that they last forever (we can make our own policy to rotate if we like).My proposal is to switch out our current Personal Access Token secrets in exchange for SSH Deploy Keys.
Positive points for SSH deploy keys:
Additional References:
The text was updated successfully, but these errors were encountered: