GitHub Actions OIDCカスタムプロパティ実践：エンタープライズ信頼境界の作り方

GitHub Actionsの2026年4月アップデートで注目すべき点は、個別機能よりも「信頼モデルの組み替え」が可能になったことです。OIDCトークンにリポジトリのカスタムプロパティを載せられるようになり、クラウド側の信頼条件を“名前”から“属性”へ移行できます。

参照: https://github.blog/changelog/2026-04-02-github-actions-early-april-2026-updates/

なぜ属性ベースが必要か

従来のrepo名ベース許可は、運用が進むほど破綻します。

• リポジトリ移管や改名でポリシー崩壊
• 例外設定が増え、説明不能なIAMになる
• 監査で「なぜ許可か」を示しにくい

属性ベースなら、組織ルールをそのまま信頼条件にできます。

設計原則

例えば次のような条件を定義します。

• data_class=internal かつ owner_team=platform
• deployment_tier=production かつ control=change-managed
• compliance=sox なら追加制約を要求

これにより、アクセス権が「リポジトリの偶然」ではなく「統制意図」に一致します。

導入手順

1. 組織で使うプロパティ語彙を固定
2. 新規repo作成時に必須プロパティを強制
3. クラウドのOIDC信頼ポリシーに属性を反映
4. 必須属性欠落時はCIを失敗させる
5. 発行トークンのクレーム監査を定期実施

語彙管理を怠ると、属性が増えるほど逆に混乱します。

サービスコンテナ改善の価値

entrypoint/command上書き対応は、地味ですがサプライチェーン健全化に効きます。

• 使い捨てカスタムイメージを減らせる
• YAMLが運用仕様書として読みやすくなる
• パッチ適用面積を小さくできる

パイプライン記述は実行コードであり、監査対象でもあります。

VNETフェイルオーバー運用

セキュアな構成ほど障害時に脆い問題があります。フェイルオーバーは「ある」だけでなく「使える」状態で管理します。

• 主副ネットワークの役割を明文化
• 手動/自動切替条件を文書化
• 負荷時の切替訓練を定期実施
• 切替発生と切替許可を別アラート化

KPI

• 属性ベースOIDC適用率
• repo名ベース信頼ポリシー残存数
• ネットワーク障害時の復旧時間
• OIDC失敗の原因内訳
• 例外設定の平均滞留日数

まとめ

目指すべきは「YAMLを賢く書くこと」ではありません。リポジトリ統制の状態がそのままクラウド権限に反映される、説明可能で保守可能な信頼モデルです。今回の更新は、その移行に使える実務的な節目です。