1. Kubernetes权限管理基础概念

在Kubernetes集群中，ServiceAccount和ClusterRole是权限管理的两大核心组件。ServiceAccount为运行在Pod中的进程提供身份标识，而ClusterRole则定义了一组权限规则。这两者的结合使用，可以实现精细化的访问控制。

ServiceAccount不同于UserAccount，它专为集群内部工作负载设计。每个命名空间都会自动创建一个default ServiceAccount，但生产环境中我们通常需要创建专用的ServiceAccount来实现最小权限原则。

ClusterRole与Role的主要区别在于作用范围：ClusterRole是集群级别的资源，可以定义对整个集群资源的访问权限；而Role仅限于单个命名空间内。当我们需要定义跨命名空间的权限时，ClusterRole是更合适的选择。

2. 创建专用ServiceAccount

2.1 基本创建方法

创建一个专用的ServiceAccount是权限管理的第一步。以下是创建一个名为"api-client"的ServiceAccount的YAML示例：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-client
  namespace: default

应用这个配置后，Kubernetes会自动生成一个对应的Secret，其中包含用于身份验证的token。可以通过以下命令查看：

kubectl get serviceaccount api-client -n default -o yaml

2.2 高级配置选项

在实际生产环境中，我们可能需要对ServiceAccount进行更精细的控制：

1. 自动挂载设置 ：可以禁用自动挂载API凭据

automountServiceAccountToken: false

2. ImagePullSecrets ：为私有镜像仓库配置拉取密钥

imagePullSecrets:
- name: my-registry-key

3. 注解和标签 ：添加元数据便于管理

metadata:
  labels:
    app: api-service
  annotations:
    description: "Service account for API server access"

3. 设计自定义ClusterRole

3.1 ClusterRole规则定义

ClusterRole通过rules字段定义权限规则。每个rule指定一组API资源及其允许的操作。以下是一个允许读取Pod和Service的ClusterRole示例：

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

3.2 常用verbs与资源组合

根据不同的访问需求，常见的verbs组合包括：

1. 只读权限 ：

verbs: ["get", "list", "watch"]

2. 读写权限 ：

verbs: ["create", "get", "list", "update", "delete"]

3. 管理权限 ：

verbs: ["*"]

对于不同的资源类型，常见的组合有：

• 对Pods的完整管理权限
• 对ConfigMaps和Secrets的读写权限
• 对Nodes的只读权限
• 对特定CRD的操作权限

4. 绑定ServiceAccount与ClusterRole

4.1 ClusterRoleBinding创建

将ClusterRole绑定到ServiceAccount需要使用ClusterRoleBinding资源。以下是一个绑定示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: api-client-binding
subjects:
- kind: ServiceAccount
  name: api-client
  namespace: default
roleRef:
  kind: ClusterRole
  name: api-reader
  apiGroup: rbac.authorization.k8s.io

4.2 绑定范围控制

根据不同的安全需求，可以选择不同的绑定策略：

1. 集群范围绑定 ：使用ClusterRoleBinding，适用于需要跨命名空间访问的场景。

2. 命名空间范围绑定 ：使用RoleBinding引用ClusterRole，将权限限制在特定命名空间内：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: api-client-ns-binding
  namespace: development
subjects:
- kind: ServiceAccount
  name: api-client
  namespace: default
roleRef:
  kind: ClusterRole
  name: api-reader
  apiGroup: rbac.authorization.k8s.io

5. 测试与验证权限配置

5.1 使用kubectl验证权限

创建好ServiceAccount后，可以通过以下步骤测试其权限：

1. 获取ServiceAccount的token：

kubectl get secret $(kubectl get serviceaccount api-client -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode

2. 使用token配置kubectl：

kubectl config set-credentials api-client --token=<上面获取的token>
kubectl config set-context api-client-context --cluster=<your-cluster> --user=api-client

3. 切换上下文并测试权限：

kubectl config use-context api-client-context
kubectl get pods # 应该能成功
kubectl delete pod <pod-name> # 根据权限配置可能失败

5.2 使用API直接访问

对于需要通过API直接访问的场景，可以使用以下curl命令测试：

APISERVER=https://kubernetes.default.svc
TOKEN=$(kubectl get secret $(kubectl get serviceaccount api-client -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode)
curl $APISERVER/api/v1/namespaces/default/pods --header "Authorization: Bearer $TOKEN" --insecure

6. 生产环境最佳实践

6.1 安全加固建议

1. 最小权限原则 ：只授予必要的权限，定期审计权限使用情况。

2. 定期轮换token ：Kubernetes 1.24+版本支持手动管理ServiceAccount token，建议定期更新。

3. 使用命名空间隔离 ：为不同团队/项目使用不同的命名空间和ServiceAccount。

4. 禁用默认ServiceAccount ：对于不需要API访问的Pod，设置 automountServiceAccountToken: false 。

6.2 常见问题排查

1. 权限不足错误 ：

   • 检查ClusterRole定义的verbs是否包含所需操作
   • 确认绑定关系是否正确建立
   • 检查是否在正确的命名空间

2. 认证失败 ：

   • 确认token是否正确
   • 检查ServiceAccount是否存在
   • 验证API服务器证书

3. 资源不可见 ：

   • 检查ClusterRole的resources字段
   • 确认apiGroups是否正确
   • 检查命名空间限制

7. 高级配置场景

7.1 聚合ClusterRole

Kubernetes支持通过标签选择器将多个ClusterRole聚合在一起：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-aggregated
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 自动填充

7.2 自定义资源权限

对于CRD(Custom Resource Definition)，需要在ClusterRole中明确指定：

rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["*"]

7.3 限制特定资源实例

可以通过resourceNames字段限制对特定资源实例的访问：

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"]
  verbs: ["get"]

8. 自动化管理工具

8.1 使用kubectl插件

可以创建bash脚本或kubectl插件来简化ServiceAccount管理：

#!/bin/bash
# create-sa.sh <name> <namespace>
kubectl create serviceaccount $1 -n $2
kubectl create clusterrole $1-role --verb=get,list --resource=pods,services
kubectl create clusterrolebinding $1-binding \
  --serviceaccount=$2:$1 \
  --clusterrole=$1-role

8.2 Terraform管理

使用Terraform的Kubernetes provider可以实现IaC方式的权限管理：

resource "kubernetes_service_account" "api_client" {
  metadata {
    name = "api-client"
    namespace = "default"
  }
}

resource "kubernetes_cluster_role" "api_reader" {
  metadata {
    name = "api-reader"
  }
  
  rule {
    api_groups = [""]
    resources  = ["pods", "services"]
    verbs      = ["get", "list", "watch"]
  }
}

resource "kubernetes_cluster_role_binding" "api_binding" {
  metadata {
    name = "api-client-binding"
  }
  
  subject {
    kind      = "ServiceAccount"
    name      = kubernetes_service_account.api_client.metadata[0].name
    namespace = "default"
  }
  
  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = kubernetes_cluster_role.api_reader.metadata[0].name
  }
}

9. 监控与审计

9.1 权限使用审计

启用Kubernetes审计日志可以跟踪ServiceAccount的API访问：

# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets"]

9.2 使用RBAC Lookup

安装rbac-lookup工具可以快速查看权限分配情况：

kubectl rbac-lookup api-client -n default

输出示例：

SUBJECT           SCOPE          ROLE
api-client        cluster-wide   ClusterRole/api-reader

10. 实际应用案例

10.1 CI/CD系统集成

为Jenkins创建专用ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins
  namespace: ci-cd

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: jenkins-deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["*"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: jenkins-binding
subjects:
- kind: ServiceAccount
  name: jenkins
  namespace: ci-cd
roleRef:
  kind: ClusterRole
  name: jenkins-deployer
  apiGroup: rbac.authorization.k8s.io

10.2 监控系统访问

为Prometheus配置只读权限：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: monitoring

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-reader
rules:
- apiGroups: [""]
  resources:
  - nodes
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: ["extensions", "networking.k8s.io"]
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-binding
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: prometheus-reader
  apiGroup: rbac.authorization.k8s.io

在配置Kubernetes权限时，我发现遵循"最小权限原则"能显著提高集群安全性。一开始可能会觉得精细的权限管理麻烦，但随着集群规模扩大，这种前期投入会带来长期的安全和管理收益。特别是在多团队共享的集群环境中，合理的ServiceAccount和ClusterRole设计是确保稳定运行的关键。