Kubernetes RBAC权限控制：从入门到实战

🔥「炎码工坊」技术弹药已装填！
点击关注 → 解锁工业级干货【工具实测|项目避坑|源码燃烧指南】

引言：为什么需要RBAC？

在Kubernetes集群中，权限失控是导致安全漏洞的核心原因之一。试想以下场景： 

• 开发人员误删生产环境的Pod或配置； 
• 第三方服务账户拥有过高的集群管理权限； 
• 多团队共享集群时资源冲突或数据泄露。

Kubernetes通过**RBAC（基于角色的访问控制）**机制，实现了对用户、服务账户和服务的细粒度权限管理。本文将带你从零掌握RBAC的核心原理与实战技巧，并提供可复用的代码示例。 

一、RBAC核心概念与原理

RBAC的核心是角色（Role）与绑定（Binding），其逻辑类似于“职位说明书”与“员工职位分配”： 

1. 角色定义：谁可以做什么？

• Role：作用于单个命名空间的权限规则。 
• ClusterRole：作用于整个集群的权限规则（如节点管理、集群级操作）。

示例：定义一个只允许读取Pod的角色

# pod-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default  # 限定命名空间
  name: pod-reader
rules:
- apiGroups: [""]  # 核心API组（Pod属于此组）
  resources: ["pods"]  # 允许操作的资源类型
  verbs: ["get", "list", "watch"]  # 可执行的操作

2. 角色绑定：谁被赋予了什么角色？

• RoleBinding：将Role绑定到用户、组或服务账户（作用于同一命名空间）。 
• ClusterRoleBinding：将ClusterRole绑定到全局对象。

示例：将pod-reader角色绑定到开发团队用户

# pod-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kin