ノート: GitHub Actionsは、GitHub Enterprise Server 2.22で限定ベータとして利用可能でした。 ベータは終了しました。 GitHub Actionsは、GitHub Enterprise Server 3.0以降で一般に利用可能になりました。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。
- GitHub Enterprise Server 3.0以降へのアップグレードに関する詳しい情報については「GitHub Enterprise Serverのアップグレード」を参照してください。
- アップグレード後のGitHub Actionsの設定に関する詳しい情報については、GitHub Enterprise Server 3.0のドキュメンテーションを参照してください。
ノート: 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のリポジトリにシークレットを作成するには、管理
アクセス権を持っていなければなりません。
- GitHub Enterprise Serverで、リポジトリのメインページにアクセスしてください。
- リポジトリ名の下で 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のレベルでシークレットを作成するには、管理
アクセス権を持っていなければなりません。
- GitHub Enterprise Serverで、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内のシークレットに適用されているアクセス ポリシーを確認できます。
- GitHub Enterprise Serverで、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は # この回避先を使うシークレットは隠蔽しません。 - name: Test printing your secret (Remove this step in production) run: cat $HOME/secrets/my_secret.json