About secrets
Secrets allow you to store sensitive information in your organization, repository, or repository environments. Secrets are variables that you create to use in GitHub Actions workflows in an organization, repository, or repository environment.
GitHub Actions can only read a secret if you explicitly include the secret in a workflow.
Naming your secrets
Tip
To help ensure that GitHub redacts your secrets in logs correctly, avoid using structured data as the values of secrets.
The following rules apply to secret names:
- 비밀 이름에는 영숫자 문자(
[a-z],[A-Z],[0-9]) 또는 밑줄(_)만 사용할 수 있습니다. 공백은 사용할 수 없습니다. - 비밀 이름은
GITHUB_접두사로 시작할 수 없습니다. - 비밀 이름은 숫자로 시작할 수 없습니다.
- 이름은 대/소문자를 구분하지 않습니다.
- 비밀 이름은 해당 수준에서 고유해야 합니다.
이름이 같은 비밀이 여러 수준에 있는 경우 가장 낮은 수준의 비밀이 우선적으로 적용됩니다. 예를 들어 조직 수준 비밀의 이름이 리포지토리 수준 비밀과 동일한 경우 리포지토리 수준 비밀이 우선 적용됩니다. Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.
Using your secrets in workflows
경고: 작업에서 비밀이 사용된 경우 GitHub는 로그에 출력된 비밀을 자동으로 수정합니다. 의도적으로 로그에 비밀을 출력하지 않아야 합니다.
조직 수준에서 저장된 비밀의 경우 액세스 정책을 사용하여 조직 비밀을 사용할 수 있는 리포지토리를 제어할 수 있습니다. 조직 수준 비밀을 사용하면 여러 리포지토리 간에 비밀을 공유할 수 있으므로 중복 비밀을 만들 필요가 줄어듭니다. 또한 한 위치에서 조직 비밀을 업데이트하면 해당 비밀을 사용하는 모든 리포지토리 워크플로에서 변경 내용이 적용됩니다.
For environment secrets, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
To make a secret available to an action, you must set the secret as an input or environment variable in your workflow file. Review the action's README file to learn about which inputs and environment variables the action expects. See GitHub Actions에 대한 워크플로 구문.
Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
Limiting credential permissions
When generating credentials, we recommend that you grant the minimum permissions possible. For example, instead of using personal credentials, use deploy keys or a service account. Consider granting read-only permissions if that's all that is needed, and limit access as much as possible.
When generating a personal access token (classic), select the fewest scopes necessary. When generating a fine-grained personal access token, select the minimum permissions and repository access required.
Instead of using a personal access token, consider using a GitHub App, which uses fine-grained permissions and short lived tokens, similar to a fine-grained personal access token. Unlike a personal access token, a GitHub App is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see GitHub Actions 워크플로에서 GitHub 앱을 사용하여 인증된 API 요청 만들기.