# GitHub Actions でのシークレットの使用
GitHub Actions ワークフローのリポジトリ、環境、および組織レベルでシークレットを作成する方法について説明します。
## リポジトリのシークレットの作成
GitHub で組織リポジトリのシークレットまたは変数を作成するには、`write` のアクセス権が必要です。 個人アカウントのリポジトリについては、リポジトリコラボレーターである必要があります。
リポジトリ シークレットを追加するには、`gh secret set` サブコマンドを使用します。
`secret-name` をシークレットの名前に置き換えます。
```shell
gh secret set SECRET_NAME
```
CLI によって、シークレット値の入力が求められます。 別の方法として、ファイルからシークレットの値を読み取ることもできます。
```shell
gh secret set SECRET_NAME < secret.txt
```
リポジトリのすべてのシークレットを一覧表示するには、`gh secret list` サブコマンドを使用します。
## 環境のシークレットの生成
個人用アカウントのリポジトリ内の環境でシークレットか変数を作成するユーザーは、そのリポジトリのオーナーである必要があります。 組織用リポジトリ内の環境用にシークレットか変数を作成するユーザーには、`admin` のアクセス権が必要です。 環境の詳細については、「[デプロイメント用の環境管理](/ja/enterprise-server@3.22/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)」を参照してください。
環境のシークレットを追加するには、環境名が後に続く `gh secret set` または `--env` フラグと共に `-e` サブコマンドを使用します。
```shell
gh secret set --env ENV_NAME SECRET_NAME
```
環境のすべてのシークレットを一覧表示するには、環境名が後に続く `gh secret list` または `--env` フラグと共に `-e` サブコマンドを使用します。
```shell
gh secret list --env ENV_NAME
```
## 組織用のシークレットを作成する
Organization でシークレットまたは変数を作成する場合、ポリシーを使用して、リポジトリによるアクセスを制限できます。 たとえば、すべてのリポジトリにアクセスを許可したり、プライベート リポジトリまたは指定したリポジトリ のリストのみにアクセスを制限したりできます。
組織の所有者 および "組織のアクション変数の管理" または "組織のアクション シークレットの管理" アクセス許可を持つユーザーは 組織レベルでシークレットまたは変数を作成できます。
詳細については、 [AUTOTITLE を](/ja/enterprise-server@3.22/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles)参照してください。
> \[!NOTE]
> 既定では、 GitHub CLI は `repo` スコープと `read:org` スコープで認証されます。 組織のシークレットを管理するには、さらに `admin:org` スコープを承認する必要があります。
>
> ```shell
> gh auth login --scopes "admin:org"
> ```
組織のシークレットを追加するには、組織名が後に続く `gh secret set` または `--org` フラグと共に `-o` サブコマンドを使用します。
```shell
gh secret set --org ORG_NAME SECRET_NAME
```
既定では、シークレットはプライベート リポジトリでのみ使用できます。 組織内のすべてのリポジトリでシークレットを使用できるようにするには、`--visibility` または `-v` フラグを使用します。
```shell
gh secret set --org ORG_NAME SECRET_NAME --visibility all
```
組織内の選択したリポジトリでシークレットを使用できるようにするには、`--repos` または `-r` フラグを使用します。
```shell
gh secret set --org ORG_NAME SECRET_NAME --repos REPO-NAME-1, REPO-NAME-2
```
組織のすべてのシークレットを一覧表示するには、組織名が後に続く `gh secret list` または `--org` フラグと共に `-o` サブコマンドを使用します。
```shell
gh secret list --org ORG_NAME
```
## 組織レベルのシークレットへのアクセスの確認
あなたの組織内のシークレットに適用されているアクセス ポリシーを確認することができます。
1. GitHub で、organization のメイン ページに移動します。
2. Organization 名の下で、**\[ Settings]** をクリックします。 \[設定] タブが表示されない場合は、 **\[]** ドロップダウン メニューを選び、 **\[設定]** をクリックします。
![組織のプロファイルのタブのスクリーンショット。 \[設定\] タブが濃いオレンジ色の枠線で囲まれています。](/assets/images/help/discussions/org-settings-global-nav-update.png)
3. サイドバーの \[Security] セクションで、** \[Secrets and variables]** を選んでから、**\[Actions]** をクリックします。
4. シークレットのリストには、設定済みのアクセス許可とポリシーが含まれます。 各シークレットに構成されているアクセス許可について詳しくは、 **\[更新]** をクリックします。
## シークレットのワークフロー内での利用
> \[!NOTE]
>
> * `GITHUB_TOKEN` の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた場合、シークレットはランナーに渡されません。
> * シークレットが再利用可能なワークフローに自動的に渡されることはありません。 詳しくは、「[ワークフローを再利用する](/ja/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#passing-inputs-and-secrets-to-a-reusable-workflow)」をご覧ください。
> * シークレットは、 Dependabot イベントによってトリガーされるワークフローでは使用できません。 詳しくは、「[GitHub Actions での Dependabot のトラブルシューティング](/ja/enterprise-server@3.22/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions#accessing-secrets)」をご覧ください。
> * GitHub Actions ワークフローが OpenID Connect (OIDC) をサポートするクラウド プロバイダーのリソースにアクセスする必要がある場合は、クラウド プロバイダーに対して直接認証するようにワークフローを構成できます。 これにより、有効期間の長いシークレットとしてこれらの資格情報の格納を停止し、その他のセキュリティ上の利点を提供できます。 詳しくは、「[OpenID Connect](/ja/enterprise-server@3.22/actions/concepts/security/openid-connect)」をご覧ください。
> \[!WARNING]
> GitHubを使用して、`::add-mask::VALUE`シークレットではないすべての機密情報をマスクします。 これにより、値がシークレットとして扱われ、ログから編集されます。
アクションに入力あるいは環境変数としてシークレットを提供するには、リポジトリ内に作成したシークレットにアクセスする `secrets` コンテキストを使うことができます。 詳細については、「[コンテキスト リファレンス](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts)」および「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax)」を参照してください。
```yaml
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 }}
```
`if:` 条件でシークレットを直接参照することはできません。 代わりに、シークレットをジョブ レベルの環境変数として設定し、ジョブのステップを条件付きで実行するために環境変数を参照することを検討してください。 詳細については、「[コンテキスト リファレンス](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability)」と [`jobs..steps[*].if`](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsif) を参照してください。
シークレットが設定されていない場合、シークレットを参照する式の戻り値 (例では `${{ secrets.SuperSecret }}` など) は空の文字列になります。
可能であれば、コマンドラインからプロセス間でシークレットを渡すのは避けてください。 コマンドライン プロセスは、他のユーザーに表示される (`ps` コマンドを使用)、または[セキュリティ監査イベント](https://docs.microsoft.com/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing)によってキャプチャされる可能性もあります。 シークレットの保護のために、環境変数、`STDIN`、またはターゲットのプロセスがサポートしている他のメカニズムの利用を検討してください。
コマンドラインから機密情報を渡さなければならない場合は、それらを適切な引用符のルールで囲んでください。 シークレットは、しばしば意図せずシェルに影響を与える可能性のある特殊文字を含みます。 それらの特殊なキャラクターをエスケープするには、環境変数を引用してください。 次に例を示します。
### Bashの利用例
```yaml
steps:
- shell: bash
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
```
### PowerShellの利用例
```yaml
steps:
- shell: pwsh
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$env:SUPER_SECRET"
```
### Cmd.exeの利用例
```yaml
steps:
- shell: cmd
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "%SUPER_SECRET%"
```
## 大きなシークレットを格納する
48 KB を超えるシークレットを使用するには、回避策を使用してリポジトリにシークレットを格納し、復号化パスフレーズをシークレットとして GitHubに保存します。 たとえば、 `gpg` を使用して、暗号化されたファイルを GitHubのリポジトリにチェックインする前に、シークレットを含むファイルをローカルで暗号化できます。 詳細については、「[gpg manpage](https://www.gnupg.org/gph/de/manual/r1023.html)」を参照してください。
> \[!WARNING]
> ワークフローを実行する際、シークレットは出力されないので注意してください。 この回避策を使用する場合、 GitHub はログに出力されるシークレットを編集しません。
1. ターミナルから次のコマンドを実行し、`gpg` と AES256 暗号アルゴリズムを使用してシークレットを含むファイルを暗号化します。 この例では、`my_secret.json` はシークレットを含むファイルです。
```shell
gpg --symmetric --cipher-algo AES256 my_secret.json
```
2. パスフレーズを入力するよう求められます。 パスフレーズを値として使用する新しいシークレットを GitHub に作成する必要があるため、パスフレーズを覚えておいてください。
3. パスフレーズを含む新しいシークレットを作成します。 たとえば、`LARGE_SECRET_PASSPHRASE` という名前で新しいシークレットを作成し、シークレットの値を上記のステップで使用したパスフレーズに設定します。
4. 暗号化したファイルをリポジトリ内のパスにコピーして、コミットします。 この例では、暗号化したファイルは `my_secret.json.gpg` です。
> \[!WARNING]
> 暗号化された`my_secret.json.gpg`ファイルで`.gpg`ファイル拡張子で終わるものをコピーし、暗号化されていない\*\*\*\* ファイルをコピーしないでください。
```shell
git add my_secret.json.gpg
git commit -m "Add new secret JSON file"
```
5. リポジトリ内にシェル スクリプトを作成して、シークレット ファイルの暗号化を解除します。 この例では、スクリプトの名前は `decrypt_secret.sh` です。
```shell copy
#!/bin/sh
# Decrypt the file
mkdir $HOME/secrets
# --batch to prevent interactive command
# --yes to assume "yes" for questions
gpg --quiet --batch --yes --decrypt --passphrase="$LARGE_SECRET_PASSPHRASE" \
--output $HOME/secrets/my_secret.json my_secret.json.gpg
```
6. リポジトリにチェックインする前に、シェルスクリプトが実行可能であることを確かめてください。
```shell
chmod +x decrypt_secret.sh
git add decrypt_secret.sh
git commit -m "Add new decryption script"
git push
```
7. GitHub Actions ワークフローで、`step`を使用してシェル スクリプトを呼び出し、シークレットを復号化します。 ワークフローが実行されている環境でリポジトリのコピーを作成するには、[`actions/checkout`](https://github.com/actions/checkout) アクションを使用する必要があります。 リポジトリのルートを基準として `run` コマンドを使用し、シェル スクリプトを参照します。
```yaml
name: Workflows with large secrets
on: push
jobs:
my-job:
name: My Job
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- name: Decrypt large secret
run: ./decrypt_secret.sh
env:
LARGE_SECRET_PASSPHRASE: ${{ secrets.LARGE_SECRET_PASSPHRASE }}
# This command is just an example to show your secret being printed
# Ensure you remove any print statements of your secrets. 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
```
## Base64 バイナリ BLOB をシークレットとして格納する
Base64 エンコードを使用して、小さなバイナリ BLOB をシークレットとして格納できます。 その後、ワークフロー内のシークレットを参照し、ランナーで使用するためにデコードできます。 サイズの制限については、「[シークレット リファレンス](/ja/enterprise-server@3.22/actions/reference/security/secrets#limits-for-secrets)」を参照してください。
> \[!NOTE]
>
> * Base64 は、バイナリからテキストへの変換だけを実行するもので、実際の暗号化に代わるものではありません。
> * 別のシェルを使用するには、シークレットをファイルにデコードするために異なるコマンドが必要になる場合があります。 Windows ランナーでは、上記のステップでコマンドを使用するために、[](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell) と共に bash シェルを使用することをお勧めします。
1. ファイルを Base64 文字列にエンコードするために `base64` を使用します。 次に例を示します。
MacOS では、次のコマンドを実行できます。
```shell
base64 -i cert.der -o cert.base64
```
Linux では、次のコマンドを実行できます。
```shell
base64 -w 0 cert.der > cert.base64
```
2. Base64 文字列を含むシークレットを作成します。 次に例を示します。
```shell
$ gh secret set CERTIFICATE_BASE64 < cert.base64
✓ Set secret CERTIFICATE_BASE64 for octocat/octorepo
```
3. ランナーから Base64 文字列にアクセスするには、シークレットを `base64 --decode` にパイプします。 次に例を示します。
```yaml
name: Retrieve Base64 secret
on:
push:
branches: [ octo-branch ]
jobs:
decode-secret:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- 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
```
## 次のステップ
参考情報については、「[シークレット リファレンス](/ja/enterprise-server@3.22/actions/reference/security/secrets)」をご覧ください。