编辑“︁Kubernetes授权”︁（章节）

= Kubernetes授权 =

'''Kubernetes授权'''（Authorization）是Kubernetes安全机制的核心组成部分，用于控制用户、服务账户或进程对集群资源的访问权限。授权系统决定了一个主体（如用户或Pod）是否有权限执行特定操作（如创建、读取、更新或删除资源）。

== 授权概述 ==
Kubernetes授权发生在'''身份验证'''（Authentication）之后，系统通过以下步骤完成授权：
# 验证请求者的身份（如用户名、组或服务账户）。
# 检查请求的操作（如GET、POST、DELETE）是否被允许。
# 根据预定义的规则（如RBAC、ABAC）做出决策。

授权模式需通过kube-apiserver的<code>--authorization-mode</code>参数配置，支持多种机制：
* '''RBAC'''（基于角色的访问控制）
* '''ABAC'''（基于属性的访问控制）
* '''Node'''（节点授权）
* '''Webhook'''（外部HTTP回调）

== RBAC（基于角色的访问控制） ==
RBAC是Kubernetes中最常用的授权模式，通过角色（Role）和角色绑定（RoleBinding）定义权限。

=== 核心概念 ===
* '''Role'''：定义在特定命名空间中的权限集合。
* '''ClusterRole'''：定义集群范围的权限集合。
* '''RoleBinding'''：将角色绑定到主体（用户/组/服务账户）。
* '''ClusterRoleBinding'''：将集群角色绑定到主体。

=== 示例：创建Role与RoleBinding ===
以下示例展示如何允许用户读取默认命名空间中的Pod信息：

<syntaxhighlight lang="yaml">
# 创建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">
# 创建RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
</syntaxhighlight>

执行绑定后，用户alice可通过<code>kubectl get pods</code>查看Pod，但无法修改或删除。

=== 权限升级防护 ===
Kubernetes默认阻止用户通过RBAC自我提升权限。例如，普通用户无法为自己绑定<code>cluster-admin</code>角色。

== ABAC（基于属性的访问控制） ==
ABAC通过静态策略文件定义权限规则，灵活性较低但适合简单场景。策略文件需通过<code>--authorization-policy-file</code>指定。

=== 策略文件示例 ===
<syntaxhighlight lang="json">
{
  "apiVersion": "abac.authorization.8s.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "bob",
    "namespace": "default",
    "resource": "pods",
    "readonly": true
  }
}
</syntaxhighlight>

== Node授权 ==
专用于kubelet的授权模式，允许节点访问必要的API（如自身Pod信息）。需配合NodeRestriction准入控制器使用。

== Webhook授权 ==
将授权决策委托给外部HTTP服务，适合与企业IAM系统集成。配置示例：
<syntaxhighlight lang="yaml">
apiVersion: v1
kind: Config
clusters:
- name: auth-service
  cluster:
    server: https://auth.example.com
contexts:
- context:
    cluster: auth-service
    user: api-server
  name: webhook
current-context: webhook
</syntaxhighlight>

== 实际案例 ==
=== 场景1：开发团队隔离 ===
为不同团队分配命名空间，通过RBAC限制访问：
<mermaid>
graph LR
    A[Team A] -->|RoleBinding| B[Role: ns-a-admin]
    C[Team B] -->|RoleBinding| D[Role: ns-b-reader]
    B --> E[Namespace A]
    D --> F[Namespace B]
</mermaid>

=== 场景2：CI/CD流水线权限 ===
为Jenkins服务账户授予部署权限：
<syntaxhighlight lang="yaml">
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "update", "patch"]
</syntaxhighlight>

== 授权检查 ==
使用<code>kubectl auth can-i</code>验证权限：
<syntaxhighlight lang="bash">
$ kubectl auth can-i create deployments --as=system:serviceaccount:ci:jenkins
yes
</syntaxhighlight>

== 数学表达 ==
授权决策可形式化为：
<math>
\text{Authorize}(s, a, r) = \begin{cases}
\text{true} & \text{if } \exists p \in P \text{ where } p.\text{subject} = s \land p.\text{action} = a \land p.\text{resource} = r \\
\text{false} & \text{otherwise}
\end{cases}
</math>
其中：
* <math>s</math>：主体（Subject）
* <math>a</math>：操作（Action）
* <math>r</math>：资源（Resource）
* <math>P</math>：策略集合

== 最佳实践 ==
* 遵循最小权限原则
* 定期审计权限（使用<code>kubectl get rolebindings --all-namespaces</code>）
* 避免直接使用<code>cluster-admin</code>
* 为服务账户设置细粒度权限

== 参见 ==
* Kubernetes认证（Authentication）
* 准入控制器（Admission Controllers）
* 网络策略（Network Policies）

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