Add recommendation to use environment secrets instead of repository secrets#273
Add recommendation to use environment secrets instead of repository secrets#273jack-berg wants to merge 1 commit into
Conversation
| publishing, signing, and other privileged workflows. | ||
|
|
||
| With **repository secrets**, any workflow running in the repository can access | ||
| them — including workflows triggered on non-protected branches. This means |
There was a problem hiding this comment.
I do not even know how to type an em-dash on the keyboard 😉
| them — including workflows triggered on non-protected branches. This means | |
| them, including workflows triggered on non-protected branches. This means |
|
|
||
| With **repository secrets**, any workflow running in the repository can access | ||
| them — including workflows triggered on non-protected branches. This means | ||
| anyone with write access could push a non-protected branch containing secret |
There was a problem hiding this comment.
I suggest capitalizing the role name https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization
| anyone with write access could push a non-protected branch containing secret | |
| anyone with Write access could push a non-protected branch containing secret |
| With **environment secrets**, access is restricted to workflows running in the | ||
| context of a named environment, and that environment can be configured to only | ||
| allow deployments from specific branches. This means even a contributor with | ||
| write access cannot access the secrets without their code successfully passing |
There was a problem hiding this comment.
| write access cannot access the secrets without their code successfully passing | |
| Write access cannot access the secrets without their code successfully passing |
| context of a named environment, and that environment can be configured to only | ||
| allow deployments from specific branches. This means even a contributor with | ||
| write access cannot access the secrets without their code successfully passing | ||
| all branch protection criteria — i.e., an approved and merged PR. |
There was a problem hiding this comment.
| all branch protection criteria — i.e., an approved and merged PR. | |
| all branch protection criteria, i.e., an approved and merged PR. |
| 4. Remove the corresponding repository-level secrets. If both exist, the | ||
| repository-level secret remains accessible from any branch, defeating the | ||
| purpose. |
There was a problem hiding this comment.
maybe swap ordering of 4 and 5, and mention something about may need to backport the release workflow update if making an older patch release
|
Bah, forgot to create the branch on my fork. See #274 instead. |
yeah, this is annoying, proposing to block the initial creation to avoid the after-the-fact surprise: https://github.com/open-telemetry/admin/pull/676 |
https://cloud-native.slack.com/archives/C01NJ7V1KRC/p1779975433850719
Companion PR: open-telemetry/community#3480