is there a need for checkout with the stale action?

[Bad3r]

Hi there! Looks like discussions are not available yet; apologies for posting in the issue tracker.

I noticed in the workflow stale.yml you have added steps for harden runner and the checkout action. Are you just following the same template for the other workflows, or is there a need to check out the repo before being able to parse issues?

As far as I know, GitHub issue tracker is separate from the repo content

[GregoireF]

Hello @Bad3r,

Many thanks for your attention to [wr-projects/github-template]().

Regarding your incident, I investigated at actions/stale and I could see that they indicate in their repo-token documentation: ${{ github.token }}. Also, I decided to apply the strategy of communicating the PAT through actions/checkout from now on and not through stale directly. However, maybe I'm doing it wrong and it's not necessary? So I went with the assumption to apply the same strategy as all other workflows requiring a PAT.

Did I bring you the expected answer?

Have a nice day,

Best regards. Grégoire FAVREAU - WRProjects

[Bad3r]

@GregoireF Thanks for the quick response!

honestly I am new to GH actions and stale specifically. I started looking into it because we want to use it for the Logseq project: https://github.com/logseq/logseq/pull/8125

However, maybe I'm doing it wrong and it's not necessary?

Based on the documentation you linked I think its good to have (?) assuming PAT gives it all user permissions.

I am confused because they recommend adding the following permissions to the workflow: https://github.com/actions/stale#recommended-permissions

Not sure how that compares security wise to using a custom app token with limited permissions.

[GregoireF]

@Bad3r, as you may have noticed through my stale action I decided to add the following action: peter-murray/workflow-application-token-action which allows me to create a GitHub Apps in order to provide better tokens close to a PAT but having granular restriction possibilities according to your need.

Also, I just recently added permissions to the workflow in order to respect the security requested on the workflows by GitHub directly or even StepSecurity.

Excuse me for the somewhat unstable workflow, we are in development on this project. Our goal is to provide a reusable model is safe for opensource.

[Bad3r]

Yes I noticed. I would like to improve logseq handling of tokens in scripts based on your template. It's been already an extremely helpful reference.

Do you have reading recommendations on the best way to set up the current Auth system?

Do you create a separate app for each actions with the required permissions? I noticed that github actions scheme allows for limiting app tokens inside the workflow.

I am not sure if I should create an app for each action or an app with all permissions required by all actions. Then limiting the permission scope in the yml file

[GregoireF]

@Bad3r, I must be honest with you that I've mostly analyzed a lot of GitHub Actions trying to keep in mind the DevSecOps aspect.

What I can recommend at this time, is to actually run most of your GITHUB_TOKEN through the peter-murray/workflow-application-token-action job allowing you to create internal GitHub applications for your organization/person to do manually. The process can be found here for creating GitHub Apps. However, it is necessary to be vigilant as an incident, on their side has been raised and I need to pay more attention to it in the next few days. You should also store your token in the actions/checkout process as it is advised at the moment because in my opinion, it seems to make more sense than what is proposed in most workflows...

It is not necessary to create an application for each action, it is rather necessary to create an application for each action requiring the use of a PAT with authorization requests.

Also, after a read today, I can confirm that it is necessary to use permissions in order to meet security standards for GitHub Actions requiring permissions. It is considered at the moment that any use of a PAT requires :

permissions:
  contents: read

[Bad3r]

Thank you for the information. I'll look more into the topic as my knowledge is lacking.

once discussions is setup; please move this issue to a discussion as I think it might be valuable for other users. I also would like to continue this discussion after more reading on the subject.

I look forward to seeing how this project progress over time! Thank you for all the hard work!

[GregoireF]

Thank you for your interesting question and your attention to this project. We will gladly move your question to the discussion threads once implemented.

I will be happy to provide you with additional information in the future.

[Bad3r]

@GregoireF I did more reading on the topic. First, I want to start by defining the different authentication mechanisms discussed.
 

• The GITHUB_TOKEN
  • This token is intentionally scoped to the single repository that invoked the workflow, and can have the same level of access as a write-access user on the repository. The token is created before each job begins and expires when the job is finished. For more information, see "Authenticating with the GITHUB_TOKEN."
  • The GITHUB_TOKEN should be used whenever possible.
• 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.
• Personal access tokens
  • You should never use a personal access token (classic). 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.
  • If you do use a personal access token, you should never use a personal access token from your own account. If you later leave an organization, workflows using this token will immediately break, and debugging this issue can be challenging. Instead, you should use a fine-grained personal access tokens for a new account that belongs to your organization and 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.

GITHUB_TOKEN != PAT

These definitions are from Security hardening for GitHub Actions - GitHub Enterprise Cloud Docs. 

As you can see, GitHub recommends using GITHUB_TOKEN whenever possible. 
Here is the default GITHUB_TOKEN permissions as described in Automatic token authentication - GitHub Docs:

Scope	Default access (permissive)	Default access (restricted)	Maximum access for pull requests from public forked repositories[†]
actions	read/write	none	read
checks	read/write	none	read
contents	read/write	read	read
deployments	read/write	none	read
id-token	none	none	read
issues	read/write	none	read
metadata	read	read	read
packages	read/write	none	read
pages	read/write	none	read
pull-requests	read/write	none	read
repository-projects	read/write	none	read
security-events	read/write	none	read
statuses	read/write	none	read

The permissions for the token can be modified and scoped per job, as described in Assigning permissions to jobs - GitHub Docs.

workflow-application-token-action

In the description of this action, it's explained why you might want to use this over the default and secure GitHub Token:

Why would you want to do this? Well the GITHUB_TOKEN whilst having an expiry, has some protections around creating events that prevent downstream GitHub Actions workflow from triggering. This prevents recursive loops from workflows, but there are a number of valid types of workflows that may require or desire triggering downstream GitHub Actions Workflows.

In other words; this action is used to circumvent some protections in GitHub token.  

I am opting to not use workflow-application-token-action in our project and use GITHUB_TOKEN instead with limited permissions.
I still need to investigate https://github.com/step-security/harden-runner

[Bad3r]

There are other considerations to be taken, such as limiting network outbound traffic. I found this article useful:
https://blog.gitguardian.com/github-actions-security-cheat-sheet/

[GregoireF]

Hello @Bad3r,

I hope you will forgive me for the wait, I have been very active during this week. I thank you for your investigation and your time that you gave us.

Indeed GITHUB_TOKEN is a good solution advised by GitHub as you indicated, on the other case, in my opinion, I prefer to use much more granular options as it can be obtained through GITHUB_APP_TOKENS in order to provide only what is necessary for my GitHub App. Also, you can directly specify permissions through your workflow in addition to using GITHUB_APP_TOKEN with granular permissions such as:

permissions:
  contents: read
  pull-requests: write

It is however good to specify that the use of GITHUB_APP_TOKEN is done preferably in the case where my flow expects to connect to the repository such as: https://github.com/wr-projects/github-template/actions/runs/3875201706

In case of outgoing traffic, I can recommend an alternative approach that can be found in my various action flows:

 steps:
      # More info: https://github.com/step-security/harden-runner.
      - name: Harden Runner
        id: harden_runner
        uses: step-security/harden-runner@ebacdc22ef6c2cfb85ee5ded8f2e640f4c776dd5
        with:
          egress-policy: audit

Thereafter, Harden Runner shows you, through its tools, the precautions to take with regard to the incoming/outgoing traffic of your workflows:

steps:
      # More info: https://github.com/step-security/harden-runner.
      - name: Harden Runner
        id: harden_runner
        uses: step-security/harden-runner@ebacdc22ef6c2cfb85ee5ded8f2e640f4c776dd5
        with:
          disable-sudo: true
          egress-policy: block
          allowed-endpoints: >
            api.github.com:443
            github.com:443

Documentation of Harden Runner: https://github.com/step-security/harden-runner

Best regards,

Grégoire FAVREAU

[github-actions[bot]]

The issue has been marked as stale due to inactivity. Please show activity within 8 days or it will be automatically closed.

[github-actions[bot]]

The issue has been automatically closed.