3. API Server 认证机制：静态 、X509 证书、ServiceAccount、Webhook 、OIDC

Kubernetes API Server 是集群控制面的唯一入口，所有对集群状态的查询、变更操作都必须经过 API Server。在请求到达授权（RBAC/ABAC）与准入控制之前，认证（Authentication）是第一道防线。API Server 支持多种认证模块，它们以链式方式工作：只要任意一个模块成功验证请求者身份，认证即通过。

3.1 认证模块链与请求处理流程

API Server 启动时，通过 --enable-admission-plugins 和 --authentication--webhook-config-file 等参数配置认证模块。请求到达时，认证模块按以下顺序依次尝试：

1. X509 客户端证书 — 验证 TLS 客户端证书的 CN 和 O 字段。
2. 静态 文件 — 从 ---auth-file 指定的 CSV 文件中匹配 Bearer 。
3. ServiceAccount — 验证挂载到 Pod 中的 JWT 。
4. Webhook — 将 发送到外部认证服务进行验证。
5. OIDC — 通过 OpenID Connect 协议验证 JWT 。
6. 匿名请求 — 如果以上所有模块都拒绝，且未启用 --anonymous-auth=false，则视为匿名请求。

3.2 五种认证机制详解

3.2.1 静态 文件

静态 是最简单的认证方式，适用于测试环境或小规模集群。管理员在 Master 节点上创建一个 CSV 格式的 文件，通过 ---auth-file 参数传递给 API Server。

文件格式：

,username,useruid,group1,group2,...
fL9xK2mN8pQr5sT7,admin,1001,system:masters
aB3cD5eF7gH1iJ2k,developer,2001,dev-team

3.2.2 X509 客户端证书

X509 证书认证是 Kubernetes 最常用的认证方式之一，尤其适用于 kubectl 和集群组件（如 kubelet、scheduler）之间的通信。API Server 通过 --client-ca-file 指定 CA 证书，验证客户端证书的签名。

证书字段映射：

• CN (Common Name) → 用户名
• O (Organization) → 用户所属组（可多个 O 字段）

生成客户端证书示例：

# 生成私钥
openssl genrsa -out dev-user.key 2048

# 生成 CSR，CN 为用户名，O 为组
openssl req -new -key dev-user.key -out dev-user.csr \
  -subj "/CN=dev-user/O=dev-team"

# 使用集群 CA 签发证书
openssl x509 -req -in dev-user.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out dev-user.crt -days 365

3.2.3 ServiceAccount

ServiceAccount 是 Kubernetes 为 Pod 内运行的进程提供的身份标识。每个 Namespace 都有一个默认的 ServiceAccount，Pod 启动时自动将 ServiceAccount 的 挂载到 /var/run/secrets/kubernetes.io/serviceaccount/。

ServiceAccount 认证流程：

1. 创建 ServiceAccount 对象，Kubernetes 自动生成对应的 Secret 并填充 。
2. Pod 通过 serviceAccountName 字段引用 ServiceAccount。
3. API Server 验证 的签名（使用集群私钥）和过期时间。
4. 认证通过后，用户名格式为 system:serviceaccount:<namespace>:<name>，组为 system:serviceaccounts。

创建 ServiceAccount 并分配权限：

# 创建 ServiceAccount
kubectl create serviceaccount my-app-sa -n production

# 查看自动生成的 Secret
kubectl get secret -n production | grep my-app-sa

# 绑定 RBAC 角色
kubectl create rolebinding my-app-sa-binding \
  --clusterrole=view \
  --serviceaccount=production:my-app-sa \
  -n production

3.2.4 Webhook

Webhook 认证允许将 验证委托给外部服务。API Server 将 Bearer 发送到 Webhook 后端，后端返回包含用户信息的响应。适用于集成企业已有的认证系统（如 LDAP、AD、自定义认证服务）。

Webhook 配置示例（webhook-config.yaml）：

apiVersion: v1
kind: Config
clusters:
  - name: auth-service
    cluster:
      server: https://auth.example.com/authenticate
      certificate-authority: /etc/kubernetes/pki/webhook-ca.crt
users:
  - name: apiserver
    user:
      client-certificate: /etc/kubernetes/pki/apiserver.crt
      client-key: /etc/kubernetes/pki/apiserver.key

API Server 启动参数：

--authentication--webhook-config-file=/etc/kubernetes/webhook-config.yaml
--authentication--webhook-cache-ttl=2m

Webhook 响应格式：

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      "username": "john.doe@example.com",
      "uid": "12345",
      "groups": ["developers", "admins"],
      "extra": {
        "department": ["engineering"]
      }
    }
  }
}

3.2.5 OIDC（OpenID Connect）

OIDC 是 Kubernetes 推荐的生产环境认证方式，基于 OAuth 2.0 协议。用户通过外部身份提供方（如 Dex、Keycloak、Azure AD、Google）获取 ID （JWT 格式），然后使用该 访问 API Server。

OIDC 认证流程：

1. 用户通过 kubectl oidc-login 或浏览器登录身份提供方。
2. 身份提供方返回 ID （JWT）和 Refresh 。
3. 用户使用 ID 作为 Bearer 请求 API Server。
4. API Server 验证 的签名（使用 OIDC 提供方的公钥）、issuer、audience 和过期时间。
5. 从 的 sub 或 email 字段提取用户名，从 groups 字段提取组信息。

API Server OIDC 配置参数：

--oidc-issuer-url=https://dex.example.com
--oidc-client-id=kubernetes
--oidc-username-claim=email
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt

3.3 五种认证机制对比

3.4 认证排错与调试

当认证失败时，可以通过以下方法快速定位问题：

• 查看 API Server 日志：kubectl logs -n kube-system kube-apiserver-<node> | grep -i auth
• 使用 curl 测试认证：直接发送请求并查看响应头中的 X-Remote-User 和 X-Remote-Group。
• 检查证书有效期：openssl x509 -in client.crt -text -noout | grep -A2 "Validity"
• 验证 格式：JWT 可通过 jq 解析 Payload 部分确认 claims。

# 使用 X509 证书直接请求 API Server
curl --cert client.crt --key client.key \
  --cacert ca.crt \
  https://api-server:6443/api/v1/namespaces/default/pods

# 使用 Bearer  请求
curl -H "Authorization: Bearer <>" \
  --cacert ca.crt \
  https://api-server:6443/api/v1/namespaces/default/pods

# 查看认证结果（返回的 HTTP 头）
curl -v --cert client.crt --key client.key \
  --cacert ca.crt \
  https://api-server:6443/api/v1/namespaces/default/pods 2>&1 | grep -i "remote"

3.5 生产环境认证选型建议