Skip to main content

GitHub Actions でのシークレットの使用

リポジトリ、環境、organization のレベルで GitHub Actions ワークフロー用のシークレットを作成する方法について説明します。

Tool navigation

リポジトリのシークレットの作成

GitHub で組織リポジトリのシークレットまたは変数を作成するには、write のアクセス権が必要です。 個人アカウントのリポジトリについては、リポジトリコラボレーターである必要があります。

  1. GitHub で、リポジトリのメイン ページに移動します。

  2. リポジトリ名の下にある [Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. サイドバーの [Security] セクションで、 [Secrets and variables] を選んでから、[Actions] をクリックします。

  4. [シークレット] タブをクリックします。 「アクションのシークレットと変数」ページの

     スクリーンショット。 [シークレット] タブが濃いオレンジ色の枠線で囲まれています。

  5. [新しいリポジトリ シークレット] をクリックします。

  6. "名前" フィールドで、コンテナーの名前を入力します。

  7. "シークレット" フィールドで、シークレットの値を入力します。

  8. [シークレットの追加] をクリックします。

リポジトリに環境シークレットがある場合、またはリポジトリが親組織のシークレットにアクセスできる場合、そのシークレットもこのページに表示されます。

リポジトリ シークレットを追加するには、gh secret set サブコマンドを使用します。 secret-name をシークレットの名前に置き換えます。

gh secret set SECRET_NAME

CLI によって、シークレット値の入力が求められます。 別の方法として、ファイルからシークレットの値を読み取ることもできます。

gh secret set SECRET_NAME < secret.txt

リポジトリのすべてのシークレットを一覧表示するには、gh secret list サブコマンドを使用します。

環境のシークレットの生成

個人用アカウントのリポジトリ内の環境でシークレットか変数を作成するユーザーは、そのリポジトリのオーナーである必要があります。 組織用リポジトリ内の環境用にシークレットか変数を作成するユーザーには、admin のアクセス権が必要です。 環境の詳細については、「デプロイに環境の使用」を参照してください。

  1. GitHub で、リポジトリのメイン ページに移動します。

  2. リポジトリ名の下にある [Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. 左側のサイドバーで、 [環境] をクリックします。

  4. シークレットを追加したい環境をクリックしてください。

  5. [環境シークレット] で、 [シークレットの追加] をクリックします。

  6. [名前] 入力ボックスにシークレットの名前を入力します。

  7. シークレットの値を入力します。

  8. [シークレットの追加] をクリックします。

環境のシークレットを追加するには、環境名が後に続く --env または -e フラグと共に gh secret set サブコマンドを使用します。

gh secret set --env ENV_NAME SECRET_NAME

環境のすべてのシークレットを一覧表示するには、環境名が後に続く --env または -e フラグと共に gh secret list サブコマンドを使用します。

gh secret list --env ENV_NAME

Organization にシークレットを作成する

メモ

organization レベルのシークレットと変数には、GitHub Free のプライベート リポジトリからはアクセスできません。 GitHub サブスクリプションのアップグレードの詳細については、「アカウントのプランをアップグレードする」を参照してください。

Organization でシークレットまたは変数を作成する場合、ポリシーを使用して、リポジトリによるアクセスを制限できます。 たとえば、すべてのリポジトリにアクセスを許可したり、プライベート リポジトリまたは指定したリポジトリ のリストのみにアクセスを制限したりできます。

Organization のオーナーは、Organization レベルでシークレットまたは変数を作成できます。

  1. GitHub で、organization のメイン ページに移動します。

  2. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  3. サイドバーの [Security] セクションで、 [Secrets and variables] を選んでから、[Actions] をクリックします。

  4. [シークレット] タブをクリックします。

    [アクション シークレットと変数] ページのスクリーンショット。 [シークレット] タブが濃いオレンジ色の枠線で囲まれています。

  5. [新しい組織シークレット] をクリックします。

  6. [名前] 入力ボックスにシークレットの名前を入力します。

  7. シークレットの [値] を入力します。

  8. [リポジトリアクセス] ドロップダウンリストから、アクセスポリシーを選びます。

  9. [シークレットの追加] をクリックします。

メモ

既定では、GitHub CLI は、reporead:org スコープで認証されます。 組織のシークレットを管理するには、さらに admin:org スコープを承認する必要があります。

gh auth login --scopes "admin:org"

組織のシークレットを追加するには、組織名が後に続く --org または -o フラグと共に gh secret set サブコマンドを使用します。

gh secret set --org ORG_NAME SECRET_NAME

既定では、シークレットはプライベート リポジトリでのみ使用できます。 組織内のすべてのリポジトリでシークレットを使用できるようにするには、--visibility または -v フラグを使用します。

gh secret set --org ORG_NAME SECRET_NAME --visibility all

組織内の選択したリポジトリでシークレットを使用できるようにするには、--repos または -r フラグを使用します。

gh secret set --org ORG_NAME SECRET_NAME --repos REPO-NAME-1, REPO-NAME-2

組織のすべてのシークレットを一覧表示するには、組織名が後に続く --org または -o フラグと共に gh secret list サブコマンドを使用します。

gh secret list --org ORG_NAME

Organizationレベルのシークレットへのアクセスの確認

Organization内のシークレットに適用されているアクセス ポリシーを確認できます。

  1. GitHub で、organization のメイン ページに移動します。

  2. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  3. サイドバーの [Security] セクションで、 [Secrets and variables] を選んでから、[Actions] をクリックします。

  4. シークレットのリストには、設定済みのアクセス許可とポリシーが含まれます。 各シークレットに構成されているアクセス許可について詳しくは、 [更新] をクリックします。

シークレットのワークフロー内での利用

メモ

  • GITHUB_TOKEN の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた場合、シークレットはランナーに渡されません。
  • シークレットが再利用可能なワークフローに自動的に渡されることはありません。 詳しくは、「ワークフローを再利用する」をご覧ください。
  • シークレットは、Dependabot イベントによってトリガーされたワークフローでは使用できません。 詳しくは、「GitHub Actions の Dependabot のトラブルシューティング」をご覧ください。
  • GitHub Actions ワークフローが OpenID Connect (OIDC) をサポートするクラウド プロバイダーのリソースにアクセスする必要がある場合、そのクラウド プロバイダーで直接認証されるようにワークフローを構成できます。 これにより、有効期間の長いシークレットとしてこれらの資格情報の格納を停止し、その他のセキュリティ上の利点を提供できます。 詳しくは、「OpenID Connect」をご覧ください。

警告

::add-mask::VALUE を使って、GitHub シークレットではないすべての機密情報をマスクします。 これにより、値がシークレットとして扱われ、ログから編集されます。

アクションに入力あるいは環境変数としてシークレットを提供するには、リポジトリ内に作成したシークレットにアクセスする secrets コンテキストを使うことができます。 詳細については、「コンテキスト リファレンス」および「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 }}

if: 条件でシークレットを直接参照することはできません。 代わりに、シークレットをジョブ レベルの環境変数として設定し、ジョブのステップを条件付きで実行するために環境変数を参照することを検討してください。 詳細については、「コンテキスト リファレンス」と jobs.<job_id>.steps[*].if を参照してください。

シークレットが設定されていない場合、シークレットを参照する式の戻り値 (例では ${{ 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%"

大きなシークレットを格納する

48 KB より大きなシークレットを使うには、シークレットをリポジトリ内に保存して、暗号化解除パスフレーズを GitHub のシークレットとして保存するという回避策を使用できます。 たとえば、GitHub のリポジトリに暗号化されたファイルをチェックインする前に、gpg を使ってシークレットを含むファイルをローカルで暗号化できます。 詳細については、「gpg manpage」を参照してください。

警告

ワークフローを実行する際、シークレットは出力されないので注意してください。 この回避策を用いる場合、GitHubはログに出力されたシークレットを削除しません。

  1. ターミナルから次のコマンドを実行し、gpg と AES256 暗号アルゴリズムを使用してシークレットを含むファイルを暗号化します。 この例では、my_secret.json はシークレットを含むファイルです。

    gpg --symmetric --cipher-algo AES256 my_secret.json
    
  2. パスフレーズを入力するよう求められます。 このパスフレーズを覚えておいてください。GitHubで、このパスフレーズを値として用いる新しいシークレットを作成するために必要になります。

  3. パスフレーズを含む新しいシークレットを作成します。 たとえば、LARGE_SECRET_PASSPHRASE という名前で新しいシークレットを作成し、シークレットの値を上記のステップで使用したパスフレーズに設定します。

  4. 暗号化したファイルをリポジトリ内のパスにコピーして、コミットします。 この例では、暗号化したファイルは my_secret.json.gpg です。

    警告

    暗号化されていない my_secret.json ファイルではなく.gpg ファイル拡張子で終わる暗号化された my_secret.json.gpg ファイルを必ずコピーしてください。

    git add my_secret.json.gpg
    git commit -m "Add new secret JSON file"
    
  5. リポジトリ内にシェル スクリプトを作成して、シークレット ファイルの暗号化を解除します。 この例では、スクリプトの名前は decrypt_secret.sh です。

    Shell
    #!/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. リポジトリにチェックインする前に、シェルスクリプトが実行可能であることを確かめてください。

    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 アクションを使用する必要があります。 リポジトリのルートを基準として run コマンドを使用し、シェル スクリプトを参照します。

    name: Workflows with large secrets
    
    on: push
    
    jobs:
      my-job:
        name: My Job
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v5
          - 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 をシークレットとして格納できます。 その後、ワークフロー内のシークレットを参照し、ランナーで使用するためにデコードできます。 サイズの制限については、「GitHub Actions でのシークレットの使用」を参照してください。

メモ

  • Base64 は、バイナリからテキストへの変換だけを実行するもので、実際の暗号化に代わるものではありません。
  • 別のシェルを使用するには、シークレットをファイルにデコードするために異なるコマンドが必要になる場合があります。 Windows ランナーでは、上記の run ステップでコマンドを使用するために、shell: bash により bash シェルを使用することをお勧めします。
  1. ファイルを Base64 文字列にエンコードするために base64 を使用します。 次に例を示します。

    MacOS では、次のコマンドを実行できます。

    base64 -i cert.der -o cert.base64
    

    Linux では、次のコマンドを実行できます。

    base64 -w 0 cert.der > cert.base64
    
  2. Base64 文字列を含むシークレットを作成します。 次に例を示します。

    $ gh secret set CERTIFICATE_BASE64 < cert.base64
    ✓ Set secret CERTIFICATE_BASE64 for octocat/octorepo
    
  3. ランナーから Base64 文字列にアクセスするには、シークレットを base64 --decode にパイプします。 次に例を示します。

    name: Retrieve Base64 secret
    on:
      push:
        branches: [ octo-branch ]
    jobs:
      decode-secret:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v5
          - 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
    

次のステップ

参考情報については、「シークレット リファレンス」をご覧ください。