📚 课程目录第2章 K8s安全基础

2. K8s安全基础：RBAC原理、ServiceAccount、用户与组、Kubeconfig配置

在构建多租户Kubernetes集群的安全防线时，认证（Authentication）与授权（Authorization）是两大基石。本章将深入解析K8s的权限控制模型，涵盖RBAC原理、ServiceAccount、用户与组的概念，以及如何通过Kubeconfig配置管理访问凭证。

2.1 Kubernetes访问控制全景

K8s API Server是所有管理操作的唯一入口。每一次请求都必须经过三个阶段的检查：

认证（Authentication）：验证请求者身份（谁在访问？）。
授权（Authorization）：判断请求者是否有权限执行操作（能做什么？）。
准入控制（Admission Control）：在对象持久化前进行策略校验（是否合规？）。

本章聚焦前两个阶段，为后续的Pod安全策略与准入控制配置打下基础。

2.2 RBAC原理与核心资源

基于角色的访问控制（RBAC）是K8s默认且推荐的授权模式。它通过四个核心资源对象实现细粒度权限管理：

资源对象	作用域	作用
Role	命名空间（Namespace）	定义一组权限规则，如对Pod、Service的get/list/create操作
ClusterRole	集群级别	定义集群范围资源的权限，如Node、PV、ClusterRole本身
RoleBinding	命名空间（Namespace）	将Role绑定到用户、组或ServiceAccount
ClusterRoleBinding	集群级别	将ClusterRole绑定到用户、组或ServiceAccount

最佳实践：在多租户场景中，优先使用Role + RoleBinding进行命名空间级别的权限隔离。仅当需要跨命名空间或集群级别权限时，才使用ClusterRole和ClusterRoleBinding。

2.3 RBAC权限规则示例

以下是一个典型的Role定义，允许对Pod和Deployment进行读写操作：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-alpha
  name: pod-manager
rules:
- apiGroups: [""]           # 核心API组
  resources: ["pods"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update"]

将上述Role绑定到用户：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: team-alpha
  name: pod-manager-binding
subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: rbac.authorization.k8s.io

2.4 ServiceAccount：Pod的身份凭证

ServiceAccount是K8s中为Pod提供身份标识的机制。与普通用户不同，ServiceAccount由K8s API管理，通常用于Pod与API Server之间的通信。

特性	User（用户）	ServiceAccount
管理方式	外部CA或证书管理	K8s API原生管理
生命周期	独立于Pod	通常与Pod关联
默认绑定	无	每个命名空间自动创建default ServiceAccount
凭证存储	Kubeconfig文件	自动挂载为Secret卷
典型用途	管理员、CI/CD系统	Pod内应用访问API Server

安全警告：默认情况下，每个命名空间中的default ServiceAccount会被自动挂载到所有Pod中。在多租户环境中，建议显式设置automountServiceAccountToken: false，或为每个工作负载创建专用的ServiceAccount并绑定最小权限。

2.5 用户与组的概念

K8s本身不管理用户对象，而是依赖外部身份系统。理解以下概念至关重要：

普通用户（User）：由外部CA签发的证书中的CN字段标识，或由OIDC、Webhook 等认证代理提供。
组（Group）：由证书中的O字段（Organization）标识，或由认证代理提供。组用于批量授权。
ServiceAccount：格式为 system:serviceaccount:<namespace>:<name>，自动属于 system:serviceaccounts 和 system:serviceaccounts:<namespace> 组。

2.6 Kubeconfig配置详解

Kubeconfig是K8s客户端（kubectl、SDK）用于连接集群的配置文件，默认路径为 ~/.kube/config。它包含三个核心部分：

配置段	字段	说明
clusters	server, certificate-authority-data	定义集群API Server地址和CA证书
users	client-certificate-data, client-key-data,	定义客户端身份凭证（证书或）
contexts	cluster, user, namespace	将集群、用户、命名空间组合为一个上下文

一个典型的Kubeconfig文件结构：

apiVersion: v1
kind: Config
current-context: dev-context
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRV...  # Base64编码的CA证书
    server: https://192.168.1.100:6443
  name: production-cluster
users:
- name: admin-user
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRV...  # 客户端证书
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJ...    # 客户端私钥
contexts:
- context:
    cluster: production-cluster
    user: admin-user
    namespace: team-alpha
  name: dev-context

  多租户配置技巧：可以为每个租户创建独立的Kubeconfig上下文，通过kubectl config use-context <context-name>快速切换。例如：

  kubectl config set-context tenant-alpha --cluster=prod --user=alice --namespace=team-alpha

2.7 实战：创建ServiceAccount并绑定RBAC

以下步骤演示如何为CI/CD系统创建一个专用的ServiceAccount，并授予其在指定命名空间内的Pod管理权限：

创建ServiceAccount

kubectl create serviceaccount cicd-bot -n team-alpha

创建Role

kubectl create role pod-reader -n team-alpha \
  --verb=get,list,watch \
  --resource=pods

创建RoleBinding

kubectl create rolebinding cicd-bot-binding -n team-alpha \
  --role=pod-reader \
  --serviceaccount=team-alpha:cicd-bot

获取ServiceAccount的

kubectl get secret $(kubectl get sa cicd-bot -n team-alpha -o jsonpath='{.secrets[0].name}') \
  -n team-alpha -o jsonpath='{.data.}' | base64 --decode

配置Kubeconfig使用认证

kubectl config set-credentials cicd-bot-user --=<>
kubectl config set-context cicd-context --cluster=prod --user=cicd-bot-user --namespace=team-alpha
kubectl config use-context cicd-context

生产建议：在K8s 1.24+版本中，ServiceAccount的Secret不再自动生成。推荐使用kubectl create cicd-bot -n team-alpha创建绑定，或使用TokenRequest API获取具有过期时间的短期。

2.8 本章小结

RBAC是K8s授权的核心机制，通过Role/ClusterRole定义权限，通过RoleBinding/ClusterRoleBinding将权限授予用户、组或ServiceAccount。
ServiceAccount是Pod的身份凭证，应遵循最小权限原则，避免使用默认的default ServiceAccount。
用户与组由外部系统管理，K8s通过证书字段或认证代理识别身份。
Kubeconfig是客户端连接集群的配置标准，通过context实现多集群、多租户的便捷切换。