OpenShiftの権限管理をわかりやすく　第7回 権限管理が適切かどうかを継続的に確認するにはどうしたらよいか

こんにちは、SCSKの石川です。

権限設定は「最初に決めて設定して終わり」ではありません。運用を続けるうちに、一時的に付与した強い権限が放置されたり、退職者のアカウントが残ったりすることはよくあります。
今回は、これらを監査・確認し、「最小権限の原則」を維持し続けるための方法を確認していきます。

１．権限の棚卸しの重要性

「いつの間にか全員が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種類あり、それぞれ個別のファイルに監査ログを出力しています。

これらを理解していないと、「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作成など）の監査

# 直近の 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)

5．なぜログ収集基盤（Loki等）が必要なのか

oc adm node-logs は便利ですが、トラブルシューティングや監査対応としては不十分です。以下の理由から、OpenShift Logging (Cluster Logging Operator) の導入が推奨されます。

推奨構成：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）を強力にサポートします。

権限の棚卸しを自動化し、クラスタ全体のセキュリティを統合的に可視化・保護したい場合は、強力な選択肢となります。詳細な機能については、以下のページをご参照ください。

Sysdig Secure クラウド環境を保護するCNAPPツール

8．シリーズのまとめ

本シリーズでは、OpenShiftのRBACの基礎から運用・監査までを解説してきました。

OpenShiftの権限管理は複雑に見えますが、基本を押さえれば非常に強力で柔軟なセキュリティ制御が可能です。ぜひ、アグレッシブにOpenShiftを活用し倒してください。