Kubernetes RBAC

Kubernetes RBAC

基于角色的访问控制（Role-Based Access Control，简称RBAC）是Kubernetes中用于管理用户和服务账户对集群资源访问权限的核心安全机制。RBAC允许管理员通过定义角色（Role）和角色绑定（RoleBinding）来精确控制谁可以在什么范围内执行哪些操作。

核心概念

角色（Role）与集群角色（ClusterRole）

• Role：作用于特定命名空间（Namespace）的权限集合，定义了对该命名空间内资源（如Pods、Services等）的操作权限。
• ClusterRole：与Role类似，但作用域为整个集群（跨所有命名空间）或非资源型API（如`/metrics`）。

角色绑定（RoleBinding）与集群角色绑定（ClusterRoleBinding）

• RoleBinding：将角色绑定到用户、组或服务账户，仅在其所属命名空间内生效。
• ClusterRoleBinding：将集群角色绑定到主体，权限全局有效。

RBAC API 对象示例

以下是一个Role和RoleBinding的YAML示例：

# 示例1：定义一个允许读取Pod信息的Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # 空字符串表示核心API组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

# 示例2：将Role绑定到用户"jane"
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: read-pods
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

权限规则详解

RBAC规则通过以下字段定义：

• apiGroups：指定API组（如`apps`、`batch`），核心资源组为`""`。
• resources：目标资源类型（如`pods`、`deployments`）。
• verbs：允许的操作，常见值包括：

 * 读操作：`get`, `list`, `watch`
 * 写操作：`create`, `update`, `delete`
 * 特权操作：`patch`, `exec`

实际应用场景

场景1：开发团队命名空间隔离

开发团队需要在自己的命名空间内管理资源，但禁止访问其他团队的资源。解决方案： 1. 为每个团队创建独立命名空间（如`team-a`）。 2. 定义Role授予该命名空间内的完整权限。 3. 通过RoleBinding将角色绑定到团队成员。

graph LR A[Cluster] --> B[Namespace: team-a] B --> C[Role: team-admin] C --> D[规则: full-access] D --> E[RoleBinding] E --> F[User: dev1]

场景2：监控系统只读权限

Prometheus需要集群范围的只读权限： 1. 创建ClusterRole定义`get`、`list`、`watch`权限。 2. 创建ClusterRoleBinding绑定到Prometheus的服务账户。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: global-reader
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

高级主题

聚合ClusterRole

Kubernetes允许通过标签选择器将多个ClusterRole组合成一个逻辑角色。例如，构建一个"admin"角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admin
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["*"]

权限提升防护

Kubernetes默认阻止以下可能引发权限提升的操作：

• 对`roles`、`clusterroles`等RBAC资源的绑定权限
• 对资源`*`的`*`操作权限
• 跨命名空间的Pod执行（`exec`/`attach`）

调试RBAC

使用`kubectl auth can-i`命令快速检查权限：

# 检查当前用户是否可以删除default命名空间的Pod
kubectl auth can-i delete pods --namespace default

# 模拟特定用户的权限
kubectl auth can-i list nodes --as system:serviceaccount:kube-system:metrics-server

数学表达

RBAC的权限判定可形式化为： $\text{AccessGranted}=\mathrm{\exists }b\in \text{Bindings},\mathrm{\exists }r\in \text{Roles}\mid \text{subject}\in b.\text{subjects}\wedge b.\text{roleRef}=r\wedge \text{action}\in r.\text{rules}[\text{resource}].\text{verbs}$

最佳实践

1. 遵循最小权限原则 2. 优先使用命名空间级别的Role/RoleBinding 3. 定期审计权限（如使用工具`kubectl-who-can`） 4. 为服务账户分配明确角色

通过以上内容，读者可以全面理解Kubernetes RBAC的实现机制与实际应用方法。