在 Kubernetes RBAC 认证授权详解Kubernetes 集群中，安全控制至关重要，其中认证、授权和准入控制构成了三层安全防线。本文将重点解析基于角色的访问控制（RBAC）机制，帮助你理解如何在 K8s 中实现精细化的权限管理。

一、K8s 安全架构概述

Kubernetes 集群的所有访问都通过 kube-apiserver 进行，任何请求都需要经过三个阶段的检查：

1. 认证（Authentication）：验证客户端身份，确认 "你是谁"
2. 授权（Authorization）：检查权限，决定 "你能做什么"
3. 准入控制（Admission Control）：对请求进行额外验证和修改，在对象持久化前生效

认证机制

K8s 支持多种认证方式：

• 令牌（Token）认证：基于共享密钥的对称认证
• SSL/TLS 认证：双向证书验证，确保通信双方身份

K8s 中有两类账号：

• User Account：面向人类用户的账号，跨命名空间
• Service Account：面向 Pod 中进程的账号，属于特定命名空间，每个命名空间默认创建一个 default 服务账号

查看当前 Pod 使用的服务账号：

shell

kubectl get pods <pod-name> -o yaml | grep "serviceAccountName"

二、RBAC 授权机制

RBAC（基于角色的访问控制）是 K8s 推荐的授权方式，通过将权限分配给角色，再将角色绑定给用户，实现灵活的权限管理。

RBAC 包含四个核心资源对象：

1. Role（角色）

命名空间级别的权限集合，仅对所属命名空间有效。

示例：创建一个能读取 Pod 的角色

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac
  name: pod-read
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

2. ClusterRole（集群角色）

集群级别的权限集合，可用于：

• 集群范围的资源（如 Node）
• 非资源型路径（如 /healthz）
• 所有命名空间的资源

示例：创建一个能访问所有 Secrets 的集群角色

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

3. RoleBinding（角色绑定）

将角色绑定到用户，仅在当前命名空间有效。可以绑定 Role 或 ClusterRole，但绑定 ClusterRole 时也仅对当前命名空间生效。

示例：将 pod-read 角色绑定给用户 es

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-read-bind
  namespace: rbac
subjects:
- kind: User
  name: es
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-read
  apiGroup: rbac.authorization.k8s.io

4. ClusterRoleBinding（集群角色绑定）

将 ClusterRole 绑定到用户，在整个集群范围内有效。

三、资源引用方式

在 RBAC 规则中，资源可以通过以下方式引用：

1. 基础资源引用：直接使用资源名称，如 "pods"、"deployments"
2. 上下级资源引用：使用 "/" 分割，如 "pods/log"
3. 特定资源实例：通过 resourceNames 指定具体资源名称

示例：授权访问特定 ConfigMap

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-update
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["get", "update"]

查看集群支持的资源类型：

kubectl api-resources

四、常见角色绑定示例

绑定不同类型的主体：

1. 用户绑定

subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io

1. 组绑定

subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io

1. 服务账号绑定

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

1. 所有认证用户

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

五、Service Account 授权管理

为服务账号授权的常见场景：

1. 为特定服务账号授权

kubectl create rolebinding my-sa-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:my-sa \
  --namespace=my-namespace

1. 为命名空间默认服务账号授权

kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:default \
  --namespace=my-namespace

1. 为命名空间所有服务账号授权

kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

六、实战：创建受限用户

下面演示如何创建一个只能操作特定命名空间的用户：

1. 生成证书和私钥

cd /etc/kubernetes/pki/
umask 077; openssl genrsa -out lucky.key 2048
openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650

1. 添加用户到 kubeconfig

kubectl config set-credentials lucky \
  --client-certificate=./lucky.crt \
  --client-key=./lucky.key \
  --embed-certs=true

kubectl config set-context lucky@kubernetes \
  --cluster=kubernetes \
  --user=lucky

1. 切换到新用户（此时无任何权限）

kubectl config use-context lucky@kubernetes

1. 为用户授权特定命名空间权限

kubectl create ns lucky
kubectl create rolebinding lucky -n lucky \
  --clusterrole=cluster-admin \
  --user=lucky

1. 验证权限

# 在授权的命名空间有操作权限
kubectl get pods -n lucky

# 在其他命名空间无权限
kubectl get pods -n default  # 会报错

总结

RBAC 提供了灵活且强大的权限管理机制，通过角色和绑定的组合，可以实现精细化的访问控制。在实际使用中，应遵循最小权限原则，为每个用户或服务账号只分配必要的权限，以提高集群的安全性。

合理规划 RBAC 权限不仅能保护集群资源安全，还能规范团队协作流程，是 Kubernetes 集群管理的重要组成部分。