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_プレフィックスにすることはできません。 - 名前の最初を数字にすることはできません。
- 名前では大文字と小文字は区別されません。
- 名前は、作成されたレベルで一意である必要があります。
複数のレベルで同じ名前のシークレットが存在する場合、最も低いレベルのシークレットが優先されます。 たとえば、Organization レベルのシークレット名がリポジトリレベルのシークレット名と同じ場合、リポジトリレベルのシークレット名が優先されます。 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
Warning
ジョブでシークレットが使われた場合、GitHub はログに出力されるシークレットを自動的に削除します。 シークレットを意図的にログに出力しないようにする必要があります。
Organizationレベルで保存されたシークレットについては、アクセスポリシーを使ってどのリポジトリがOrganizationのシークレットを利用できる化を制御できます。 Organizationレベルのシークレットを利用すると、複数のリポジトリ間でシークレットを共有できるので、重複してシークレットを作成する必要が軽減されます。 一カ所でOrganizationシークレットを更新すれば、そのシークレットを使うすべてのリポジトリワークフローにその変更が有効になることを保証できます。
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 App を使用して認証済み API 要求を作成する.