ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情� �を見ることができます。
暗号化されたシークレットについて
シークレットは暗号化された環境変数で、Organizationあるいはリポジトリに作成できます。 作成したシークレットは、GitHub Actionsワークフローで利用できます。 GitHubはシークレットがGitHubに到達する前に暗号化され、ワークフローで使用されるまで暗号化されたままになっていることを確実にするのを助けるためにlibsodium sealed boxを使います。
Organizationレベルで保存されたシークレットについては、アクセスポリシーを使ってどのリポジトリがOrganizationのシークレットを利用できる化を制御できます。 Organizationレベルのシークレットを利用すると、複数のリポジトリ間でシークレットを共有できるので、重複してシークレットを作成する必要が軽減されます。 一カ所でOrganizationシークレットを更新すれば、そのシークレットを使うすべてのリポジトリワークフローにその変更が有効になることを保証できます。
シークレットに名前を付ける
シークレットの名前には次のルールが適用されます。
-
シークレット名には、英数字(
[a-z]
、[A-Z]
、[0-9]
)または下線(_
)のみを含めることができます。 スペースは使用できません。 -
シークレット名の最初を
GITHUB_
プレフィックスにすることはできません。 -
シークレット名の最初を数字にすることはできません。
-
シークレット名は大文字と小文字を区別しません。
-
シークレット名は、作成されたレベルで一意である必要があります。
たとえば リポジトリのレベルで作成されたシークレットはそのリポジトリ内でユニークな名前になっていなければならず、Organizationのレベルで作成されたシークレットはそのレベルでユニークな名前になっていなければなりません。
複数のレベルで同じ名前のシークレットが存在する� �合、低いレベルのシークレットが優先されます。 たとえば、Organization レベルのシークレット名がリポジトリレベルのシークレット名と同じ� �合、リポジトリレベルのシークレット名が優先されます。
GitHub がログのシークレットを確実に削除するよう、シークレットの値として構� 化データを使用しないでく� さい。 たとえば、JSONやエンコードされたGit blobを含むシークレットは作成しないでく� さい。
シークレットにアクセスする
シークレットをアクションが使用できるようにするには、ワークフローファイルでシークレットを入力または環境変数に設定する必要があります。 アクションに必要な入力および環境変数については、アクションのREADMEファイルを確認します。 詳しい情� �については、「GitHub Actionsのワークフロー構文」を参照してく� さい。
ファイルを編集するアクセス権を持っていれば、ワークフローファイル中の暗号化されたシークレットを使い、読み取ることができます。 詳細は「GitHub 上のアクセス権限」を参照してく� さい。
警告: GitHubは、ログに出力されたシークレットを自動的に削除しますが、シークレットをログに出力することは意識的に避けなくてはなりません。
REST API を使用してシークレットを管理することもできます。 詳しい情� �については、「シークレット」を参照してく� さい。
認証情� �のアクセス許可を制限する
認証情� �を生成する際には、可能な限り最小限の権限� けを許可することをおすすめします。 たとえば、個人の認証情� �を使う代わりに、デプロイキーあるいはサービスアカウントを使ってく� さい。 必要なのが読み取り� けであれば、読み取りのみの権限を許可すること、そしてアクセスをできるかぎり限定することを考慮してく� さい。 個人アクセストークン(PAT)を生成する際には、必要最小限のスコープを選択してく� さい。
Note: You can use the REST API to manage secrets. 詳しい情� �については「GitHub ActionsシークレットAPI」を参照してく� さい。
リポジトリに暗号化されたシークレットを作成する
ユーザアカウントのリポジトリにシークレットを作成するには、そのリポジトリのオーナーでなければなりません。 Organizationのリポジトリにシークレットを作成するには、管理
アクセス権を持っていなければなりません。
-
your GitHub Enterprise Server instanceで、リポジトリのメインページにアクセスしてく� さい。
-
リポジトリ名の下で Settings(設定)をクリックしてく� さい。
-
左サイドバーで [Secrets] をクリックします。
-
New repository secret(新しいリポジトリのシークレット)をクリックしてく� さい。
-
[Name(名前)] 入力ボックスにシークレットの名前を入力します。
-
シークレットの値を入力します。
-
[Add secret(シークレットの追� )] をクリックします。
リポジトリが親のOrganizationのシークレットにアクセスできるなら、それらのシークレットもこのページにリストされます。
To learn more about GitHub CLI, see "About GitHub CLI."
To add a repository secret, use the gh secret set
subcommand. Replace secret-name
with the name of your secret.
gh secret set secret-name
The CLI will prompt you to enter a secret value. Alternatively, you can read the value of the secret from a file.
gh secret set secret-name < secret.txt
To list all secrets for the repository, use the gh secret list
subcommand.
Organizationの暗号化されたシークレットの作成
Organizationでシークレットを作成する� �合、ポリシーを使用して、そのシークレットにアクセスできるリポジトリを制限できます。 たとえば、すべてのリポジトリにアクセスを許可したり、プライベート リポジトリまたは指定したリポジトリ のリストのみにアクセスを制限したりできます。
Organizationのレベルでシークレットを作成するには、管理
アクセス権を持っていなければなりません。
- your GitHub Enterprise Server instanceで、Organizationのメインページにアクセスしてく� さい。
- Organization 名の下で、クリックします Settings.
-
左サイドバーで [Secrets] をクリックします。
-
New organization secret(新しいOrganizationのシークレット)をクリックしてく� さい。
-
[Name(名前)] 入力ボックスにシークレットの名前を入力します。
-
シークレットの Value(値) を入力します。
-
[ Repository access(リポジトリアクセス) ドロップダウン リストから、アクセス ポリシーを選択します。
-
[Add secret(シークレットの追� )] をクリックします。
Note: By default, GitHub CLI authenticates with the repo
and read:org
scopes. To manage organization secrets, you must additionally authorize the admin:org
scope.
gh auth login --scopes "admin:org"
To add a secret for an organization, use the gh secret set
subcommand with the --org
or -o
flag followed by the organization name.
gh secret set --org organization-name secret-name
By default, the secret is only available to private repositories. To specify that the secret should be available to all repositories within the organization, use the --visibility
or -v
flag.
gh secret set --org organization-name secret-name --visibility all
To specify that the secret should be available to selected repositories within the organization, use the --repos
or -r
flag.
gh secret set --org organization-name secret-name --repos repo-name-1,repo-name-2"
To list all secrets for an organization, use the gh secret list
subcommand with the --org
or -o
flag followed by the organization name.
gh secret list --org organization-name
Organizationレベルのシークレットへのアクセスの確認
Organization内のシークレットに適用されているアクセス ポリシーを確認できます。
- your GitHub Enterprise Server instanceで、Organizationのメインページにアクセスしてく� さい。
- Organization 名の下で、クリックします Settings.
-
左サイドバーで [Secrets] をクリックします。
-
シークレットのリストには、設定済みのアクセス許可とポリシーが含まれます。 例:
-
各シークレットに設定されているアクセス許可の詳細については、[Update(更新)] をクリックしてく� さい。
暗号化されたシークレットのワークフロー内での利用
注釈: GITHUB_TOKEN
を除き、フォークしたリポジトリからワークフローがトリガーされた� �合、シークレットはランナーに渡されません。
アクションに入力あるいは環境変数としてシークレットを提供するには、リポジトリ内に作成したシークレットにアクセスするsecrets
コンテキストを使うことができます。 For more information, see "Contexts" and "Workflow syntax for GitHub Actions."
steps:
- name: Hello world action
with: # Set the secret as an input
super_secret: ${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret: ${{ secrets.SuperSecret }}
可能であれば、コマンドラインからプロセス間でシークレットを渡すのは避けてく� さい。 コマンドラインプロセスは他のユーザから見えるかもしれず(ps
コマンドを使って)、あるいはセキュリティ監査イベントでキャプチャされるかもしれません。 シークレットの保護のために、環境変数、STDIN
、あるいはターゲットのプロセスがサポートしている他の仕組みの利用を考慮してく� さい。
コマンドラインからシークレットを渡さなければならない� �合は、それらを適切なルールでクオート内に収めてく� さい。 シークレットは、意図せずシェルに影響するかもしれない特殊なキャラクターをしばしば含みます。 それらの特殊なキャラクターをエスケープするには、環境変数をクオートで囲ってく� さい。 例:
Bashの利用例
steps:
- shell: bash
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
PowerShellの利用例
steps:
- shell: pwsh
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$env:SUPER_SECRET"
Cmd.exeの利用例
steps:
- shell: cmd
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "%SUPER_SECRET%"
シークレットの制限
You can store up to 1,000 organization secrets and 100 repository secrets.
A workflow created in a repository can access the following number of secrets:
- All 100 repository secrets.
- If the repository is assigned access to more than 100 organization secrets, the workflow can only use the first 100 organization secrets (sorted alphabetically by secret name).
シークレットの容量は最大64 KBです。 64 KBより大きなシークレットを使うには、暗号化されたシークレットをリポジトリ内に保存して、復号化パスフレーズをGitHubに保存します。 たとえば、GitHubのリポジトリにファイルをチェックインする前に、gpg
を使って認証情� �をローカルで暗号化します。 詳しい情� �については、「gpg manpage」を参照してく� さい。
警告: アクションを実行する際、シークレットが出力されないよう注意してく� さい。 この回避策を用いる� �合、GitHubはログに出力されたシークレットを削除しません。
-
ターミナルから以下のコマンドを実行して、
gpg
およびAES256暗号アルゴリズ� を使用してmy_secret.json
ファイルを暗号化します。$ gpg --symmetric --cipher-algo AES256 my_secret.json
-
パスフレーズを入力するよう求められます。 このパスフレーズを覚えておいてく� さい。GitHubで、このパスフレーズを値として用いる新しいシークレットを作成するために必要になります。
-
パスフレーズを含む新しいシークレットを作成します。 たとえば、
LARGE_SECRET_PASSPHRASE
という名前で新しいシークレットを作成し、シークレットの値を上記のステップで選択したパスフレーズに設定します。 -
暗号化したファイルをリポジトリ内にコピーしてコミットします。 この例では、暗号化したファイルは
my_secret.json.gpg
です。 -
パスワードを復号化するシェルスクリプトを作成します。 このファイルを
decrypt_secret.sh
として保存します。#!/bin/sh # ファイルを復号化 mkdir $HOME/secrets # --batchでインタラクティブなコマンドを防ぎ、 # --yes で質問に対して "はい" が返るようにする gpg --quiet --batch --yes --decrypt --passphrase="$LARGE_SECRET_PASSPHRASE" \ --output $HOME/secrets/my_secret.json my_secret.json.gpg
-
リポジトリにチェックインする前に、シェルスクリプトが実行可能であることを確かめてく� さい。
$ chmod +x decrypt_secret.sh $ git add decrypt_secret.sh $ git commit -m "Add new decryption script" $ git push
-
ワークフローから、
step
を使用してシェルスクリプトを呼び出し、シークレットを復号化します。 ワークフローを実行している環境にリポジトリのコピーを作成するには、actions/checkout
アクションを使用する必要があります。 リポジトリのルートを基準としてrun
コマンドを使用し、シェルスクリプトを参照します。name: Workflows with large secrets on: push jobs: my-job: name: My Job runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Decrypt large secret run: ./.github/scripts/decrypt_secret.sh env: LARGE_SECRET_PASSPHRASE: ${{ secrets.LARGE_SECRET_PASSPHRASE }} # このコマンドは、あなたの秘密が印刷されていることを示す例 # シークレットを出力する文は必ず削除してく� さい。 GitHub does # not hide secrets that use this workaround. - name: Test printing your secret (Remove this step in production) run: cat $HOME/secrets/my_secret.json
Storing Base64 binary blobs as secrets
You can use Base64 encoding to store small binary blobs as secrets. You can then reference the secret in your workflow and decode it for use on the runner. For the size limits, see "Limits for secrets".
Note: Note that Base64 only converts binary to text, and is not a substitute for actual encryption.
-
Use
base64
to encode your file into a Base64 string. 例:$ base64 -i cert.der -o cert.base64
-
Create a secret that contains the Base64 string. 例:
$ gh secret set CERTIFICATE_BASE64 < cert.base64 ✓ Set secret CERTIFICATE_BASE64 for octocat/octorepo
-
To access the Base64 string from your runner, pipe the secret to
base64 --decode
. 例:name: Retrieve Base64 secret on: push: branches: [ octo-branch ] jobs: decode-secret: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Retrieve the secret and decode it to a file env: CERTIFICATE_BASE64: ${{ secrets.CERTIFICATE_BASE64 }} run: | echo $CERTIFICATE_BASE64 | base64 --decode > cert.der - name: Show certificate information run: | openssl x509 -in cert.der -inform DER -text -noout