HOMEデベロッパー向け ブログ・コミュニティ SCSK技術者ブログ 第7回：OpenShiftの権限管理を継続改善する：RBAC監査と見直しのポイント
第7回：OpenShiftの権限管理を継続改善する：RBAC監査と見直しのポイント
こんにちは、SCSKの石川です。
これまで技術的な詳細を見てきましたが、今回は運用設計、いわゆる「ガバナンス」の話です。「アプリチームから『権限が足りなくてデプロイできない』と問い合わせが来る」問題に対し、組織としてどう向き合うべきか。OpenShiftチームとアプリチームの役割分担を探ります。
こんにちは、SCSKの石川です。
権限設定は「最初に決めて設定して終わり」ではありません。運用を続けるうちに、一時的に付与した強い権限が放置されたり、退職者のアカウントが残ったりすることはよくあります。
今回は、これらを監査・確認し、「最小権限の原則」を維持し続けるための方法を確認していきます。
シリーズ
- 第1回：OpenShift権限管理入門：ユーザー作成直後の初期権限とプロジェクト作成制御
- 第2回：OpenShiftのAdminロールとは？できること・できないことを実践解説
- 第3回：OpenShiftのClusterRoleBindingとは？Adminロールをクラスタ全体に付与した場合の影響
- 第4回：OpenShiftのcluster-admin権限を解説：RoleBindingとClusterRoleBindingの違い
- 第5回：OpenShiftのカスタムロール設計：最小権限で運用するための作成ポイント
- 第6回：OpenShiftのRBAC設計：チームごとに適切な権限を付与する考え方
- 第7回：OpenShiftの権限管理を継続改善する：RBAC監査と見直しのポイント
目次
- 権限の棚卸しの重要性
- 便利なコマンド：oc adm policy who-can
- OpenShiftの監査ログ（Audit Log）の仕組み
- 実践：oc adm node-logs で監査ログを確認する
- なぜログ収集基盤（Loki等）が必要なのか
- 【実践】全ユーザの権限をリスト化（マトリクス確認）する
- セキュリティプラットフォームの活用（Sysdig Secure）
- シリーズのまとめ
1.権限の棚卸しの重要性
「いつの間にか全員がcluster-adminになっていた」というのは笑えない冗談ですが、トラブル対応のドサクサで権限を付与し、そのまま忘れてしまうケースは実際に起こります。定期的な棚卸しが必要です。
2.便利なコマンド：oc adm policy who-can
複雑なRBACのルールを一つ一つ確認するのは大変です。そこで役立つのが oc adm policy who-can コマンドです。「この操作をできるのは誰か？」を逆引きで教えてくれます。
「誰がSecretを作れるか？」を確認する
例えば、「機密情報（Secret）を作成できるユーザを知りたい」場合、以下のように実行します。
# Secret作成権限を持つユーザ一覧
$ oc adm policy who-can create secret -n ocp-prj02
resourceaccessreviewresponse.authorization.openshift.io/<unknown>
Namespace: ocp-prj02
Verb: create
Resource: secrets
Users: admin
...
Groups: system:cluster-admins
system:masters
このように、RoleやBindingを個別に調べることなく、実効権限を持っているユーザ・グループを一発でリストアップできます。これを定期的に実行し、意図しないユーザが含まれていないかチェックします。
3.OpenShiftの監査ログ（Audit Log）の仕組み
権限設定の状態だけでなく、「実際に誰が何をしたか」を追うには 監査ログ (Audit Log) が必要です。
OpenShiftのAPIサーバは大きく分けて3種類あり、それぞれ個別のファイルに監査ログを出力しています。
| API Server | 内容 | ログファイルのパス (Masterノード) |
|---|---|---|
| kube-apiserver | Kubernetes標準リソース (Pod, Service, ConfigMap等) への操作 | /var/log/kube-apiserver/audit.log |
| openshift-apiserver | OpenShift固有リソース (Project, Route, User, Group等) への操作 | /var/log/openshift-apiserver/audit.log |
| oauth-apiserver | 認証トークンの発行、ログイン成功/失敗などの認証イベント | /var/log/oauth-apiserver/audit.log |
これらを理解していないと、「Projectを作ったログを探しているのに kube-apiserver のログばかり見ていて見つからない」といった事態に陥ります。
4.実践：oc adm node-logs で監査ログを確認する
実環境では、セキュリティ上 SSH でマスターノードにログインすることは推奨されません。
代わりに、oc adm node-logs コマンドを使用して、クライアント端末から安全にログを確認できます。
Kubernetesリソース（Pod作成など）の監査
# 直近の kube-apiserver 監査ログを確認 $ oc adm node-logs --role=master --path=kube-apiserver/audit.log
OpenShiftリソース（User作成など）の監査
「誰がこのユーザを作ったのか？」「誰がProjectを削除したのか？」を調べるにはこちらを見ます。
# 直近の openshift-apiserver 監査ログを確認 $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log
ログ分析の例：不正な権限付与を探す
「誰かが勝手に cluster-admin 権限を付与した」瞬間を探すには、以下のような条件でログ（JSON）を grep します。
- Resource: clusterrolebindings
- Verb: create または update
- ResponseStatus: 201 (Created) または 200 (OK)
# ※ノード上のログはローテートされるため、過去のログは audit-202X...log 等のファイル名で指定する必要があります $ oc adm node-logs --role=master --path=kube-apiserver/audit.log \ | grep "clusterrolebindings" | grep "cluster-admin" | grep -v "system:serviceaccount"
5.なぜログ収集基盤（Loki等）が必要なのか
oc adm node-logs は便利ですが、トラブルシューティングや監査対応としては不十分です。以下の理由から、OpenShift Logging (Cluster Logging Operator) の導入が推奨されます。
- 保存期間と容量の制限: ノード上のログファイルはサイズ上限に達すると古いものから削除（ローテート）されます。数日〜数週間前のログは消失する可能性があります。
- ノード障害時のロスト: マスターノード自体が故障した場合、そのノード内のログも失われます。
- 検索性の低さ: テキスト形式のログを grep するのは非効率で、複雑な条件（「特定ユーザ」かつ「特定期間」かつ「失敗した操作」など）での検索は困難です。
推奨構成：OpenShift Logging + Loki
Red Hatが提供するスタックでは、以下の構成が標準的です。
- Vector (Collector): 各ノードからログを収集・転送
- Loki (Storage): ログを効率的に圧縮・保存（オブジェクトストレージ等へ）
- OpenShift Console / Kibana (UI): ログを可視化・検索
また、企業のセキュリティポリシーで Splunk や Syslogサーバ への転送が義務付けられている場合も、Cluster Logging の「Log Forwarding」機能を使えば転送設定が可能です。
6.【実践】全ユーザの権限をリスト化（マトリクス確認）する
「誰がどのプロジェクトで何の権限を持っているか、一覧（マトリクス）で見たい」
これは、よくある要望ですが、これを一発で表示する単一の oc コマンドは存在しません。
しかし、標準コマンドと jq を組み合わせたワンライナーを使うことで、Excel等で管理しやすいCSV形式のリストを生成することは可能です。
全プロジェクトの権限一覧を出力するワンライナー
以下のコマンドを実行すると、Namespace, RoleBindingName, RoleName, Kind, User/GroupName の形式で出力されます。
Bash / PowerShell (要jqコマンド)
$ oc get rolebindings -A -o json | jq -r '.items[] | .metadata.namespace + "," + .metadata.name + "," + .roleRef.name + "," + (.subjects[]? | .kind + ":" + .name)'
これをファイルに保存すれば、「Aさんがアクセスできる全プロジェクト」や「admin権限を持つ全ユーザ」を簡単にフィルタリングできます。
特定ユーザの権限を詳細確認する
マトリクスで怪しい箇所を見つけたら、そのユーザが具体的に「何の操作（Verb）ができるか」を深掘りします。ここで oc auth can-i --list を使います。
# aliceになりすまして権限一覧を表示 $ oc auth can-i --list --as=alice -n ocp-prj02
これにより、「adminロールを持っているはずなのにPodが消せない」といった設定矛盾や、意図しない権限の持ちすぎを特定できます。
7.セキュリティプラットフォームの活用（Sysdig Secure）
標準コマンドやログ基盤を用いた権限管理は重要ですが、大規模環境や複数クラスタを運用するようになると手動での追跡や定期的なスクリプト実行だけでは限界が来ます。そこで有効なのが、セキュリティプラットフォーム **「Sysdig Secure」**の導入です。
Sysdig Secure は、Kubernetes/OpenShift環境における権限の継続的な管理（CIEM）やセキュリティポスチャ管理（KSPM）を強力にサポートします。
- 過剰な権限の検出と最適化: 実際に使われている権限と付与されている権限のギャップを分析し、「最小権限の原則」に基づいたポリシーを自動提案・適用します。
- ランタイムセキュリティ監視: 監査ログと連携し、特権コンテナの不正な起動や、許可されていないプロセスの実行をリアルタイムに検知・ブロックします。
- コンプライアンスの継続的チェック: 設定ミスや脆弱性がないか（CIS Benchmark等に準拠しているか）を自動でスキャンし続け、監査対応の工数を大幅に削減します。
権限の棚卸しを自動化し、クラスタ全体のセキュリティを統合的に可視化・保護したい場合は、強力な選択肢となります。詳細な機能については、以下のページをご参照ください。
Sysdig Secure クラウド環境を保護するCNAPPツール
https://p--wcqcq9nnj7.re-cotta.com/sp/sysdig/sysdig_secure.html
8.シリーズのまとめ
本シリーズでは、OpenShiftのRBACの基礎から運用・監査までを解説してきました。
- 第1回. 作成直後のユーザ: はほぼ何もできない（プロジェクト作成のみ）。
- 第2回. Adminロール: はプロジェクト内の管理者だが、Quota変更やノード参照はできない。
- 第3回. ClusterRoleBinding: でAdminを付与すると、全プロジェクトの管理者になる。
- 第4回. ローカルcluster-admin: は、Quota変更やSCCを使用できるプロジェクトスーパー管理者。
- 第5回. カスタムロール: は便利だが、Aggregation（集約）機能の扱いに注意。
- 第6回. 権限分界点: は、GitOps等のプロセスを活用してOpenShiftチームの負荷を下げる。
- 第7回. 継続的な監査: は who-can コマンドや Sysdig Secure 等で権限を確認し、ログ基盤 で操作履歴を追跡する。
OpenShiftの権限管理は複雑に見えますが、基本を押さえれば非常に強力で柔軟なセキュリティ制御が可能です。ぜひ、アグレッシブにOpenShiftを活用し倒してください。
