4. 鉴权

# 一、RBAC 授权模式

1. RBAC的基于“角色”（role）这一核心组件实现了权限指派，它为账号赋予一到多个角色从而让其具有角色之上的权限，其中的账号可以是用户账号、用户组、服务账号及其相关的组等，而同时关联至多个角色的账号所拥有的权限是多个角色之上的权限集合。
2. RBAC具有如下优势
- 对集群中的资源和非资源型URL的权限实现了完整覆盖。
- 整个RBAC完全由少数几个API对象实现，而且同其他API对象一样可以用kubectl或API调用进行操作。
- 支持权限的运行时调整，无须重新启动API Server。
3. RBAC基本概念
- Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
- Subject：被作用者，既可以是“人”，也可以是“机器”，也可以使你在 Kubernetes 里定义的“用户”。
- RoleBinding：定义了“被作用者”和“角色”的绑定关系。

![未命名图片.png](/media/202406/11.4.15283281_image1.png)

4. RBAC 的 API 资源对象 RBAC 引入了 4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4种对象类型均可以通过 kubectl 与 API 操作
- Role：作用于名称空间级别，用于定义名称空间内的资源权限集合
- ClusterRole：用于集群级别的资源权限集合。常用于控制Role无法生效的资源类型，这包括集群级别的资源（如Nodes）、非资源类型的端点（如/healthz）和作用于所有名称空间的资源（例如，跨名称空间获取任何资源的权限）。
- RoleBinding用于将Role上的许可权限绑定到一个或一组用户之上，它隶属于且仅能作用于一个名称空间。绑定时，可以引用同一名称中的Role，也可以引用集群级别的ClusterRole。
- ClusterRoleBinding把ClusterRole中定义的许可权限绑定在一个或一组用户之上，它仅可以引用集群级别的ClusterRole。
5. 支持的动作 create delete deletecollection get list patch update watch，bind等
6. 支持的资源 “services”, “endpoints”, “pods“，"deployments“ **“**jobs”，“configmaps”，“nodes”，“rolebindings”，“clusterroles”

# 二、Role and ClusterRole

1. Role表示一组规则权限，权限只会增加(累加权限)，不存在一个资源一开始就有很多权限而通过RBAC对其进行减少的操作
2. Role 可以定义在一个 namespace 中，如果想要跨 namespace则可以创建ClusterRole，ClusterRole 具有与 Role相同的权限角色控制能力，不同的是 ClusterRole 是集群级别的，ClusterRole可以用于:
- 集群级别的资源控制( 例如 node 访问权限 )
- 非资源型 endpoints( 例如/healthz访问 )
- 所有命名空间资源控制(例如 pods )
3. Role对象中的rules也称为PolicyRule，用于定义策略规则，不过它不包含规则应用的目标，其可以内嵌的字段包含如下几个。

| apiGroups | string | 包含了资源的API组的名称，支持列表格式指定的多个组，空串（""）表示核心组。 |
| --- | --- | --- |
| resourceNames | string | 规则应用的目标资源名称列表，可选，缺省时意味着指定资源类型下的所有资源。 |
| resources | string | 规则应用的目标资源类型组成的列表，例如pods、deployments、daemonsets、roles等，ResourceAll表示所有资源 |
| verbs | string | 可应用至此规则匹配到的所有资源类型的操作列表，可用选项有get、list、create、update、patch、watch、proxy、redirect、delete和deletecollection；此为必选字段 |
| nonResourceURLs | string | 用于定义用户应该有权限访问的网址列表，它并非名称空间级别的资源，因此只能应用于ClusterRole和ClusterRoleBinding，在Role中提供此字段的目的仅为与ClusterRole在格式上兼容。 |

2. RoleBinding的配置中主要包含两个嵌套的字段subjects和roleRef，其中，subjects的值是一个对象列表，用于给出要绑定的主体，而roleRef的值是单个对象，用于指定要绑定的Role或ClusterRole资源。
- subjects字段的可嵌套字段具体如下。

| apiGroup | string | 要引用的主体所属的API群组，对于ServiceAccount类的主体来说默认为""，而User和Group类主体的默认值为"rbac.authorization.k8s.io" |
| --- | --- | --- |
| kind | string | 要引用的资源对象（主体）所属的类别，可用值为"User" "Group"和"ServiceAccount"三个，必选字段 |
| name | string | 引用的主体的名称，必选字段 |
| namespace | string | 引用的主体所属的名称空间，对于非名称空间类型的主体，如"User"和"Group"，其值必须为空，否则授权插件将返回错误信息 |

- roleRef的可嵌套字段具体如下。

| apiGroup | string | 引用的资源（Role或ClusterRole）所属的API群组，必选字段 |
| --- | --- | --- |
| kind | string | 引用的资源所属的类别，可用值为Role或ClusterRole，必选字段 |
| name | string | 引用的资源的名称 |

3. Resources
- Kubernetes 集群内一些资源一般以其名称字符串来表示，这些字符串一般会在 API 的 URL 地址中出现；同时某些资源也会包含子资源，例如 logs 资源就属于 pods 的子资源，它们的URL格式通常形如如下表示：GET /api/v1/namespaces/{namespace}/pods/{name}/log
- 在RBAC角色定义中，如果要引用这种类型的子资源，则需要使用“resource/subre-source”的格式

# 三、RoleBinding and ClusterRoleBinding

1. RoloBinding 可以将角色中定义的权限授予用户或用户组，RoleBinding包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型(users,groups, or service accounts)；
2. RoloBinding 同样包含对被Bind 的 Role 引用；RoleBinding适用于某个命名空间内授权，而 ClusterRoleBinding 适用于集群范围内的授权
3. RoleBinding 同样可以引用 ClusterRole 来对当前 namespace 内用户、用户组或ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole，然后在不同的 namespace 中使用RoleBinding 来引用
4. to Subjects
- RoleBinding 和 ClusterRoleBinding 可以将 Role 绑定到 Subjects；Subjects可以是 groups、users 或者service accounts
- Subjects 中 Users 使用字符串表示，它可以是一个普通的名字字符串，如“alice”；也可以是 email 格式的邮箱地址，如“wangyanglinux@163.com”；甚至是一组字符串形式的数字 ID 。但是 Users 的前缀，system: 是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式
- Groups 书写格式与 Users 相同，都为一个字符串，并且没有特定的格式要求；同样 system: 前缀为系统保留

# 四、常用策略

1. Role+RoleBinding 正常使用：某个名称空间级别的权限授权
2. ClusterRole+ClusterRoleBinding 正常使用：k8s集群级别的权限授权
3. ClusterRole+RoleBinding 交叉使用：其中ClusterRole策略会降级成rolebinding名称空间的策略，效果和role+rolebinding一样，好处就是在名称空间很多的时候，重复权限的配置文件会少一半，而且更灵活