01
namespaceを明示する
オフライン解析のRoleとRoleBindingにはmetadata.namespaceが必要です。RoleBindingからClusterRoleを参照しても、そのnamespace外には広がりません。
Kubernetes
Kubernetes RBAC可視化誰に何が付与されたかを追跡
Role、ClusterRoleとBindingのマニフェストを貼り付け、揃ってから解析します。
Kubernetes RBAC可視化
関係と検出結果
RBACマニフェストを貼り付けて解析します。
入力はこのブラウザー内で処理し、クラスター接続やネットワーク送信をしません。
付与を照合
* はクラスター範囲。関係図だけ見る場合は照合欄を空にします。
マニフェストを貼り付けてください。
Roleだけを見ると、実際に誰へ付与されたかが分かりません。Kubernetes RBAC可視化は主体、Binding、Role、ルールをつなぎ、レビュー中の権限の出所を明らかにします。
Kubernetes RBAC可視化が読むのは貼り付けたマニフェストだけです。既定ロール、実際のグループ所属、他の認可方式は見えないため、不足する根拠を区別して表示します。
Kubernetes RBAC可視化を使う理由
付与経路と判断できない範囲を同時に示します。
付与の出所をたどれる
RBAC権限確認ではUser、Group、ServiceAccountからBindingとルールまで表示します。ClusterRoleを参照していてもRoleBindingの許可はそのnamespaceだけです。
広い権限にも根拠を添える
ワイルドカード、Secretsの広い読み取り、権限昇格の動詞を、実際のBindingとともに表示します。参照先がないRoleや集約Roleは不完全な資料として扱います。
一致を見る前に範囲を確認
02
主体を正確に選ぶ
User、Group、ServiceAccountは別の主体です。名前が同じでもServiceAccountのnamespaceが違えば別々に表示し、UserのGroup所属は推測しません。
03
名前制限を読む
resourceNamesを持つルールはリソース名を入力してください。list/watchにはさらに一致するfield selectorが必要ですが、ここではその実リクエストを検証できません。
経路、条件、警告を一つの結果に
選択できる関係図
RoleBindingの権限から主体→Binding→Role→ルールを表示します。ノードを選ぶと関連する経路に絞れ、API groupと適用範囲も残ります。 ロールの可視化で参照元を追えます。
リソースと動詞の照合
主体、namespace、API group、リソースまたはサブリソース、動詞、任意の名前を指定して、入力内のルールを検索します。podsとpods/execは別物です。
出所付きの監査メモ
Kubernetes RBAC可視化のMarkdownにはSecrets、通配指定、bind・escalate・impersonateなどの確認点と、その根拠となるBindingを残します。
マニフェストだけで分かる限界
- 本番の許否は確定しない
- Kubernetes RBAC可視化はクラスターへ接続せず、SubjectAccessReviewも実行しません。入力に一致がなくても、実際のAPIでForbiddenになるとは限りません。
- 欠けた参照を補完しない
- 参照先Roleや集約ClusterRoleの構成員が足りない場合は不完全と表示します。UserがどのGroupに入るかもユーザー名から判断しません。
- 非リソースURLは対象外
- nonResourceURLsは未評価として残します。カスタムリソースの実スコープを検出したり、ポリシーを生成・適用したり、podsをpods/execと同一視したりしません。
Kubernetes RBAC可視化のよくある質問
RoleBindingで一つのnamespaceにアクセスできても、全namespaceでは失敗するのはなぜ？
RoleBindingはClusterRoleを参照しても、そのBindingのnamespaceでのみ権限を付与します。全体に付与するにはClusterRoleBindingが必要です。
一つのServiceAccountに複数のRoleBindingを付けられますか？
付けられます。RBACの許可は加算されます。結果は勝者を一つ選ばず、各Bindingを別々の出所として表示します。
Secretsのlistがあれば内容も読めますか？
listの応答にSecretオブジェクトとデータが含まれる場合があります。単体のgetがなくても注意が必要です。resourceNamesの制限があればlist/watchにはfield selectorも関係します。
別namespaceのServiceAccountがSecretを読むことはできますか？
対象namespaceのRoleBindingが別namespaceのServiceAccountを参照できます。主体のnamespaceを明示すれば、同名の別アカウントとの混同を防げます。
Kubernetes RBACに明示的な拒否ルールはありますか？
ありません。RBACは許可を加える方式です。このページは入力にある付与経路を示しますが、実クラスターの最終判定までは示せません。
まだ疑問がありますか？