简要概述

Kubernetes的RBAC用于控制“谁（Subject）”可以使用Kubernetes的哪些“资源（Resource）”的哪些“操作（Action）”。

RBAC で実現したいことは AWS の IAM と同じです。

以前 「AWS IAMの基本概念を概念モデルで整理した」という記事でまとめたのと同じように Kubernetes の RBAC の概念モデルを作成し、さらに AWS IAM と対比させて整理しました。

结论

关于Kubernetes的RBAC概念模型

整理关于RBAC的概念，可以总结如下。

AWS Identity and Access Management（IAM）与之对比

如果将Kubernetes的RBAC要素与AWS IAM的要素进行对比，可以得出以下结论。

要素ごとの説明

角色和集群角色

Role と ClusterRole には、どのリソース (Resource) のどの 操作 (Action) を利用できるか (Rule) を定義します。
Role と ClusterRole の違いは、Namespace に紐付くか紐付かないかです。

Role与ClusterRole类似于AWS IAM的IAM策略。

角色绑定和集群角色绑定

将由 Role 和 ClusterRole 定义的内容与“某人（主体）”相关联的是 RoleBinding 和 ClusterRoleBinding。

Subject

Subject的绑定方式有三种，分别为RoleBinding、ClusterRoleBinding。

• ServiceAccount

• Group

User

关于 ServiceAccount 将在后面提及。
Group 是将用户归类为一组的概念。
用户是与个人相关联的实体，在 EKS 中与 IAM 进行关联认证。

服务账户

当需要使用Kubernetes API时，ServiceAccount将被使用。通过将ServiceAccount与Pod关联，将自动创建用于从Pod内部访问Kubernetes API的Secret，并将其挂载到Pod上。

当使用 EC2 与 AWS 的 API 进行通信时，与 IAM 角色进行关联相同。

结束时

我以前对于Kubernetes的RBAC和AWS的IAM一直很难理解，但是通过概念模型的总结，我的理解变得更深刻了。

如果有人发现错误，请指出来。