Create a Guide/Template: How to Create Secrets in GitHub

[erniep278]

Overview

There are developers that need to create secrets for projects and are unaware of how to do so in GitHub. This causes an issue where Secrets are being used in a non-compliant way which increases our security risk.

Action Items

The phases in the guide-making process are listed below. Each phase displayed in blue is linked to a wiki page with instructions on how to complete that phase. Open the wiki page in a new tab, copy the instructions for each part into the section labeled 'Tasks' at the bottom of this issue, and complete each task listed.

• Gather Examples Solo (open in a new tab)
• Gather Examples Collaboratively
• Create a Guide Draft
  • If needed, create a template
• Have your guide peer reviewed
• Present your guide for leadership review

Resources/Instructions

• Google Drive Folder for this Guide’s documents and shortcuts (to documents in other locations) 0067 [DRAFT] How to Create Secrets in GitHub

GitHub's documentation: Using secrets in GitHub Actions

Review this link to understand how someone might hack your secrets:
https://stackoverflow.com/questions/63003669/how-can-i-see-my-git-secrets-unencrypted

Projects to Check

Tasks

• This is where you will copy instructions from the wiki page for the step you are currently on.

[erniep278]

https://stackoverflow.com/questions/63003669/how-can-i-see-my-git-secrets-unencrypted

[fyliu]

Retrieving secrets from repos is an unsupported usage. GitHub does the simple job of matching output with secrets values and replaces them with asterisks when found. If you break it up into first char + space + the rest, it won't prevent it.

This really means that teams need to audit all gha internal and external to make sure they don't do malicious things. For example, do not allow workflows extra permissions in settings. Recently, I read a recommendation to set more permissions on the individual jobs level rather than repo global or workflow global. See this example

[nyarly]

In general, we should consider "retrieving a secret" an *anti-*feature. Every secret is effectively a target of a security threat, and any way you could exfiltrate one should be considered a vulnerability.

Consider a case where a GHA uses a secret and runs code in the repo on PR (for instance: it runs tests) - an attacker could issue a PR with a new "test" that retrieves the secrets and exposes them in the logs - the examples above demonstrate how easy it is to evade the Github protections.

Fortunately, actions don't provide secrets they don't ask for, so we can consider secret usage on a per-Action basis, and reject new Actions that mix secret usage with the means to reveal the secret.

Again, consider retrieval and anti-feature. The cases where it seems necessary are better handled with e.g. credential rotation or a password vault.

[Aditya23soni]

Prior version of issue

Overview

There are developers that need to create secrets for projects and are unaware of how to do so in GitHub. This causes an issue where Secrets are being used in a non-compliant way which increases our security risk.

Action Items

• Research best practices for using Secrets in GitHub
• Research how you can use Secrets that are stored in GitHub
• Research how to show the secret (there is a way to view the secret after it's created).

Resources/Instructions

Here is the GitHub documentation about this:
https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-an-environment
Highlight this a have it stand out more to developers.

[Aditya23soni]

Assignee, Labels, Project Board Placement, and Milestones for this issue in the Ops Repo: