编辑“︁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示例：

<syntaxhighlight lang="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"]
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# 示例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
</syntaxhighlight>

== 权限规则详解 ==

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将角色绑定到团队成员。

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

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

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

== 高级主题 ==

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

<syntaxhighlight lang="yaml">
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: ["*"]
</syntaxhighlight>

=== 权限提升防护 ===
Kubernetes默认阻止以下可能引发权限提升的操作：
* 对`roles`、`clusterroles`等RBAC资源的绑定权限
* 对资源`*`的`*`操作权限
* 跨命名空间的Pod执行（`exec`/`attach`）

== 调试RBAC ==

使用`kubectl auth can-i`命令快速检查权限：
<syntaxhighlight lang="bash">
# 检查当前用户是否可以删除default命名空间的Pod
kubectl auth can-i delete pods --namespace default

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

== 数学表达 ==

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

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

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

[[Category:集成部署]]
[[Category:Kubernetes]]
[[Category:Kubernetes安全]]