Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add token permissions for ci/erlang.yml #1341

Merged
merged 4 commits into from
Mar 30, 2022
Merged

Add token permissions for ci/erlang.yml #1341

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
f42f92e
Update erlang.yml
varunsh-coder Jan 5, 2022
3c01b83
Merge branch 'actions:main' into varunsh-coder-erlang
varunsh-coder Jan 21, 2022
eedf8fb
Update erlang.yml
varunsh-coder Jan 21, 2022
d01cf9a
Merge branch 'main' into varunsh-coder-erlang
Phantsure Mar 30, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions ci/erlang.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,10 +6,14 @@ on:
pull_request:
branches: [ $default-branch ]

permissions: read-all
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


jobs:

build:

permissions:
contents: read # for actions/checkout to fetch code
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

runs-on: ubuntu-latest

container:
Expand Down