用 RBAC 来管控 Kubernetes 资源访问权限，避免乱动和安全隐患

在Kubernetes集群中，如果没有一套清晰的权限管理机制，就如同把一座宝库的钥匙交给了所有人，任何有访问权限的用户或应用（例如运行中的Pod）都可以随意创建、修改或删除集群中的关键资源，如Pod、服务、配置信息甚至节点本身，这会导致严重的问题，主要包括两类：一是无意中的“乱动”，比如开发人员误删了生产环境的数据库Pod，导致服务长时间中断；二是恶意行为带来的“安全隐患”，比如某个被入侵的应用服务利用过高权限在集群内部进行横向移动,窃取数据或进行破坏。

为了解决这些问题，Kubernetes内置了一套名为“基于角色的访问控制”（RBAC）的授权机制，它的核心思想非常直观：不是直接给用户或服务分配权限，而是先定义好“角色”，规定这个角色能做什么，再把角色赋予给具体的用户或服务账户。 这种分层的管理方式极大地提升了权限管理的灵活性和安全性。

RBAC模型主要由四个核心概念组成：

1. 主体（Subject）：指需要访问Kubernetes资源的人或东西，主要包括三类：普通用户（User）、用户组（Group）和服务账户（ServiceAccount），服务账户尤其重要,它是给在Pod中运行的程序使用的身份。
2. 资源（Resource）：指Kubernetes中需要被保护的对象，例如Pod、Deployment、Service、Secret、Namespace等。
3. 动词（Verb）：指对资源可以执行的操作，也就是具体的权限，最常见的动词包括：get（查看）、list（列表）、watch（监听）、create（创建）、update（更新）、patch（部分更新）、delete（删除）等。
4. 角色（Role）和角色绑定（RoleBinding）：这是RBAC的核心。
   • 角色（Role）：它定义了一组规则，明确说明了“在哪个命名空间（Namespace）内，可以对哪些资源执行哪些操作”，可以定义一个名为“pod-reader”的角色，规则是“在‘default’命名空间内，对‘pods’资源拥有‘get’、‘list’和‘watch’的权限”。
   • 集群角色（ClusterRole）：与Role类似，但它的权限是集群范围的，不局限于某个命名空间，通常用于授予访问集群级资源（如节点Node、存储卷PersistentVolume）的权限,或者被跨命名空间引用。
   • 角色绑定（RoleBinding）：它将一个角色（Role）中定义的权限授予一个或多个主体（Subject），它有自己的作用范围，通常限定在某个命名空间内，创建一个RoleBinding，将上面定义的“pod-reader”角色绑定给名为“jane”的用户,那么jane就在default命名空间拥有了只读Pod的权限。
   • 集群角色绑定（ClusterRoleBinding）：与RoleBinding类似，但它将集群角色（ClusterRole）的权限授予主体，并且这种绑定是全局生效的，作用于整个集群,需要极其谨慎地使用。

如何具体运用RBAC来实践“最小权限原则”,避免乱动和安全隐患呢？

第一，为不同职责的人员创建不同的角色。 绝不能给所有开发人员“cluster-admin”（集群管理员）这样的超级权限,应该根据他们的实际工作需要来定制角色。

• 对于应用开发者：可以创建一个角色，允许他们在特定的开发或测试命名空间中管理Deployment、Pod和Service（动词包括get、list、create、delete等），但绝对不允许他们访问Secrets（密码、密钥等敏感信息）或操作其他命名空间的资源。
• 对于运维人员：可能需要一个范围更广的角色，允许他们查看所有命名空间的Pod状态、节点信息，甚至管理存储和命名空间本身,但可能仍然不需要修改某些核心系统组件的权限。
• 对于只需查看监控信息的人：可以创建一个只有“get”、“list”、“watch”Pod、Node等资源的只读角色。

第二，严格管控服务账户的权限。 这是防止安全隐患的重中之重，默认情况下，在Pod中运行的程序如果没有指定服务账户，会使用一个默认的、权限很有限的账户，但很多应用需要访问Kubernetes API，这时就要为其创建专门的服务账户（ServiceAccount）,并绑定一个权限精确匹配的角色。

• 典型案例：一个日志收集Agent（如Fluentd）需要读取所有Pod的日志，那么就应该创建一个ClusterRole，定义其对“pods”和“pods/log”资源有“get”、“list”和“watch”的权限，然后通过RoleBinding或ClusterRoleBinding将这个角色绑定给Fluentd Pod所使用的服务账户，这样就实现了既满足功能需求,又不会授予它删除Pod或修改服务的额外权限。
• 反面教材：图省事，直接给一个应用的服务账户绑定“cluster-admin”角色，或者绑定一个权限过于宽泛的角色，一旦该应用存在安全漏洞被攻击者利用，攻击者就获得了整个集群的控制权,后果不堪设想。

第三，利用命名空间进行逻辑隔离。 将RBAC与命名空间结合是最佳实践，可以为每个项目、每个团队甚至每个环境（开发、测试、生产）创建独立的命名空间，通过Role和RoleBinding将权限严格限制在各自的命名空间内，这样，A团队的用户和服务账户默认根本无法访问或影响B团队的资源，从物理（逻辑）层面避免了跨团队的误操作和越权访问。

第四，定期审计和清理权限。 随着人员变动和项目演进，需要定期检查集群中的RoleBinding和ClusterRoleBinding，确保没有闲置的、过期的或权限过大的绑定存在，可以使用像kubectl describe clusterrolebinding和kubectl describe rolebinding -n <namespace>这样的命令来审查,也可以借助一些开源工具进行更深入的RBAC权限分析。

RBAC是保障Kubernetes集群安全稳定运行的基石，通过遵循“最小权限原则”，精心设计角色，严谨地进行权限绑定，并将权限范围控制在命名空间之内，可以有效地将“乱动”的风险降到最低，并构筑起一道坚实的安全防线,防止因权限泛滥而导致的严重安全事故。