理解RBAC在Kubernetes中的作用
在搭建好Kubernetes集群后，很多人会直接进入应用部署阶段，但忽略了一个关键环节——权限管理。RBAC（Role-Based Access Control）是Kubernetes中用于控制用户和服务账户访问资源的核心机制。比如公司里不同岗位的人能操作的系统功能不一样，开发人员不需要删除生产数据库的权限，同理，在K8s中也不能让每个服务都拥有集群管理员权限。
不设置RBAC，相当于把整个系统大门钥匙交给所有人，一旦某个Pod被攻破，攻击者就能横向移动操控整个集群。所以从一开始就合理部署RBAC权限，就像给办公室每个房间配不同的门禁卡，谁该进哪个门，提前安排清楚。
开启RBAC并创建基本角色
Kubernetes默认支持RBAC，只要apiserver启动时启用了--authorization-mode=RBAC参数即可。大多数托管K8s服务如阿里云ACK、腾讯云TKE都已默认开启。
接下来以一个实际场景为例：你需要让一个名为dev-user的开发者只能查看default命名空间下的Pod，不能修改或删除。
先定义一个Role：
<apiVersion> rbac.authorization.k8s.io/v1</apiVersion>
<kind> Role</kind>
<metadata>
<namespace> default</namespace>
<name> pod-reader</name>
</metadata>
<rules>
- <apiGroups> [""] </apiGroups>
<resources> pods</resources>
<verbs> ["get", "list", "watch"] </verbs>
</rules>这个Role只允许读取Pod信息。接着绑定到用户：
<apiVersion> rbac.authorization.k8s.io/v1</apiVersion>
<kind> RoleBinding</kind>
<metadata>
<name> read-pods</name>
<namespace> default</namespace>
</metadata>
<subjects>
- <kind> User</kind>
<name> dev-user</name>
<apiGroup> rbac.authorization.k8s.io</apiGroup>
</subjects>
<roleRef>
<kind> Role</kind>
<name> pod-reader</name>
<apiGroup> rbac.authorization.k8s.io</apiGroup>
</roleRef>为服务账户分配最小权限
更常见的需求是给运行在集群内的应用授权。比如一个监控Agent需要获取所有命名空间的Pod状态，但不应允许它创建Deployment。
创建一个ServiceAccount：
<apiVersion> v1</apiVersion>
<kind> ServiceAccount</kind>
<metadata>
<name> monitor-agent</name>
<namespace> kube-system</namespace>
</metadata>然后定义一个ClusterRole，因为它需要跨命名空间访问：
<apiVersion> rbac.authorization.k8s.io/v1</apiVersion>
<kind> ClusterRole</kind>
<metadata>
<name> pod-monitor</name>
</metadata>
<rules>
- <apiGroups> [""] </apiGroups>
<resources> pods</resources>
<verbs> ["get", "list", "watch"] </verbs>
</rules>最后通过ClusterRoleBinding关联ServiceAccount：
<apiVersion> rbac.authorization.k8s.io/v1</apiVersion>
<kind> ClusterRoleBinding</kind>
<metadata>
<name> bind-monitor-to-agent</name>
</metadata>
<subjects>
- <kind> ServiceAccount</kind>
<name> monitor-agent</name>
<namespace> kube-system</namespace>
</subjects>
<roleRef>
<kind> ClusterRole</kind>
<name> pod-monitor</name>
<apiGroup> rbac.authorization.k8s.io</apiGroup>
</roleRef>部署完成后，在Pod的spec中指定serviceAccountName使用该身份运行，就能以限定权限执行任务了。
验证权限是否生效
配置完别急着上线，用kubectl测试最直接。切换到目标用户或使用--as参数模拟：
kubectl get pods --as=dev-user -n default如果返回正常列表，再试试删除操作：
kubectl delete pod xxx --as=dev-user -n default预期会提示“permission denied”，说明RBAC起了作用。这种提前验证能避免线上环境因权限不足导致应用异常。
日常维护中，定期检查现有的RoleBinding和ClusterRoleBinding，清理不再使用的授权，就像定期更换门禁卡一样，保持系统的干净和安全。