Add token permissions for ci/erlang.yml

[varunsh-coder]

This is related to issue #1299. This PR adds token permissions for ci/erlang.yml.

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.

---

Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.

---

Tasks

For all workflows, the workflow:

• Should be contained in a .yml file with the language or platform as its filename, in lower, kebab-cased format (for example, docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
• Should use sentence case for the names of workflows and steps (for example, "Run tests").
• Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
• Should include comments in the workflow for any parts that are not obvious or could use clarification.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, ci/properties/docker-publish.properties.json).
• Should run on push to branches: [ $default-branch ] and pull_request to branches: [ $default-branch ].
• Packaging workflows should run on release with types: [ created ].
• Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, docker-publish.yml).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (for example, code-scanning/properties/codeql.properties.json), with properties set as follows:
  • name: Name of the Code Scanning integration.
  • organization: Name of the organization producing the Code Scanning integration.
  • description: Short description of the Code Scanning integration.
  • categories: Array of languages supported by the Code Scanning integration.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.
• Should run on push to branches: [ $default-branch, $protected-branches ] and pull_request to branches: [ $default-branch ]. We also recommend a schedule trigger of cron: $cron-weekly (for example, codeql.yml).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, or
• This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be published to the GitHub Marketplace. We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
• Automation and CI workflows cannot be dependent on a paid service or product.

[bishal-pdMSFT]

Why is this needed?

[varunsh-coder]

This permission at the workflow (top) level is so that any future jobs that get added to the same workflow are secure by default. It also makes the changes in-line with expectation from ossf/scorecard. You can see the discussion here.

CC: @laurentsimon

[bishal-pdMSFT]

The discussion ⬆️ was good read. Thanks!
And I agree it makes sense to add permission at workflow level for new jobs.

[bishal-pdMSFT]

I believe contents: read is a default permission even for restricted access.
So in a strict sense this change is not needed, and that keeps the workflow simple.

[varunsh-coder]

My understanding is that when a new GitHub org or repo is created, the default GitHub Action token permissions are permissive. By that I mean that all permissions are granted to the GITHUB_TOKEN. So, if contents: read is not added in the workflow file, the token will get all permissions.

Moreover, while writing the starter workflows, we do not know what is the token permission set at the org/ repo level for whoever will use the workflow. So, the permissions should be specified in the workflow file.

[bishal-pdMSFT]

So, if contents: read is not added in the workflow file, the token will get all permissions.

That's a good point in case of permissive repos/orgs.

[bishal-pdMSFT]

However, given that we have already specified a workflow level read permission, this job level permission seems redundant.
I am not against good practice of explicit permissions, but this one here is just adding one more line which is not much useful. Simplicity of workflow is important, especially in this repo as it is meant for the users to get started with workflows.

[varunsh-coder]

@bishal-pdMSFT this is good feedback. Since the changes are done via automation, I would want to address this via a configuration option in the automation. What if there is a configuration option to Only set job level permissions. In this case, the workflow level (top level) permissions will not be set, and only job level permissions will be set. So the workflow would be simpler. Moreover, the workflow would get a score of 9 in scorecards. Not perfect from a security perspective, but it balances security with simplicity. Will this work?

CC: @laurentsimon

[varunsh-coder]

@laurentsimon please see feedback on this PR. The ask is to set contents: read at the workflow (top) level instead of permissions: read-all. This is what the repo level restrictive setting is (screenshot here), so it would align with that setting. Then I can update the StepSecurity automation such that if job level permission is contents: read, then do not add it explicitly (inherit from workflow). I believe this is aligned with what @bishal-pdMSFT is also asking for. What are your thoughts? I don't think you need to make changes to scorecards for this.

[laurentsimon]

contents: read sgtm. If additionally read permissions are needed for a job within the workflow, you'll add them all at the job level, correct?

[varunsh-coder]

contents: read sgtm. If additionally read permissions are needed for a job within the workflow, you'll add them all at the job level, correct?

Yes. Thanks! I will make this change.

[varunsh-coder]

@bishal-pdMSFT the logic has been updated to add contents: read at workflow level, and if job needs contents: read only, then to set no permissions at the job level. Applied changes to this yaml file. Let me know if the update looks fine.

[varunsh-coder]

@bishal-pdMSFT - reminder to please review this. Thanks!

[anuragc617]

Looks good to me.