Skip to main content

暗号化されたシークレット

暗号化されたシークレットを使うと、機密情報をOrganization、リポジトリ、あるいはリポジトリの環境に保存できます。

暗号化されたシークレットについて

Secrets are encrypted environment variables that you create in an organization, repository, or repository environment. 作成したシークレットは、GitHub Actionsワークフローで利用できます。 GitHubはシークレットがGitHubに到達する前に暗号化され、ワークフローで使用されるまで暗号化されたままになっていることを確実にするのを助けるためにlibsodium sealed boxを使います。

Organizationレベルで保存されたシークレットについては、アクセスポリシーを使ってどのリポジトリがOrganizationのシークレットを利用できる化を制御できます。 Organizationレベルのシークレットを利用すると、複数のリポジトリ間でシークレットを共有できるので、重複してシークレットを作成する必要が軽減されます。 一カ所でOrganizationシークレットを更新すれば、そのシークレットを使うすべてのリポジトリワークフローにその変更が有効になることを保証できます。

環境レベルで保存されたシークレットについては、それらへのアクセスを制御するために必須のレビュー担当者を有効化することができます。 必須の承認者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。

注釈: GitHub ActionsワークフローがOpenID Connect(OIDC)をサポートするクラウドプロバイダからのリソースへのアクセスを必要とするなら、クラウドプロバイダから直接認証を受けるよう、ワークフローを設定できます。 そうすることで、それらの認証情報を長期間使われるシークレットとして保存することを止めることや、その他のセキュリティ上の利点が得られます。 詳しい情報については「OpenID Connectでのセキュリティ強化について」を参照してください。

シークレットに名前を付ける

シークレットの名前には次のルールが適用されます。

  • シークレット名には、英数字([a-z][A-Z][0-9])または下線(_)のみを含めることができます。 スペースは使用できません。

  • シークレット名の最初を GITHUB_ プレフィックスにすることはできません。

  • シークレット名の最初を数字にすることはできません。

  • シークレット名は大文字と小文字を区別しません。

  • シークレット名は、作成されたレベルで一意である必要があります。

    For example, a secret created at the environment level must have a unique name in that environment, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.

    複数のレベルで同じ名前のシークレットが存在する場合、最も低いレベルのシークレットが優先されます。 たとえば、Organization レベルのシークレット名がリポジトリレベルのシークレット名と同じ場合、リポジトリレベルのシークレット名が優先されます。 Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.

GitHub がログのシークレットを確実に削除するよう、シークレットの値として構造化データを使用しないでください。 たとえば、JSONやエンコードされたGit blobを含むシークレットは作成しないでください。

シークレットにアクセスする

シークレットをアクションが使用できるようにするには、ワークフローファイルでシークレットを入力または環境変数に設定する必要があります。 アクションに必要な入力および環境変数については、アクションのREADMEファイルを確認します。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

ファイルを編集するアクセス権を持っていれば、ワークフローファイル中の暗号化されたシークレットを使い、読み取ることができます。 詳細は「GitHub 上のアクセス権限」を参照してください。

警告: GitHubは、ログに出力されたシークレットを自動的に削除しますが、シークレットをログに出力することは意識的に避けなくてはなりません。

Organization及びリポジトリのシークレットはワークフローの実行がキューイングされた時点で読まれ、環境のシークレットは環境を参照しているジョブが開始された時点で読まれます。

REST API を使用してシークレットを管理することもできます。 詳しい情報については、「シークレット」を参照してください。

認証情報のアクセス許可を制限する

クレデンシャルを生成する際には、可能な限り最小限の権限だけを許可することをおすすめします。 たとえば、個人の認証情報を使う代わりに、デプロイキーあるいはサービスアカウントを使ってください。 必要なのが読み取りだけであれば、読み取りのみの権限を許可すること、そしてアクセスをできるかぎり限定することを考慮してください。 個人アクセストークン(PAT)を生成する際には、必要最小限のスコープを選択してください。

Note: You can use the REST API to manage secrets. 詳しい情報については「GitHub ActionsシークレットAPI」を参照してください。

リポジトリに暗号化されたシークレットを作成する

個人アカウントのリポジトリにシークレットを作成するには、リポジトリのオーナーでなければなりません。 Organizationのリポジトリにシークレットを作成するには、管理アクセス権を持っていなければなりません。

  1. GitHub.comで、リポジトリのメインページにアクセスしてください。

  2. リポジトリ名の下で Settings(設定)をクリックしてください。 リポジトリの設定ボタン

  3. 左のサイドバーで Secret(シークレット)をクリックしてください。

  4. New repository secret(新しいリポジトリのシークレット)をクリックしてください。

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

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

  7. [Add secret(シークレットの追加)] をクリックします。

If your repository has environment secrets or can access secrets from the parent organization, then those secrets are also listed on this page.

GitHub CLIについてさらに学ぶには、「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リポジトリ内の環境にシークレットを作成するには、adminアクセス権を持っていなければなりません。

  1. GitHub.comで、リポジトリのメインページにアクセスしてください。
  2. リポジトリ名の下で Settings(設定)をクリックしてください。 リポジトリの設定ボタン
  3. 左のサイドバーで Environments(環境)をクリックしてください。
  4. シークレットを追加したい環境をクリックしてください。
  5. Environment secrets(環境のシークレット)の下で、Add secret(シークレットの追加)をクリックしてください。
  6. [Name(名前)] 入力ボックスにシークレットの名前を入力します。
  7. シークレットの値を入力します。
  8. [Add secret(シークレットの追加)] をクリックします。

To add a secret for an environment, use the gh secret set subcommand with the --env or -e flag followed by the environment name.

gh secret set --env environment-name secret-name

To list all secrets for an environment, use the gh secret list subcommand with the --env or -e flag followed by the environment name.

gh secret list --env environment-name

Organizationの暗号化されたシークレットの作成

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

Organizationのレベルでシークレットを作成するには、管理アクセス権を持っていなければなりません。

  1. GitHub.comで、Organizationのメインページにアクセスしてください。
  2. Organization 名の下で、クリックします Settings. Organizationの設定ボタン
  1. 左のサイドバーで Secret(シークレット)をクリックしてください。

  2. New organization secret(新しいOrganizationのシークレット)をクリックしてください。

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

  4. シークレットの Value(値) を入力します。

  5. [ Repository access(リポジトリアクセス) ドロップダウン リストから、アクセス ポリシーを選択します。

  6. [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内のシークレットに適用されているアクセス ポリシーを確認できます。

  1. GitHub.comで、Organizationのメインページにアクセスしてください。
  2. Organization 名の下で、クリックします Settings. Organizationの設定ボタン
  1. 左のサイドバーで Secret(シークレット)をクリックしてください。

  2. シークレットのリストには、設定済みのアクセス許可とポリシーが含まれます。 例: シークレットリスト

  3. 各シークレットに設定されているアクセス許可の詳細については、[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 }}

Secrets cannot be directly referenced in if: conditionals. Instead, consider setting secrets as job-level environment variables, then referencing the environment variables to conditionally run steps in the job. For more information, see "Context availability" and jobs.<job_id>.steps[*].if.

If a secret has not been set, the return value of an expression referencing the secret (such as ${{ secrets.SuperSecret }} in the example) will be an empty string.

可能であれば、コマンドラインからプロセス間でシークレットを渡すのは避けてください。 コマンドラインプロセスは他のユーザから見えるかもしれず(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, 100 repository secrets, and 100 environment 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).
  • All 100 environment secrets.

シークレットの容量は最大64 KBです。 To store larger secrets, see the "Storing large secrets" workaround below.

Storing large secrets

To use secrets that are larger than 64 KB, you can use a workaround to store encrypted secrets in your repository and save the decryption passphrase as a secret on GitHub. For example, you can use gpg to encrypt a file containing your secret locally before checking the encrypted file in to your repository on GitHub. 詳しい情報については、「gpg manpage」を参照してください。

Warning: Be careful that your secrets do not get printed when your workflow runs. この回避策を用いる場合、GitHubはログに出力されたシークレットを削除しません。

  1. Run the following command from your terminal to encrypt the file containing your secret using gpg and the AES256 cipher algorithm. In this example, my_secret.json is the file containing the secret.

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

  3. パスフレーズを含む新しいシークレットを作成します。 For example, create a new secret with the name LARGE_SECRET_PASSPHRASE and set the value of the secret to the passphrase you used in the step above.

  4. Copy your encrypted file to a path in your repository and commit it. この例では、暗号化したファイルはmy_secret.json.gpgです。

    Warning: Make sure to copy the encrypted my_secret.json.gpg file ending with the .gpg file extension, and not the unencrypted my_secret.json file.

    git add my_secret.json.gpg
    git commit -m "Add new encrypted secret JSON file"
    
  5. Create a shell script in your repository to decrypt the secret file. In this example, the script is named decrypt_secret.sh.

    #!/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. In your GitHub Actions workflow, use a step to call the shell script and decrypt the secret. ワークフローを実行している環境にリポジトリのコピーを作成するには、actions/checkoutアクションを使用する必要があります。 リポジトリのルートを基準として、runコマンドを使用することで、シェルスクリプトを参照します。

    name: Workflows with large secrets
    
    on: push
    
    jobs:
      my-job:
        name: My Job
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v3
          - 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
    

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.

  1. Use base64 to encode your file into a Base64 string. 例:

    $ base64 -i cert.der -o cert.base64
    
  2. Create a secret that contains the Base64 string. 例:

    $ gh secret set CERTIFICATE_BASE64 < cert.base64
    ✓ Set secret CERTIFICATE_BASE64 for octocat/octorepo
    
  3. 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@v3
          - 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