OpenShiftの権限管理をわかりやすく　第6回 結局、各チームにはどのような権限を渡すのがよいか

1. よくある「権限足りない」問合せトップ3

OpenShift運用で頻出する権限エラーは主に以下の3つです。

1. 「rootユーザで動かしたいのにErrorになる」: (SCC制限)
2. 「Operatorを入れたいのに権限がない」: (CRD作成権限不足)
3. 「他プロジェクトのイメージをPullしたい」: (RoleBinding不足)

これらは通常の admin 権限では解決できません。

2. 問い合わせ1：特権コンテナとSCC（AnyUIDなど）

OpenShiftはデフォルトでroot実行を禁止しています。
これを回避するには anyuid などのSCC（Security Context Constraints）をServiceAccountに付与する必要がありますが、この「SCCを付与する権限」は cluster-admin レベルが必要です。
アプリチームに cluster-admin を渡すわけにはいきません。どうすればよいでしょうか。

3. 問い合わせ2：OperatorのインストールとCRD

「便利なDBのOperatorを入れたい」という要望も多いです。しかし、Operatorの導入にはCRD（Custom Resource Definition）の作成が伴うことが多く、CRDはクラスタ全体のリソースであるため、プロジェクト管理者には作成権限がありません。加えて、OpenShiftではOperatorHub経由でのインストールが標準ですが、この Subscription や OperatorGroup の構成もクラスタレベルの操作を伴うため、アプリチーム単独では完結できません。

4. 問い合わせ3：他プロジェクトのイメージPull

マイクロサービス化が進むと、「別のプロジェクトでビルドしたイメージを、自分のプロジェクトからPullして使いたい」という要件が発生します。
しかし、OpenShiftはプロジェクト間のリソースアクセスを厳格に遮断しています。これを解決するには、イメージを提供する側のプロジェクトで、利用する側のServiceAccountに対して system:image-puller というロールをRoleBindingで付与する必要があります。これも、別プロジェクトをまたぐ操作となるため、通常の単一プロジェクトの admin 権限だけでは完結しない、相手側プロジェクトの管理者の協力が必要なパターンです。

5. 解決策A：OpenShiftチームが作業代行する（チケット制）

最も堅実な方法は、これら「Admin権限を超える操作」をOpenShiftチームへの申請ベースにすることです。

• SCC: アプリチームは「ServiceAccount名」を申請 → OpenShiftチームが oc adm policy add-scc-to-user を実行。
• Operator: OpenShiftチームが導入し、アプリチームには利用権限だけを渡す。

セキュリティは担保されますが、OpenShiftチームの負荷が高まり、開発スピードが落ちるのが欠点です。

6. 解決策B：一時的特権付与

「チケット対応を待っていられない」という開発スピードの課題を解決するため、アプリチームに対してアプリのデプロイ期間など必要な時だけ一時的に強い権限を渡し、作業後に剥奪するというアプローチです。
メリットは、平時の権限を最小化（アタックサーフェスを限定）しつつ、作業時の柔軟性とスピードを担保できる点です。
注意点としては、OpenShiftの標準RBACには「3時間後に権限を自動消去する（有効期限）」という機能がないため必ず手動で権限を剥奪する必要があります。しかし、「作業終了後の権限剥奪忘れ」が発生し、なし崩し的に特権が放置される重大なインシデントに繋がります。また、トラブルシューティングのたびに権限の再申請が必要になり、復旧が遅れる原因にもなります。

7. 解決策C：GitOpsによる権限の抽象化

解決策Bの「手動での剥奪もれ」という致命的なリスクをシステムで解決し、スピードとガバナンスを両立させるモダンなアプローチが、 ArgoCD (OpenShift GitOps) の活用です。

• ArgoCD自体には強い権限（cluster-admin相当）を持たせておきます。
• アプリチームは、Gitリポジトリに「必要なSCC設定」や「RoleBinding」を書いたマニフェストをCommitします。
• OpenShiftチームはGit上でそのPull Requestをレビュー・承認します。
• Mergeされると、ArgoCDが自動的に設定をクラスタに反映します。

この方法であれば、アプリチームに直接強い権限を渡すことなく、かつOpenShiftチームの手作業（コマンド実行）も不要になります。「権限」ではなく「承認プロセス」で統制するアプローチです。ただし、本アプローチを採用する場合、OpenShift上の権限管理が楽になる代わりに、『Gitリポジトリのアクセス権限（誰がMergeできるか）とブランチ保護ルール』が、システム全体のセキュリティを担保する新たな防波堤になります。Gitの運用統制とセットで設計することが重要です。

8. 権限分界点のモデルケース例

GitOps（解決策C）の導入を前提とした場合、OpenShift上の権限は以下のようにシンプルにすることができます。

(※) 特権SCC利用は、解決策C（GitOps）や専用のServiceAccount払い出しフローで対応する。

9. まとめ

「なんでもできる権限を渡す」のは簡単ですが、マルチテナント環境の崩壊に直結します。
基本は 「Namespaceの中に閉じた権限（admin/edit）」 を原則とし、そこからはみ出る要件（SCC, Operator, Quota等）については、人間に一時的な権限を付与して頑張るのではなく、GitOpsなどの 「プロセスとシステム」 に権限を委譲して解決するのが、エンタープライズにおける最善の策と言えます。

次回はいよいよ最終回、権限管理の継続的な見直しについて確認していきます。