1. Kubernetes RBAC基础概念
刚接触Kubernetes权限管理时，我经常被各种角色和绑定关系绕晕。直到踩过几次坑才明白，RBAC（基于角色的访问控制）其实就像公司里的岗位职级体系：Role是岗位说明书，ServiceAccount是员工工牌，而RoleBinding就是人事部的任命文件。
先看几个核心概念：
- ServiceAccount：相当于Pod的身份证。每个Pod运行时都会自动挂载一个ServiceAccount，默认是default。我建议永远不要使用default账号，就像你不会把管理员密码贴在公告栏上。
- Role：部门级权限手册。比如开发团队只能访问test命名空间下的Pod，这就是典型的Role场景。它的权限范围仅限单个命名空间。
- ClusterRole：集团级权限手册。比如运维团队需要查看所有节点的状态，这种跨命名空间的权限就需要ClusterRole。
这里有个容易混淆的点：RoleBinding既能绑定Role也能绑定ClusterRole。但绑定ClusterRole时，权限会被限制在RoleBinding所在的命名空间内。这就像把集团制度下发给某个分公司执行。
2. 创建ServiceAccount实战
去年我们有个事故：某测试Pod误删了生产环境的ConfigMap。根本原因就是用了default ServiceAccount。现在我的团队强制要求：每个微服务必须使用专属ServiceAccount。
# 创建专属账号就像办工牌
apiVersion: v1
kind: ServiceAccount
metadata:
name: order-service
namespace: production
扫一扫
9006
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
