4、认证与授权机制：ServiceAccount、RBAC、Node 鉴权、Webhook 令牌认证

Kubernetes 控制平面的每一次 API 调用都必须经过严格的认证（Authentication）与授权（Authorization）两道关卡。认证负责确认“你是谁”，授权负责决定“你能做什么”。本章深入剖析四种核心认证与授权机制：ServiceAccount、RBAC、Node 鉴权 和 Webhook 令牌认证，并展示它们如何协同工作以保护 Secrets 等敏感资源。

4.1 认证与授权总览

Kubernetes API Server 的请求处理流水线分为三个阶段：

1. TLS 传输层安全：验证客户端证书，建立加密通道。
2. 认证阶段：从请求中提取身份信息（User、Group、Extra）。
3. 授权阶段：根据身份信息匹配授权策略，决定是否允许操作。

4.2 ServiceAccount：Pod 的身份凭证

ServiceAccount 是 Kubernetes 为 Pod 内进程提供的身份标识。与 User Account 不同，ServiceAccount 由集群管理，而非外部身份提供商管理。

4.2.1 核心属性

属性	说明	默认值
名称	命名空间内唯一标识	default
Secrets	关联的令牌 Secret（自动挂载）	自动创建
ImagePullSecrets	拉取私有镜像的凭据	无
AutomountServiceAccountToken	是否自动挂载令牌到 Pod	true

4.2.2 令牌挂载与生命周期

当 Pod 被创建时，Kubernetes 自动将 ServiceAccount 的 JWT 令牌以卷挂载方式注入到 /var/run/secrets/kubernetes.io/serviceaccount/。该令牌用于向 API Server 发起认证请求。

# 创建自定义 ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production
automountServiceAccountToken: false   # 禁止自动挂载
---
# Pod 引用自定义 ServiceAccount
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  namespace: production
spec:
  serviceAccountName: my-app-sa
  containers:
  - name: app
    image: my-app:latest

4.3 RBAC：基于角色的访问控制

RBAC 是 Kubernetes 最核心的授权机制。它通过 Role（角色）定义权限集合，再通过 RoleBinding 或 ClusterRoleBinding 将角色绑定到用户、组或 ServiceAccount。

4.3.1 核心资源对象

资源	作用域	用途
Role	命名空间	定义对特定命名空间内资源的访问权限
ClusterRole	集群范围	定义集群级别资源（Node、PV、Namespace）或跨命名空间资源的权限
RoleBinding	命名空间	将 Role 绑定到主体（User/Group/SA）
ClusterRoleBinding	集群范围	将 ClusterRole 绑定到主体

4.3.2 RBAC 规则示例

# 定义 Role：允许读取 Secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]
---
# 绑定 Role 到 ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: read-secrets-binding
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: production
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

4.4 Node 鉴权：节点身份的特殊授权

Node 鉴权是一种特殊的授权模式，专门用于 kubelet 节点代理。它自动识别请求来自集群节点，并授予 kubelet 执行其职责所需的最小权限集。

4.4.1 授权范围

• 读取操作：Services、Endpoints、Nodes、Pods、Secrets（仅限绑定到本节点 Pod 的 Secrets）。
• 写入操作：更新本节点状态、Pod 状态、Events。
• 特殊操作：获取绑定到本节点 Pod 的 PersistentVolumeClaims 相关信息。

4.4.2 与 RBAC 的协作

Node 鉴权通常与 RBAC 同时启用。当 kubelet 发起请求时，API Server 先通过 Node 鉴权检查是否属于节点授权范围；如果 Node 鉴权拒绝，则回退到 RBAC 模块继续评估。

# kube-apiserver 启动参数示例
--authorization-mode=Node,RBAC
--enable-admission-plugins=NodeRestriction

4.5 Webhook 令牌认证：外部身份集成

Webhook 令牌认证允许集群管理员将 Kubernetes 认证委托给外部身份服务（如 OIDC、LDAP、自定义认证系统）。API Server 将 Bearer 发送到外部 Webhook 服务，由该服务验证令牌并返回用户身份信息。

4.5.1 工作流程

1. 客户端向 API Server 发起请求，携带 Bearer 。
2. API Server 将 封装为 TokenReview 对象，发送到配置的 Webhook URL。
3. 外部认证服务验证 有效性，返回 TokenReviewStatus，包含 Authenticated 状态、User 信息、Groups。
4. API Server 根据返回的身份信息进入授权阶段。

apiVersion: authentication.k8s.io/v1 格式的 TokenReview 响应。 支持 TLS 双向认证，确保 API Server 与 Webhook 服务之间的通信安全。

4.5.2 配置示例

# kube-apiserver 启动参数
--authentication--webhook-config-file=/etc/kubernetes/webhook-config.yaml
--authentication--webhook-cache-ttl=2m

# webhook-config.yaml 内容
apiVersion: v1
kind: Config
clusters:
- name: external-auth
  cluster:
    server: https://auth.example.com/verify
    certificate-authority: /etc/kubernetes/webhook-ca.pem
users:
- name: apiserver
  user:
    client-certificate: /etc/kubernetes/apiserver-client.pem
    client-key: /etc/kubernetes/apiserver-client-key.pem

4.6 四种机制协同工作场景

在一个生产集群中，四种机制通常同时启用，形成多层防御：

场景	认证方式	授权方式	说明
Pod 内应用读取 Secrets	ServiceAccount 令牌	RBAC（RoleBinding）	应用通过挂载的令牌认证，RBAC 控制可读的 Secrets 范围
kubelet 上报节点状态	X.509 客户端证书	Node 鉴权	节点证书认证后，Node 鉴权自动允许状态更新
外部 CI/CD 工具管理资源	Webhook 令牌认证	RBAC（ClusterRoleBinding）	CI 工具通过 OIDC 令牌认证，RBAC 授予部署权限
管理员执行 kubectl 命令	X.509 证书 / 静态令牌	RBAC + Node 鉴权（回退）	管理员证书认证后，RBAC 授予集群管理权限