第九章.k8s集群安全机制-鉴权-3

来源链接：https://www.bilibili.com/video/BV1PbeueyE8V?spm_id_from=333.788.videopod.episodes&vd_source=d8c71ff24a3359a807967fc4b5daa0e4&p=68

1. 证书生成前置准备与cfssl工具部署

• 操作位置建议选择master节点的/etc/kubernetes/pki目录，该目录默认存储集群所有相关证书，避免证书随意存放带来安全风险。
• 第一步生成证书签名请求描述文件：创建名为devuser.json的文件，写入证书生成规则后保存。
• 第二步部署cfssl证书工具集：cfssl是Kubernetes生态常用的证书签发工具，需要配合cfssl、cfssljson、cfssl-certinfo三个工具共同使用，官方下载速度较慢，可直接使用课程提供的预置工具包，操作步骤如下：
  1. 将三个工具包上传到服务器家目录
  2. 移动到/usr/local/bin目录下
  3. 为工具添加可执行权限
  4. 执行cfssl命令验证工具可用

2. 用户证书生成与kubeconfig文件配置

• 生成dv_user用户证书：执行cfssl签发命令，指定CA证书、CA私钥、证书输出前缀、证书类型为kubernetes、JSON描述文件路径，执行后生成三类文件：dev_user.csr（证书请求文件）、dv_user.pem（用户证书）、dev_user-key.pem（用户私钥）。
• 生成kubectl配置文件（kubeconfig）：该文件用于kubectl连接集群时的身份认证，配置过程分为三步：
  1. 配置集群参数：指定集群名称为kubernetes、CA根证书路径、API Server访问地址（如https://192.168.66.11:6443）、配置文件保存路径为devuser.kubeconfig
  2. 配置客户端认证参数：绑定dev_user用户，关联对应用户证书与私钥，保存到上述kubeconfig文件
  3. 配置上下文：将集群、用户、默认命名空间dv关联，上下文命名为kubernetes，保存到配置文件
• 完成上述配置后，devuser.kubeconfig就包含了完整的集群、用户、上下文信息，可直接用于kubectl的集群认证。

3. 权限绑定与鉴权验证

• 权限累加规则说明：Kubernetes权限为累加机制，用户默认无任何操作权限，必须绑定对应的角色（Role）/集群角色（ClusterRole）才能获得操作权限，权限不会自动继承。
• 创建目标命名空间：执行kubectl create ns dev创建名为dev的命名空间，后续权限绑定均作用于该命名空间。
• 创建角色绑定：将官方预置的集群角色admin绑定到dev_user用户，绑定范围为dev命名空间，执行命令：

  kubectl create rolebinding dv-admin-binding --clusterrole=admin --user=dev_user --namespace=dev
  

  可通过添加--dry-run=client -o yaml参数输出对应的YAML资源清单，确认绑定规则：绑定类型为RoleBinding（非ClusterRoleBinding），绑定来源为集群角色admin，绑定用户为dv_user，仅作用于dv命名空间，属于集群角色的“降维绑定”，权限限定在单个命名空间内。
• 切换kubectl上下文：执行kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig，加载dev_user的认证配置。
• 权限验证：
  1. 将devuser.kubeconfig文件复制到root用户家目录的.kube目录下，重命名为config，替换默认的管理员认证配置
  2. 执行kubectl get pod可正常返回（默认查询default命名空间，当前无Pod故返回为空）
  3. 执行kubectl get pod -n default返回403 Forbidden权限不足，因为dv_user仅拥有dev命名空间的admin权限，无default命名空间的访问权限
  4. 在dev命名空间创建Deployment验证：执行kubectl create deployment dv-delaying --image=myapp:v1.0 --namespace=dev，扩容副本数到10，执行kubectl get pod -n dv可看到10个对应Pod，确认dev_user在dev命名空间下的权限符合预期
  5. 切换回管理员kubeconfig配置后，可正常查询default命名空间的资源，进一步验证权限隔离的有效性。

4. Linux系统用户与K8s权限隔离实践

• 为避免手动切换kubeconfig文件的繁琐操作，可结合Linux系统用户实现用户级的K8s权限自动隔离：kubectl默认读取当前登录用户家目录下.kube目录的config文件，因此为不同K8s用户创建对应的Linux系统用户，将对应kubeconfig文件放在对应用户的家目录下即可实现权限自动匹配。
• 操作步骤：
  1. 创建Linux系统用户：执行useradd dev创建用户，执行passwd dev设置密码为123123
  2. 创建配置目录：在dev用户的家目录下创建.kube目录
  3. 复制配置文件：将devuser.kubeconfig文件复制到/home/dev/.kube/目录下，重命名为config
  4. 配置目录权限：递归修改/home/dv目录的权限，所有者为dev用户、dev组，确保用户可正常读取配置文件
• 验证：使用dev用户登录服务器，直接执行kubectl相关命令，默认操作dev命名空间，无需手动切换配置，即可实现用户级的K8s权限隔离。

5. Kubernetes内置常用集群角色说明

Kubernetes官方预置了多种内置集群角色，可直接用于权限绑定，无需手动创建权限规则，常见角色及权限范围如下：

• view：只读角色，允许读取指定命名空间中的大多数资源（如Deployment、ConfigMap等），禁止读取Role、RoleBinding、Secret资源，避免权限溢出（Secret关联ServiceAccount，读取后可能获取API Server访问权限）
• edit：读写角色，允许读取和修改指定命名空间中的大多数资源，禁止查看或修改Role、RoleBinding，防止权限扩散
• admin：命名空间管理员角色，拥有指定命名空间内除资源配额、命名空间本身外的所有资源的完全控制权限，可读写命名空间内的Role、RoleBinding；与edit角色的核心区别是admin可管理命名空间的权限配置
• cluster-admin：集群管理员角色，拥有整个Kubernetes集群的完全控制权，是集群内最高权限角色，相当于集群的“root用户”
• 补充说明：system:开头的集群角色均为系统组件专用预设角色，如system:node用于节点管理、system:kubernetes-scheduler用于调度器、system:coredns用于CoreDNS插件，是系统运行的基础权限配置，不建议手动修改。

AI 总结

本小节完成了Kubernetes RBAC鉴权机制的全流程实践：从用户证书生成、kubeconfig配置、角色绑定到权限验证，同时结合Linux系统用户实现了用户级的权限自动隔离，最后介绍了官方预置的4类常用内置集群角色的权限范围。核心要点包括：K8s权限为累加制，用户默认无权限需绑定角色才能获得操作权；集群角色可通过RoleBinding实现“降维绑定”，权限限定在单个命名空间内；可通过系统用户与kubeconfig路径的绑定实现便捷的权限隔离，大幅降低多用户管理的配置成本。