K8S RBAC 使用一则

绿蚁新醅酒，红泥小火炉。
晚来天欲雪，能饮一杯无？
                                              —— 《问刘十九》

越深入地接触程序世界，越体会到其对现实世界运行规则的借鉴、揭示与模拟，建筑工程是软件构建直接借鉴的领域，而生物界则蕴含着演化得最完善的规则，生态圈、生物个体、细胞之间的组成和交互，和互联网、app、进程、线程、函数、属性如此相像，结构与信息，形式/结构决定功能，最常见的 null 问题在某种程度上表明人对物质底层的存在本质还没有一个确定的逻辑认知，一首诗和一段代码，都是一种表达方式，当技巧和内涵达到一定的精妙程度，都能令人赞叹 ~ 世界触目所及满是『道』的痕迹。

扯远了，等项目忙完了有时间再单独写写。

技术人员对于权限控制应该并不陌生，毕竟工作中或多或少都需要和 Linux 打交道，都知道用 root 用户运行进程是高危操作，安全界不时爆出来的 root 提权漏洞也是听得耳朵都起茧子了。Linux 中的权限是作用于文件（Linux 系统的哲学之一：一切皆文件），限制所有者、组、其他组的读、写、执行行为。这属于底层视角，自下而上，我们知道，越接近底层越繁琐，细节总是多于概念，需要再进一步的抽象。而 RBAC（Role-Based Access Control），基于角色的访问控制，就是聚焦于人的更进一步的抽象。角色就好比人名片上的头衔，标记的是人，从数量上来说天然就更少。

K8S 中采用 RBAC 作为权限控制模型，使用角色的主体可以为 User、Group、ServiceAccount，角色又分两种：Role、ClusterRole，望文生义，后一种能作用于整个集群，前一种则只能作用于一个指定的 Namespace 。主体和角色通过绑定来建立关系，绑定也分两种：RoleBinding、ClusterRoleBinding。作用域为集群的自然是不用声明 Namespace 的。

在这里，ClusterRole 也可以用 RoleBinding 来绑定出去，列几种常用场景：

1）将 A NS 的权限授予 A NS 的主体：Role(NS: A)、RoleBinding(NS: A)、主体(NS: A)

2.1）将 A NS 的权限授予 B NS 的主体：Role(NS: A)、RoleBinding(NS: A)、主体(NS: B)

2.2）将 A NS 的权限授予 B NS 的主体：ClusterRole、RoleBinding(NS: A)、主体(NS: B)

3） 将所有 NS 的权限授予 B NS 的主体 ：ClusterRole、ClusterRoleBinding、主体(NS: B)

也就是说，被 RoleBinding 所绑定出去的权限，只能是 RoleBinding 所在命名空间的权限，当 ClusterRole 被 RoleBinding 引用，则实际效果等同 Role。瞅瞅代码，里面也是这样解释的。

Reference

https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/

https://octopus.com/blog/k8s-rbac-roles-and-bindings

https://github.com/kubernetes/kubernetes/blob/release-1.22/pkg/apis/rbac/types.go