K8s 的鉴权管理（一）：基于角色的访问控制（RBAC 鉴权）
1.Kubernetes 的鉴权管理
客户端请求通过认证阶段后，将进入鉴权阶段。这个阶段将包含两个内容：
- 1️⃣ 审查客户端请求的属性
- 2️⃣ 确定请求的操作
1.1 审查客户端请求的属性
Kubernetes 审查客户端请求的属性 主要包括以下几个方面。
- 用户与组：经过认证的用户名和所属组名的列表。
- API 和动作：对 Kubernetes 资源的操作，如
create、list、get等请求动词。 - 请求路径和动作：指示各种非 Kubernetes 资源的路径（如
/api），以及对该路径执行的 HTTP 操作（如 GET、POST、PUT 等）。 - 命名空间：正在访问的 Kubernetes 对象的命名空间。
1.2 确定请求的操作
确定请求的操作 是指，确定对 Kubernetes 资源对象的请求动词或 HTTP 操作，以及该动词或 HTTP 操作是针对单个资源还是一组资源。
下表列举常见的请求动词与 HTTP 操作，以及它们的对应关系。
| 请求动词 | HTTP 操作 |
|---|---|
create | POST |
get、list | GET、HEAD |
update | PUT |
patch | PATCH |
delete、deletecollection | DELETE |
根据 Kubernetes 鉴权时使用的模块，可以将 Kubernetes 的鉴权分为以下 4 4 4 种方式：
- 基于 角色 的访问控制（RBAC 鉴权）
- 基于 属性 的访问控制（ABAC 鉴权）
- 基于 节点 的访问控制（Node 鉴权）
- 基于 Webhook 的访问控制
❗ 基于角色的访问控制（RBAC 鉴权）是最重要的鉴权方式。
2.基于角色的访问控制（RBAC 鉴权）
基于角色的访问控制（Role-Based Access Control，RBAC），通过为用户赋予不同的角色来控制其访问 Kubernetes 集群资源。它允许用户动态配置不同的角色策略。基于角色的访问控制需要使用 rbac.authorization.k8s.io API 组来执行。
2.1 基于角色的访问控制中的概念
在基于角色的访问控制中涉及 3 3 3 个非常重要的概念：角色、角色绑定 和 主体。
2.1.1 角色
角色 是一组权限的集合。Kubernetes 中的角色分为两种：Role 和 ClusterRole。
- Role 是某个命名空间中对象访问权限的集合。因此，在创建 Role 时，必须指定 Role 所属的命名空间。
- ClusterRole 是访问某个命名空间的权限的集合。
2.1.2 角色绑定
将包含各种权限的角色授予给一个主体，这个过程被叫作 角色绑定。因为角色分为 Role 和 ClusterRole，所以角色绑定分为 RoleBinding 和 ClusterRoleBinding。
2.1.3 主体
使用角色的用户被叫作 主体（Subject）。它可以是一个用户（User）、一个用户组（Group），也可以是一个服务账号（ServiceAccount）。
角色与角色绑定存在
3
3
3 种关系：RoleBind-Role、ClusterRoleBind-ClusterRole 和 RoleBind-ClusterRole，如下图所示。
下面解释了这
3
3
3 种关系的区别：
User A通过 RoleBinding 绑定到了 Role 上。因此，它就拥有了命名空间 A 的操作权限。- 在集群 B 上有两个命名空间：命名空间 A 和命名空间 B。
User B通过 ClusterRolebinding 绑定到 ClusterRole 上，因此它拥有了集群的操作权限（即访问命名空间 A 和命名空间 B）。 User C在使用 RoleBind 和 ClusterRole 进行绑定时，仅能获取当前名称空间的所有权限（即User C只能访问命名空间 A）。
角色、角色绑定 和 主体 之间的约束关系如下图所示。
2.2 实现基于角色的访问控制
下面来演示如何实现基于角色的访问控制。这里将实现 Jerry 用户只能对 mydemo 命名空间拥有读取 Pod 的权限。
创建 mydemo 命名空间，并在该命名空间中创建 Pod。
kubectl create ns mydemo
kubectl create deployment nginx --image=nginx --replicas=3 -n mydemo
查看 mydemo 命名空间中的 Pod 信息。
kubectl get pods -n mydemo
输出的信息如下：
生成 只有读取 Pod 权限的角色 的描述信息。
kubectl create role mydemo-pod-reader-role --verb=get,list,watch --resource=pods --dry-run -o yaml
在生成的描述信息中增加 namespace: mydemo 字段，并将描述信息保存为 mydemo-pod-reader-role.yaml 文件。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: mydemo-pod-reader-role
namespace: mydemo
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
创建 mydemo-pod-reader-role 角色。
kubectl apply -f mydemo-pod-reader-role.yaml
查看 mydemo 命名空间中的角色信息。
kubectl get role -n mydemo
输出的信息如下：
编辑 mydemo-pod-reader-rolebinding.yaml 文件进行角色绑定，将主体与角色进行绑定。
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: mydemo-pod-reader-rolebinding
namespace: mydemo
subjects:
- kind: User
#名字大小写敏感
name: Jerry
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role #this must be Role or ClusterRole
# 名字必须与Role或者ClusterRole的名字一致
name: mydemo-pod-reader-role
apiGroup: rbac.authorization.k8s.io
标签：kubectl,Kubernetes,角色,访问控制,Jerry,RBAC,mydemo,鉴权 From： https://blog.csdn.net/be_racle/article/details/142023207