概要
Kubernetes の RBAC は、「誰が (Subject) 」が Kubernetes のどの「リソース (Resource) 」のどの「操作 (Action) 」を利用可能かを制御します。
RBAC で実現したいことは AWS の IAM と同じです。
以前 「AWS IAMの基本概念を概念モデルで整理した」という記事でまとめたのと同じように Kubernetes の RBAC の概念モデルを作成し、さらに AWS IAM と対比させて整理しました。
結論
Kubernetes の RBAC に関する概念モデル
RBAC に関する概念をまとめると以下のようになりました。
AWS IAM との対比
Kubernetes の RBAC の要素と AWS IAM の要素を対比させると、以下のようになります。
Kubernetes RBAC | AWS IAM |
---|---|
Role, ClusterRole | IAM Policy |
RoleBinding, ClusterRoleBinding | IAM Policy Attachment |
ServiceAccount | IAM Role |
Group | IAM Group |
User | IAM User |
要素ごとの説明
Role と ClusterRole
Role と ClusterRole には、どのリソース (Resource) のどの 操作 (Action) を利用できるか (Rule) を定義します。
Role と ClusterRole の違いは、Namespace に紐付くか紐付かないかです。
Role と ClusterRole は AWS IAM の IAM Policy のようなものです。
Kubernetes RBAC | AWS IAM |
---|---|
Role, ClusterRole | IAM Policy |
RoleBinding と ClusterRoleBinding
Role、ClusterRole で定義した内容を「誰か (Subject) 」に紐付けるのが RoleBinding と ClusterRoleBinding です。
Kubernetes RBAC | AWS IAM |
---|---|
RoleBinding, ClusterRoleBinding | IAM Policy Attachment |
Subject
RoleBinding、ClusterRoleBindingによる紐付け先 (Subject) は3種類あります。
- ServiceAccount
- Group
- User
ServiceAccount については後述します。
Group は User をまとめたものです。
User は人に紐付くもので、EKS であれば IAM と紐付いた認証となります。
Kubernetes RBAC | AWS IAM |
---|---|
ServiceAccount | IAM Role |
Group | IAM Group |
User | IAM User |
ServiceAccount
ServiceAccount は、Pod から Kubernetes の API を使いたいときに利用します。
ServiceAccount を Pod に紐づけることで、Pod 内から Kubernetes の API にアクセスするためのSecret が自動的に作成され、Podにマウントされます。
EC2 から AWS の API を利用する際に IAM Role を紐付けるのと同じです。
おわりに
Kubernetes の RBAC も AWS IAM もなかなか理解できずにいたのですが、概念モデルでまとめることで理解が深まりました。
もし間違いに気付かれた方はご指摘お願いします。