Kubernetes集群RBAC权限控制与ServiceAccount安全配置实战

Kubernetes RBAC（Role-Based Access Control）是集群权限管理的核心机制，通过Role定义权限、通过Binding将权限绑定到用户或服务账户。在多租户集群和DevOps实践中，合理的RBAC配置直接决定集群安全边界。本文围绕Kubernetes容器编排场景下的权限隔离需求，详细拆解ServiceAccount、Role、Binding的配置方法和生产环境安全加固方案。

Kubernetes RBAC权限模型与API对象

K8s RBAC包含四个核心API对象：

# 查看集群已有RBAC对象
kubectl get roles,clusterroles,rolebindings,clusterrolebindings -A

# RBAC对象层级关系
ClusterRole -> ClusterRoleBinding -> User/Group/ServiceAccount（集群级别）
Role -> RoleBinding -> User/Group/ServiceAccount（命名空间级别）

Role和ClusterRole的区别在于作用范围：Role限定在单个Namespace，ClusterRole对全集群生效。ClusterRole可以通过RoleBinding绑定到特定Namespace，实现”定义一次，多处使用”。权限规则由verbs（操作类型）、resources（资源类型）、resourceNames（具体资源名）三个维度组成。

常用verbs包括：get、list、watch、create、update、patch、delete、deletecollection。使用kubectl auth can-i快速验证权限：

# 检查当前用户是否有权限
kubectl auth can-i create pods -n production

# 检查指定ServiceAccount的权限
kubectl auth can-i list secrets -n production --as=system:serviceaccount:production:ci-bot

# 查看权限来源
kubectl auth can-i get pods --list --as=system:serviceaccount:production:ci-bot

ServiceAccount配置与Token管理

ServiceAccount是K8s中服务级别的身份标识。每个Namespace自动创建default ServiceAccount，但生产环境不应使用default，需为每个应用创建独立SA：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service-sa
  namespace: production
  annotations:
    # K8s 1.24+使用TokenRequest API自动管理Token
    # 不再自动生成Secret，按需创建短期Token
automountServiceAccountToken: false  # 默认不自动挂载Token

---
apiVersion: v1
kind: Secret
metadata:
  name: order-service-token
  namespace: production
  annotations:
    kubernetes.io/service-account.name: order-service-sa
type: kubernetes.io/service-account-token

K8s 1.24+移除了自动生成长效Token的机制，改用TokenRequest API生成短期Token（默认1小时过期）。长期Token需手动创建Secret绑定。对于CI/CD场景推荐使用短期Token：

# 生成短期Token（1小时有效）
kubectl create token order-service-sa -n production --duration=1h

# 生成带受众限制的Token
kubectl create token order-service-sa -n production   --audience=vault   --duration=24h

Pod使用指定ServiceAccount：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: production
spec:
  template:
    spec:
      serviceAccountName: order-service-sa
      automountServiceAccountToken: true  # 此Pod需要访问API Server

Role与ClusterRole权限定义

命名空间级别的Role定义示例，为CI/CD机器人授予部署权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ci-deployer
  namespace: production
rules:
# 允许管理Deployment
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
# 允许管理Pod（查看日志、exec）
- apiGroups: [""]
  resources: ["pods", "pods/log", "pods/exec"]
  verbs: ["get", "list", "watch"]
# 允许管理ConfigMap和Secret（仅限指定名称）
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "create", "update"]
  resourceNames: ["order-service-config", "order-service-env"]
# 允许重启Deployment（滚动更新触发）
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["patch"]
  resourceNames: ["order-service", "payment-service"]

集群级别的ClusterRole定义示例，用于只读监控：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "nodes/metrics", "namespaces", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "list"]
- nonResourceURLs: ["/metrics", "/healthz"]
  verbs: ["get"]

RoleBinding与ClusterRoleBinding绑定配置

将Role绑定到ServiceAccount：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deployer-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: order-service-sa
  namespace: production
roleRef:
  kind: Role
  name: ci-deployer
  apiGroup: rbac.authorization.k8s.io

利用ClusterRole+RoleBinding实现跨Namespace复用权限定义。创建一个ClusterRole后，在各Namespace创建RoleBinding引用它：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: staging
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole    # 引用ClusterRole
  name: monitoring-reader
  apiGroup: rbac.authorization.k8s.io

使用aggregationRule组合多个ClusterRole，适合按职能拆分权限后聚合：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: full-reader
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-full-reader: "true"
rules: []  # 自动聚合匹配的ClusterRole权限

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
  labels:
    rbac.example.com/aggregate-to-full-reader: "true"
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

生产环境权限隔离方案

多租户集群的权限隔离原则：每个Namespace对应一个租户或团队，每个应用使用独立ServiceAccount，禁止跨Namespace共享SA。

权限审计方法：

# 列出所有RoleBinding及其关联的SA
kubectl get rolebinding -A -o json | jq '.items[] | {
  ns: .metadata.namespace,
  name: .metadata.name,
  subjects: .subjects
}'

# 检查某SA的全部权限
kubectl auth can-i --list --as=system:serviceaccount:production:order-service-sa -n production

# 查找拥有cluster-admin的绑定
kubectl get clusterrolebinding -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name'

最小权限原则落地：先用kubectl auth can-i –list确认当前权限，逐步裁剪非必要权限。对于只需读取的组件，使用view或edit等系统内置ClusterRole，不自行创建。Secret访问严格控制，通过resourceNames限定可访问的具体Secret名称，避免列表级泄露。

Token轮换策略：K8s 1.24+默认Token含过期时间，长期Token需定期轮换。结合外部密钥管理（如HashiCorp Vault）实现Token的自动签发和轮换，减少人工维护成本。