#devops#ci/cd#security#cloud#platform-engineering#enterprise
Self-hosted Runner最小バージョン強制停止局面の運用設計
「強制停止」は免罪符ではない
self-hosted runner最小バージョンの強制が一時停止されると、現場は「急がなくてよい」と誤解しがちです。しかし実態は逆で、外部が止まった分だけ内部統制の責任が増える状態です。
強制がなくても、runnerは秘密情報・ネットワーク・実行権限の交点にあるため、放置するとセキュリティと可用性を同時に崩します。
まずは資産台帳を作る
最初の1週間で、次を棚卸しします。
- runner group名と責任者
- 稼働環境（prod/stg/dev）
- runnerバージョン・OSイメージ
- 配置形態（VM/K8s/オンプレ）
- 紐づくworkflow群
多くの組織で、誰も責任を持っていない“幽霊runner”が見つかります。
リング展開で安全に更新する
更新は一斉ではなくリングで進めます。
- Ring0: 検証専用
- Ring1: 低重要度repo
- Ring2: 社内プロダクト
- Ring3: 顧客影響・規制対象
昇格条件は、成功率・認証異常有無・キュー遅延を定量化して判定します。
Workflow互換性契約を先に配る
runner更新事故の多くはworkflow側の暗黙依存です。以下を契約として公開します。
- サポートするactionバージョン
- 非推奨パターンと移行期限
- shell/toolchainの前提
- SHA pinning方針
契約なしに更新だけ進めると、組織横断の調整コストが爆増します。
強制停止中でも即実施すべき防御
- 高権限環境では古いrunnerを拒否
- 登録トークンの短寿命化
- 高リスクrepoはephemeral runner化
- runnerサブネットのegress制御
- 長期クラウド鍵を廃しOIDC中心へ
これは外部方針に依存しない普遍的な防御です。
CI基盤SLOを公開する
runner保守を“見えない雑務”にしないため、SLOを持ちます。
- workflow成功率
- queue latency p95
- 目標版との差分日数
- host脆弱性修正MTTR
数値を出すと、更新がコストでなく可用性投資だと説明できます。
まとめ
強制適用停止は「待ち」の合図ではなく、「自律運用に切り替える」合図です。台帳、リング、互換契約を整備し、ポリシーを内製で回せる組織が、次の変更局面でも止まりません。
