- Published on
GitHub Actions ARC 運用ガイド: Ephemeral Runner、Scale Set、セキュリティ境界
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに
- なぜ ephemeral runner が安全な既定値になりやすいのか
- Scale set は workload と trust boundary で分ける
- セキュリティは runner 本体より周辺境界で決まる
- イメージ戦略は起動速度と清潔性のバランス
- ネットワークとシークレットは最小権限で
- 本番で見るべき指標
- 運用チェックリスト
- よくあるアンチパターン
- まとめ
- References
はじめに
GitHub Actions を組織規模で運用し始めると、self-hosted runner は単なるコスト最適化ではなく、実行隔離とセキュリティ境界の設計対象になります。特に ARC を Kubernetes 上で使うと、重要な問いは次のようになります。
- runner は長寿命にするか、ephemeral にするか
- scale set を workload や trust boundary ごとにどう分けるか
- イメージ、キャッシュ、シークレット、ネットワークをどう分離するか
この記事では GitHub の ARC 公式ドキュメントを基に、運用判断に必要な観点を整理します。
なぜ ephemeral runner が安全な既定値になりやすいのか
長寿命 runner は始めやすい一方で、時間とともに状態が蓄積します。
- 前回 job のファイルが残る
- ツールバージョンが drift する
- 汚染や侵害が長く残る
ephemeral runner は短いライフサイクル後に破棄されるため、次の利点があります。
- job 間隔離が強い
- イメージベースの標準化がしやすい
- 汚染状態を次に引き継ぎにくい
Scale set は workload と trust boundary で分ける
ARC 導入時の典型的な失敗は、すべての保存庫と workload を 1 つの巨大 scale set にまとめることです。管理は単純に見えても、セキュリティ境界と優先度制御が弱くなります。
推奨される分離基準:
- 信頼できないコードと信頼済みコード
- build 系と deploy 系
- 異なるネットワークアクセス要件
例:
| scale set | 用途 | 分離理由 |
|---|---|---|
public-ci | 外部寄稿 PR の検証 | untrusted code を隔離 |
internal-build | 内部 build と test | 制御された package と cache アクセス |
deploy-ops | deployment と運用 workflow | 強い資格情報と承認境界が必要 |
セキュリティは runner 本体より周辺境界で決まる
runner セキュリティはイメージ更新だけでは足りません。重要なのは周辺の実行境界です。
- job が触れられる secret
- Kubernetes service account 権限
- イメージ provenance
- outbound network policy
- cache と artifact 保存境界
特に untrusted pull request 用 runner と deploy credential を持つ runner を同じ境界に置くのは避けるべきです。
イメージ戦略は起動速度と清潔性のバランス
ephemeral runner ではイメージ設計が重要です。空に近すぎると毎回インストールコストがかかり、重すぎると pull が遅くなります。
現実的なバランス:
- 言語ランタイムや共通 build tool はベースイメージへ入れる
- プロジェクト固有依存は cache または workflow で復元する
- runner image のバージョンと rollout 履歴を明確にする
ネットワークとシークレットは最小権限で
ARC runner は CI workload ですが、実際にはかなり強い権限が付きやすい実行環境です。次を推奨します。
- scale set ごとに egress policy を分離する
- cloud credential は deploy runner に限定する
- 単純な test runner は最小権限に保つ
- 可能なら long-lived secret より GitHub OIDC を優先する
本番で見るべき指標
- job queue 待ち時間
- runner 生成時間
- Pod scheduling failure
- image pull 時間
- 失敗 job 後の cleanup 状態
- scale out, scale in の遅延
運用チェックリスト
- untrusted workload と privileged workload が分離されているか
- ephemeral runner が基本パターンか
- runner image バージョンが追跡可能か
- scale set ごとに network policy 境界があるか
- OIDC または最小権限 secret 戦略があるか
よくあるアンチパターン
すべての保存庫を 1 つの runner group に入れる
一見シンプルですが、セキュリティと優先度制御が崩れます。
状態を多く残す長寿命 runner
見かけ上は速くても、drift と汚染のリスクが増えます。
deploy credential と外部 PR 検証を同じ境界で処理する
最も避けたい構成の一つです。
まとめ
ARC 運用の本質は Kubernetes 上で runner を動かす技術ではなく、どの job をどの信頼境界で動かすかという運用モデルです。ephemeral runner、分離された scale set、最小権限のネットワークと secret 戦略がその中心になります。