Kubernetes授权

Kubernetes授权

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

授权概述

Kubernetes授权发生在身份验证（Authentication）之后，系统通过以下步骤完成授权：

1. 验证请求者的身份（如用户名、组或服务账户）。
2. 检查请求的操作（如GET、POST、DELETE）是否被允许。
3. 根据预定义的规则（如RBAC、ABAC）做出决策。

授权模式需通过kube-apiserver的--authorization-mode参数配置，支持多种机制：

• RBAC（基于角色的访问控制）
• ABAC（基于属性的访问控制）
• Node（节点授权）
• Webhook（外部HTTP回调）

RBAC（基于角色的访问控制）

RBAC是Kubernetes中最常用的授权模式，通过角色（Role）和角色绑定（RoleBinding）定义权限。

核心概念

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

示例：创建Role与RoleBinding

以下示例展示如何允许用户读取默认命名空间中的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"]

# 创建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

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

权限升级防护

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

ABAC（基于属性的访问控制）

ABAC通过静态策略文件定义权限规则，灵活性较低但适合简单场景。策略文件需通过--authorization-policy-file指定。

策略文件示例

{
  "apiVersion": "abac.authorization.8s.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "bob",
    "namespace": "default",
    "resource": "pods",
    "readonly": true
  }
}

Node授权

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

Webhook授权

将授权决策委托给外部HTTP服务，适合与企业IAM系统集成。配置示例：

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

实际案例

场景1：开发团队隔离

为不同团队分配命名空间，通过RBAC限制访问：

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]

场景2：CI/CD流水线权限

为Jenkins服务账户授予部署权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "update", "patch"]

授权检查

使用kubectl auth can-i验证权限：

$ kubectl auth can-i create deployments --as=system:serviceaccount:ci:jenkins
yes

数学表达

授权决策可形式化为： $\text{Authorize}(s,a,r)=\{\begin{array}{ll}\text{true}& \text{if }\mathrm{\exists }p\in P\text{ where }p.\text{subject}=s\wedge p.\text{action}=a\wedge p.\text{resource}=r\\ \text{false}& \text{otherwise}\end{array}$ 其中：

• $s$：主体（Subject）
• $a$：操作（Action）
• $r$：资源（Resource）
• $P$：策略集合

最佳实践

• 遵循最小权限原则
• 定期审计权限（使用kubectl get rolebindings --all-namespaces）
• 避免直接使用cluster-admin
• 为服务账户设置细粒度权限

参见

• Kubernetes认证（Authentication）
• 准入控制器（Admission Controllers）
• 网络策略（Network Policies）