立即关注公众号宁波seo排名优化培训

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$ 种方式：

• 基于 角色 的访问控制（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: nullname: mydemo-pod-reader-rolenamespace: mydemo
rules:
- apiGroups:- ""resources:- podsverbs:- 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-rolebindingnamespace: mydemo
subjects:
- kind: User#名字大小写敏感name: JerryapiGroup: 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 信息。