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.

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

ER: Create Epic to address GitHub permissions vulnerabilities #6649

Open
4 of 5 tasks
gaylem opened this issue Apr 15, 2024 · 10 comments
Open
4 of 5 tasks

ER: Create Epic to address GitHub permissions vulnerabilities #6649

gaylem opened this issue Apr 15, 2024 · 10 comments
Assignees
Labels
Complexity: Large Complexity: See issue making label See the Issue Making label to understand the issue writing difficulty level ER Emergent Request Feature: Refactor GHA Refactoring GitHub actions to fit latest architectural norms Issue Making: Level 4 Create an Epic Issue, and it's Level 2 or 3 issues role: back end/devOps Tasks for back-end developers size: 3pt Can be done in 13-18 hours
Milestone

Comments

@gaylem
Copy link
Member

gaylem commented Apr 15, 2024

Emergent Requirement - Problem

Right now, our permissions are set to read and write but this isn't best practice. According to GitHub, "It's good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents. The permissions can then be increased, as required, for individual jobs within the workflow file."

Screenshot of current repo settings:

screenshot_2024-04-14_115940

The GITHUB_TOKEN is automatically created and available for use in your workflows without any extra setup. It can be used for lots of things, like PR automation, workflow triggers, and accessing the GitHub API. It's probably the right token for a lot of the things we do. However, it does have some limitations, such as restricted scopes for certain actions. For more sensitive operations or when more specific permissions are needed, you may need to use custom secrets with more finely tuned scopes. If we change it to read only instead of read/write, it will have an even more limited scope.

Additionally, we are setting specific permissions in some of our workflow files (Ex: codeql.yml). In some cases this may be redundant.

This epic and its issues should determine whether or not the permissions set in workflows are needed if we change the GITHUB_TOKEN scope to read only. Or, perhaps we will need to add additional write permissions. In other words, we need an audit of our permissions across our workflows to identify where we need to restrict or expand access for each workflow.

Issue you discovered this emergent requirement in

Date discovered

2024-04-15

Did you have to do something temporarily

  • YES
  • NO

Who was involved

@gaylem

What happens if this is not addressed

If this isn't addressed, there's an increased risk of unintended changes being made to the repository, potentially leading to data loss, security breaches, or other issues.

By following best practices and setting the default permission to read access, we will reduce the potential impact of any accidental or malicious actions, as the token will only have the ability to read repository contents. This minimizes the risk of unauthorized modifications and helps ensure the overall security of our GitHub workflows.

Resources

Recommended Action Items

  • Make a new issue
  • Discuss with team
  • Let a Team Lead know

Potential solutions [draft]

We need an issue to assess how we handle permissions in GitHub. This issue needs to accomplish the following:

  1. Identify all files that use more than read permissions
  2. Create an epic
  3. Add issues to the epic to modify permissions on each file individually and test locally

We need to be sure we won't introduce any breaking changes before flipping the repo setting back to read-only

@gaylem gaylem added role: back end/devOps Tasks for back-end developers Complexity: Large Feature: Refactor GHA Refactoring GitHub actions to fit latest architectural norms size: 3pt Can be done in 13-18 hours ER Emergent Request ready for dev lead Issues that tech leads or merge team members need to follow up on labels Apr 15, 2024
@roslynwythe

This comment was marked as resolved.

@roslynwythe roslynwythe added Ready for Prioritization and removed ready for dev lead Issues that tech leads or merge team members need to follow up on labels Apr 18, 2024
@gaylem

This comment was marked as resolved.

@roslynwythe

This comment was marked as resolved.

@ExperimentsInHonesty ExperimentsInHonesty added this to the 02. Security milestone Apr 22, 2024
@ExperimentsInHonesty

This comment was marked as resolved.

@ExperimentsInHonesty ExperimentsInHonesty added ready for dev lead Issues that tech leads or merge team members need to follow up on and removed Ready for Prioritization labels Apr 23, 2024
@ExperimentsInHonesty ExperimentsInHonesty added the Draft Issue is still in the process of being created label Apr 23, 2024

This comment was marked as resolved.

@gaylem gaylem removed their assignment Apr 24, 2024
@gaylem gaylem removed the Draft Issue is still in the process of being created label Apr 24, 2024
@ExperimentsInHonesty
Copy link
Member

@gaylem

This comment was marked as resolved.

@gaylem
Copy link
Member Author

gaylem commented Apr 29, 2024

Hey @ExperimentsInHonesty, I don't think that testing will be impacted by this issue and so #6402 shouldn't be a dependency.

The only way testing might be impacted is if we have to create new tokens or change any scopes. That may not happen, though, and it doesn't make sense to delay updating our overall GHA instructions to wait for this.

Personally, I think updating the instructions is a more pressing issue and would rather make some minor tweaks later on if our audit reveals a need for token changes.

Let me know what you think. Thanks!

@gaylem gaylem removed their assignment Apr 29, 2024
@gaylem gaylem added Ready for Prioritization and removed ready for dev lead Issues that tech leads or merge team members need to follow up on labels Apr 29, 2024
@ExperimentsInHonesty ExperimentsInHonesty added the Complexity: See issue making label See the Issue Making label to understand the issue writing difficulty level label Jun 9, 2024
@ExperimentsInHonesty ExperimentsInHonesty moved this to ERs and epics that are ready to be turned into issues in P: HfLA Website: Project Board Jun 23, 2024
@ExperimentsInHonesty ExperimentsInHonesty added the Issue Making: Level 4 Create an Epic Issue, and it's Level 2 or 3 issues label Jun 23, 2024
@ExperimentsInHonesty
Copy link
Member

ExperimentsInHonesty commented Nov 5, 2024

Make the following issues

  • Audit all the workflow files to determine what permissions each require (this issue creates the spreadsheet and details what they find)
  • Reviewing the list of permission (in the spreadsheet), write a decision record on how to improve existing policy
  • Epic for making template and issue that will change the permissions (IM2)
    • change permissions in one file
    • ...

@ExperimentsInHonesty ExperimentsInHonesty moved this from ERs and epics that are ready to be turned into issues to In progress (actively working) in P: HfLA Website: Project Board Nov 5, 2024
@HackforLABot
Copy link
Contributor

Hi @dcotelessa, thank you for taking up this issue! Hfla appreciates you :)

Do let fellow developers know about your:-
i. Availability: (When are you available to work on the issue/answer questions other programmers might have about your issue?)
ii. ETA: (When do you expect this issue to be completed?)

You're awesome!

P.S. - You may not take up another issue until this issue gets merged (or closed). Thanks again :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Complexity: Large Complexity: See issue making label See the Issue Making label to understand the issue writing difficulty level ER Emergent Request Feature: Refactor GHA Refactoring GitHub actions to fit latest architectural norms Issue Making: Level 4 Create an Epic Issue, and it's Level 2 or 3 issues role: back end/devOps Tasks for back-end developers size: 3pt Can be done in 13-18 hours
Projects
Status: In progress (actively working)
Development

No branches or pull requests

5 participants