Allow using a GitHub App installation token in place of a PAT

[jamesmortensen]

Thank you for creating this action! We're looking forward to being able to have private actions without needing to fork out the big bucks for GitHub Enterprise.

From a security perspective, GitHub recommends using Deploy keys or GitHub Apps for cross-repository access instead of PAT's whenever possible:

You should never use personal access tokens from your own account. These tokens grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your personal account. This indirectly grants broad access to all write-access users of the repository the workflow is in. In addition, if you later leave an organization, workflows using this token will immediately break, and debugging this issue can be challenging.
If a personal access token is used, it should be one that was generated for a new account that is only granted access to the specific repositories that are needed for the workflow. Note that this approach is not scalable and should be avoided in favor of alternatives, such as deploy keys.

One alternative that's more secure is to use a GitHub App and sign a GITHUB_INSTALL_TOKEN:

GitHub App tokens

• GitHub Apps can be installed on select repositories, and even have granular permissions on the resources within them. You could create a GitHub App internal to your organization, install it on the repositories you need access to within your workflow, and authenticate as the installation within your workflow to access those repositories.

And they also add the following information about deploy keys, which are most preferred for cross-repo access:

• Deploy keys are one of the only credential types that grant read or write access to a single repository, and can be used to interact with another repository within a workflow. For more information, see "Managing deploy keys."
• Note that deploy keys can only clone and push to the repository using Git, and cannot be used to interact with the REST or GraphQL API, so they may not be appropriate for your requirements.

Moreover, the GitHub documentation describes how to use a GitHub App token to clone a project as follows:

$  git clone https://x-access-token:<token>@github.com/owner/repo.git

I believe this could be enabled by adding a flag to differentiate between PAT tokens and GitHub App Tokens. For PAT, we'd use this code to generate the URL, while for a GitHub App token, we'd use the x-access-token: method shown above:

// Generate repository URL for the action to checkout with PAT
const url = `https://${token}:[email protected]/${org}/${repo}.git`;

// generate repository URL for the action to checkout with GitHub App Token
const url = `https://x-access-token:${token}@github.com/${org}/${repo}.git`;

I am not yet sure how the clone URL would look with a deploy key, but these steps should help make things more secure so the private action doesn't have access to everything the developer has access to. Hope this information is helpful!

[nikita-volkov]

You're right. Using PAT in a team setting is a major vulnerability, because every team member will be able to access all of your private repos.

I've found that deploy keys can be used for these purposes. What solution have you settled on?

[jamesmortensen]

In my personal projects, I mostly use deploy keys if all I need to do is clone a separate repo. If more than one repo may need to access the same repo, or if GitHub API usage is required, I will create a GitHub app and then use it to create access tokens on repos where it is installed.

I have also used a PAT created through a machine user on one project, (which is a GitHub account created explicitly for the purpose of accessing outside repos where the machine user is granted minimal permissions.)

I feel each methodology has its pros and cons, but for something like private GitHub Actions, we simply used deploy keys or machine users to clone the repo and then run the action locally. Under the hood, that is what this action does is just clone the repo. But by not using the private action loader, we were able to run shell scripts, not only JavaScript...

As an aside, I also had a demo where I published a private action to GitHub npm packages and then imported it into a workflow using npm install, but I abandoned the idea since cloning seemed to be more widely used (and hence easier for folks to understand).