16.7.1 RBAC权限模型与角色绑定

RBAC权限模型与角色绑定#

Kubernetes 通过 RBAC 将“用户/服务账户”与“角色/角色绑定”关联，实现最小权限原则。核心对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

原理草图（认证→授权）#

RBAC 启用与检查（安装/配置）#

Kubeadm 默认启用 RBAC，若为自建组件需检查 API Server 参数：

# 检查 kube-apiserver 是否启用 RBAC 授权
ps -ef | grep kube-apiserver | grep authorization-mode

# 预期包含：--authorization-mode=Node,RBAC

解释：authorization-mode 包含 RBAC 才会执行角色授权判断。

核心概念与作用域#

Role：命名空间级权限集合，仅作用于特定命名空间内的资源。
ClusterRole：集群级权限集合，适用于全局资源或跨命名空间资源。
RoleBinding：将 Role 绑定到某个用户/组/ServiceAccount，仅在指定命名空间生效。
ClusterRoleBinding：将 ClusterRole 绑定到用户/组/ServiceAccount，在全集群生效。

示例一：命名空间只读角色（含完整可执行 YAML）#

目标：让 dev-sa 在 dev 命名空间只读 Pod 与 Deployment。

# 1) 创建命名空间与 ServiceAccount
kubectl create ns dev
kubectl -n dev create sa dev-sa

# 2) 创建 Role 与 RoleBinding
cat > /tmp/dev-readonly.yaml <<'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-readonly
  namespace: dev
rules:
- apiGroups: [""]
  resources: ["pods","services","configmaps"]
  verbs: ["get","list","watch"]
- apiGroups: ["apps"]
  resources: ["deployments","replicasets"]
  verbs: ["get","list","watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-readonly-bind
  namespace: dev
subjects:
- kind: ServiceAccount
  name: dev-sa
  namespace: dev
roleRef:
  kind: Role
  name: dev-readonly
  apiGroup: rbac.authorization.k8s.io
EOF

kubectl apply -f /tmp/dev-readonly.yaml

命令解释：
- Role 定义可访问资源与动词（get/list/watch）。
- RoleBinding 绑定角色到 dev-sa，作用域仅 dev。

验证权限：

# 使用 can-i 模拟授权检查
kubectl auth can-i get pods -n dev --as=system:serviceaccount:dev:dev-sa
kubectl auth can-i delete pods -n dev --as=system:serviceaccount:dev:dev-sa

预期：get pods 为 yes，delete pods 为 no。

示例二：集群级只读节点（ClusterRole + ClusterRoleBinding）#

目标：运维审计账号只读 nodes。

# 1) 创建 ClusterRole
cat > /tmp/audit-nodes.yaml <<'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: audit-nodes
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get","list","watch"]
EOF
kubectl apply -f /tmp/audit-nodes.yaml

# 2) 绑定到用户（假设用户为 audit-user）
cat > /tmp/audit-nodes-bind.yaml <<'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: audit-nodes-bind
subjects:
- kind: User
  name: audit-user
roleRef:
  kind: ClusterRole
  name: audit-nodes
  apiGroup: rbac.authorization.k8s.io
EOF
kubectl apply -f /tmp/audit-nodes-bind.yaml

说明：ClusterRoleBinding 为集群级授权，谨慎使用。

角色设计策略#

最小权限：避免 * 动词与资源。
命名空间隔离：开发/测试/生产使用不同 Role/Binding。
复用 ClusterRole：公共模板在多命名空间通过 RoleBinding 复用。
审计与回收：定期清理不再使用的绑定关系。
限制 cluster-admin：仅限极少数平台管理员。

常见问题与排错#

# 1) 没权限访问资源：检查 Role/Binding 是否存在
kubectl -n dev get role,rolebinding

# 2) 检查权限解析结果
kubectl auth can-i create deployments -n dev --as=system:serviceaccount:dev:dev-sa

# 3) 查看绑定对象是否正确（subjects/roleRef）
kubectl -n dev describe rolebinding dev-readonly-bind

# 4) 检查是否误用 ClusterRoleBinding 导致过高权限
kubectl get clusterrolebinding | grep dev-sa

练习题#

在 test 命名空间创建一个仅允许 create/update Deployment 的 Role，并绑定到 test-sa。
使用 kubectl auth can-i 验证 test-sa 对 secrets 是否有权限，并给出结论。
将 dev-readonly 权限扩展为允许读取 pods/log，并验证生效结果。