Create a wiki page about best practices for maintaining GitHub secrets

[SAUMILDHANKAR]

Overview

As a developer, I would like all the secrets being used in the website repo to be well maintained. In this issue, we will create a wiki page about the best practices for maintaining and resetting secrets in GitHub repos.

Action Items

• [x] We are currently in the process of moving the old wiki to the new website-wiki repo, so we will not be making any changes or additions to the old wiki at this time. Thus, we will be adding wiki content through a different process now. Read How to Contribute to the Wiki
• [x] Explore how GitHub secrets and tokens work.
• [x] Research the best practices for resetting secrets in general, including the Audit and rotate registered secrets as well as Audit how secrets are handled sections in this helpful article on using secrets.
• [x] Decide on what would be the best place to add your research to HfLA wiki pages
• [x] Create a draft wiki page in a comment in this issue, and list your recommendations/suggestions that might be helpful for the website team going forward.
• [x] Once done, place this issue in the Questions/In Review column and add the ready for dev lead label.
• [x] When the draft is approved, add a link to the draft to How to Contribute to the Wiki
• [x] For reviewers: Once this issue is approved and closed, check off the dependency in #3228, remove the dependency label and move issue #3228 from ice box column to the new issue approval column.

Resources/Instructions

• GitHub encrypted secrets
• HfLA wiki pages
• Note from a prior assignee to this issue:

  I did speak with some open source repository maintainers and they said that they just waited for the emails. They suggested that we make sure that the emails from github are visible. I think we have a problem with someone being responsible for checking the email that the repository sends to. We might consider adding a notification to the channel or calendar to update secrets. It is not considered best practice to never update secrets.

[roslynwythe]

@ExperimentsInHonesty I don't think it is necessary to restrict this issue to dev leads. I suggest we can reomove the role: dev leads and add role: back end/devOps. Then it is ready for prioritization.

[HackforLABot]

Hello @k-cardon, we appreciate you taking on this issue, however it looks like you're already working on another issue at this time. Please wait until your current issue is merged before taking on another issue. :)

We are going to unassign you from this issue so you can focus on your current issue.

Hfla appreciates you! :)

[HackforLABot]

Hello @k-cardon, we appreciate you taking on this issue, however it looks like you're already working on another issue at this time. Please wait until your current issue is merged before taking on another issue. :)

We are going to unassign you from this issue so you can focus on your current issue.

Hfla appreciates you! :)

[HackforLABot]

Hi @k-cardon, HfLA appreciates your interest in this issue, but please note that it is in the "New Issue Approval" column of the Project Board because it has not been finalized, approved, or prioritized, and so it is not ready for assignment. For this reason, you have been unassigned from this issue. Please remember to assign issues only from the "Prioritized Backlog" column.

The only exceptions to this rule are if you are writing an issue and the Draft label is applied, or if you are self-assigning to your "Pre-work Checklist" (the issue includes the Complexity: Prework label).

[HackforLABot]

Hi @k-cardon, HfLA appreciates your interest in this issue, but please note that it is in the "New Issue Approval" column of the Project Board because it has not been finalized, approved, or prioritized, and so it is not ready for assignment. For this reason, you have been unassigned from this issue. Please remember to assign issues only from the "Prioritized Backlog" column.

The only exceptions to this rule are if you are writing an issue and the Draft label is applied, or if you are self-assigning to your "Pre-work Checklist" (the issue includes the Complexity: Prework label).

[HackforLABot]

Hi @k-cardon, HfLA appreciates your interest in this issue, but please note that it is in the "New Issue Approval" column of the Project Board because it has not been finalized, approved, or prioritized, and so it is not ready for assignment. For this reason, you have been unassigned from this issue. Please remember to assign issues only from the "Prioritized Backlog" column.

The only exceptions to this rule are if you are writing an issue and the Draft label is applied, or if you are self-assigning to your "Pre-work Checklist" (the issue includes the Complexity: Prework label).

[k-cardon]

This issue was in the prioritized backlog, so I assigned myself to it. I was removed because I had another issue-making issue (#6709) for which I was waiting for permission to begin so I could make myself a medium issue. I have now removed myself from the issue making issue so that I could do this medium issue instead; however, it has now been moved out of the "Prioritized Backlog" so that I am not allowed to assign myself anymore.

[HackforLABot]

Hi @k-cardon, 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 :)

[k-cardon]

Availability: 1 hr right now, more time Thursday evening and weekend

Eta: end of week

[k-cardon]

Here's a draft of the info for the wiki (I think it would fit on the currently blank page "GitHub Actions" https://hackforla.github.io/website-wiki/roles/dev/github-actions/)

Maintaining GitHub Secrets

The owner of a GitHub repo can create and manage secrets stored by GitHub. It's a good idea to regularly audit and rotate secrets to reduce risk of a compromised secret affecting the product or users. For a guide to implementing, using, and updating secrets stored by GitHub, refer to this page.

An audit of secret security would include:

1. Periodically review the registered secrets to confirm they are still required. Remove those that are no longer needed.
2. Reviewing the source code of the repository executing the workflow, and checking any actions used in the workflow. For example, check that they’re not sent to unintended hosts, or explicitly being printed to log output.
3. View the run logs for your workflow after testing valid/invalid inputs, and check that secrets are properly redacted, or not shown.
4. Rotate secrets periodically.

More info available here.

One option is to create some auto-generated issues that pop up periodically, perhaps annually or biannually, that prompt devs to undertake steps 1-3 above, and perhaps whoever owns the repo could undertake step 4 on a similar schedule. The codebase would need to be updated with an issue template for each one and a GitHub action that auto-generates the issue using the template 1-2 times per year.

[roslynwythe]

@k-cardon please add to your comments, what is the best way for us to auto-generate issues annually or biannually, to prompt devs to undertake these steps.? Is that done via a GHA workflow? Also please add a link to your comment/draft in https://github.com/hackforla/website/wiki/How-to-Contribute-to-the-Wiki

[k-cardon]

@roslynwythe thanks for your comments! I updated the text and added the link to that contributions page.

[ExperimentsInHonesty]

@k-cardon - Please write a decision record (it should include the best practices that you wrote up) drafted in a new comment

Use the template from here https://github.com/hackforla/website/wiki/Decision-Records-on-Solutions-Adopted#template

Once approved, the decision record will end up on these pages https://github.com/hackforla/website/wiki/Decision-Records-on-Solutions-Adopted https://github.com/hackforla/website/wiki/Decision-Records

and a link to your final approved draft comment will get linked to this page https://github.com/hackforla/website/wiki/How-to-Contribute-to-the-Wiki

And the decision is to do what you suggest with these specifics 1 GHA to make an issue, bi-annually (twice a year), that has a volunteer with Admin access change the secrets.

[ExperimentsInHonesty]

and when you are done creating it, add a ready for dev lead label and move it back to Questions / Review column

[k-cardon]

This is a record in the Decision Records on Solutions Adopted.

Issue

Best practices for maintaining GitHub secrets

Problem Statement

We store H4LA secrets in GitHub and do not currently have a regular system for maintaining and rotating them, which are best practices for security.

Potential Solution

We could resolve this with: 1 GHA to make an issue, bi-annually (twice a year), that has a volunteer with Admin access change the secrets, and 1 GHA to make an issue, bi-annually (twice a year), that prompts a volunteer to audit existing secrets to confirm they are still needed and not unintentionally revealed in logs

Feasibility Determination

For a volunteer with Admin access, rotating secrets is a quick and straightforward task. For auditing existing secrets, we will need to establish a list of where and how the secrets are currently used so that it can become a simple task to check the logs and to check whether the secrets are in use. Putting that into place will make both of these tasks routine.

[roslynwythe]

Thank you @k-cardon for excellent analysis and writing!