#devops#ci/cd#security#identity#cloud
GitHub OIDCをレジストリ連携まで拡張する: エンタープライズ実装ガイド
GitHub Changelogで進んでいるOIDC関連更新は、単なるクラウドログイン改善ではありません。CI/CDにおける機械ID管理を、固定秘密鍵からクレームベースへ移す流れが本格化しています。
多くの組織はOIDCを「クラウド認証だけ」に使っていますが、本来はレジストリ公開、内部配布、昇格処理まで含めて統一することで効果が出ます。
いま残っている“固定シークレット負債”
現場で残りやすいのは次の領域です。
- プライベートレジストリのpublish/install
- 内部artifactの受け渡し
- 環境昇格ツール
- 横断自動化ボット
これらのシークレットは複製され、実体把握が難しく、漏えい時の影響範囲が読みにくくなります。
リポジトリ名依存からクレーム評価へ
OIDCでは、repo名だけでなく複数属性で信頼判断できます。
- org / repo / environment
- workflow ref / event種別
- runner情報
- 組織カスタムプロパティ（リスク区分、準拠区分、責任部署）
たとえば、
risk:lowのみpreview公開許可- 本番昇格は
compliance:approvedかつ保護ブランチ起点のみ許可
のような運用が可能です。
推奨アーキテクチャ
- ワークフローごとに短命OIDCトークン発行
- ポリシーエンジンでクレーム評価
- 必要最小権限の下流資格情報を払い出し
- 特権操作にトレースメタデータ付与
- 失効はシークレットローテではなくポリシー変更で実施
この形にすると、事故時の対応が“全置換作業”ではなく“ルール修正”になります。
固定シークレットからの移行手順
1. 棚卸し
- CIシークレットを用途と権限で一覧化
- シークレット単位でブラスト半径を可視化
- 置換難易度で分類
2. 並行運用
- OIDC経路を先に作り、既存シークレットは一時温存
- 成功率と遅延を比較
- fallback発生理由を記録
3. 強制切替
- 対象ワークフローで固定シークレットを無効化
- 緊急用break-glass経路は承認付きで限定運用
- クレーム逸脱を検知するポリシーテストをCIへ追加
4. 統制運用
- 月次で信頼ポリシー見直し
- federated workflowに責任者メタデータを必須化
- 監査証跡を自動エクスポート
失敗しやすいポイント
aud受け入れ範囲が広すぎる- ブランチ参照をワイルドカード許可
- 本番権限と環境情報の未バインド
- リプレイ耐性不足
- 拒否理由が不明瞭で開発者が迂回
拒否ログが読めないと、現場は安全経路を使わなくなります。
KPIとして追うべき指標
- 特権操作に占めるOIDC利用率
- 固定シークレット数の四半期推移
- ポリシー拒否率と主要理由
- 信頼設定ミスからの復旧時間
- クレーム評価で防止した不正試行数
数値化されて初めて、改善が継続します。
まとめ
GitHub OIDCは「便利なログイン機能」ではなく、CI/CD統制の基盤です。クレーム、カスタムプロパティ、ポリシー自動化を接続できれば、機密リスクを下げながらデリバリー速度も上げられます。
