【Kubernetes】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 操作，以及它们的对应关系。

根据 Kubernetes 鉴权时使用的模块，可以将 Kubernetes 的鉴权分为以下 $4$ 种方式：

• 基于 角色 的访问控制（RBAC 鉴权）
• 基于 属性 的访问控制（ABAC 鉴权）
• 基于 节点 的访问控制（Node 鉴权）
• 基于 Webhook 的访问控制

基于角色的访问控制（RBAC 鉴权）是最重要的鉴权方式。

2.基于角色的访问控制（RBAC 鉴权）

基于角色的访问控制（Role-Based Access Control，RBAC），通过为用户赋予不同的角色来控制其访问 Kubernetes 集群资源。它允许用户动态配置不同的角色策略。基于角色的访问控制需要使用 rbac.authorization.k8s.io API 组来执行。

2.1 基于角色的访问控制中的概念

在基于角色的访问控制中涉及 $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$ 种关系：RoleBind-Role、ClusterRoleBind-ClusterRole 和 RoleBind-ClusterRole，如下图所示。

下面解释了这 $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

这里的主体是用户名称（即 Jerry），绑定的角色是 mydemo-pod-reader-role。

执行 kubectl apply -f 命令。

kubectl apply -f mydemo-pod-reader-rolebinding.yaml

查看 mydemo 命名空间中的角色信息与角色绑定信息。

kubectl get role,rolebinding -n mydemo

输出的信息如下：

创建 Jerry 用户和认证证书。

# 生成用户的私钥
openssl genrsa -out Jerry.key 2048

# 使用刚生成的私钥创建证书，并在 -subj 中指定用户和组。证书文件格式: 用户名.csr
openssl req -new -key Jerry.key -out Jerry.csr -subj "/CN=Jerry/O=mydemo"

# 在 /etc/kubernetes/pki 目录下，找到 Kubernetes 集群的证书 ca.crt 和 ca.key
# 生成最终的证书 Jerry.crt，有效期为 30 天
openssl x509 -req -in Jerry.csr -CA /etc/kubernetes/pki/ca.crt \
-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial \
-out Jerry.crt -days 30

把 Jerry 用户的凭证加入 kubeconfig。

kubectl config set-credentials Jerry --client-key=Jerry.key --client-certificate=Jerry.crt

查看 config 文件，看是否把密钥的内容写进去了，以便在命令行中切换用户。

tail ~/.kube/config

输出的信息如下：

创建用户上下文对象 Jerry-contex。

kubectl config set-context Jerry-context --cluster=kubernetes --namespace=mydemo --user=Jerry

切换到 Jerry 用户。

kubectl config use-context Jerry-context

输出的信息如下：

在 Kubernetes 中进行用户切换的常用命令有：

• 回到管理员：kubectl config use-context kubernetes-admin@kubernetes
• 获取所有用户的 context 列表：kubectl config get-contexts
• 获取当前用户的 context 信息：kubectl config current-context

测试 Jerry 用户能否读取 mydemo 命名空间中的 Pod 信息。

kubectl get pod -n mydemo

如果能够正常读取 mydemo 命名空间中的 Pod 信息，则输出如下信息：

执行以下命令测试 Jerry 用户能否在 mydemo 命名空间中创建 Pod：

kubectl create deployment Jerry-nginx --image=nginx --replicas=3 -n mydemo

这时将出现以下错误信息：

error: failed to create deployment: 
deployments.apps is forbidden: 
User "Jerry" cannot create resource "deployments" in API group "apps" in the namespace "mydemo"

按照相同的方法创建 Tom 用户和认证证书，并切换到 Tom 用户，测试 Tom 用户能否读取 mydemo 命名空间中的 Pod 信息。