对 Kubernetes 有点了解的朋友可能知道，访问 Kubernetes 集群通常有三种主要方式：使用 kubectl（命令行工具）、通过 Dashboard（仪表盘）界面操作，或者编写程序直接调用 RESTful API。但无论采用哪种方式，所有与集群的交互请求都必须首先到达 API Server。

然而，并非所有到达 API Server 的请求都会被允许执行。请求需要经过三个关键的安全检查阶段：认证（Authentication）、鉴权（Authorization） 和 准入控制（Admission Control）。这三个阶段共同构成了 Kubernetes 访问控制的核心机制，确保只有合法且合规的请求才能对集群资源进行操作。

本篇主要围绕 认证阶段 展开介绍。

一、从访问入口说起

在日常使用 Kubernetes 时，我们通常通过以下几种方式与集群交互：

• 使用 kubectl 命令行工具

• 通过 Dashboard 可视化界面

• 调用 RESTful API

无论采用哪种方式，所有请求最终都会汇聚到 Kubernetes 的核心组件：API Server。

不过，API Server 并不会直接执行请求，而是会先进行一系列安全校验。整个流程可以抽象为：

请求 → 认证 → 鉴权 → 准入控制 → 执行

这也是 Kubernetes 安全体系的核心链路。

---

二、Kubernetes 的 3A 安全模型

Kubernetes 的访问控制机制可以用经典的 3A 模型来理解。

1. 认证（Authentication）

解决的问题：你是谁？

用于确认请求的身份是否合法。

类比：进入公司大楼需要刷工卡验证身份。

---

2. 鉴权（Authorization）

解决的问题：你能做什么？

在确认身份后，系统判断该用户是否具备执行某个操作的权限。

类比：是否有权限进入某一层办公区域。

---

3. 准入控制（Admission Control）

解决的问题：你的操作是否符合规则？

即使具备权限，请求仍需要通过策略校验。

类比：某些敏感操作需要额外审批。

---

这三个阶段全部由 API Server 统一处理，是 Kubernetes 的第一道安全防线。

---

三、认证方式详解

Kubernetes 提供了多种认证方式，安全级别逐步提升。

1. Token 认证

原理：通过一个字符串（Token）标识用户身份。

Authorization: Bearer <token>

特点：

• 实现简单

• 适用于测试或内部环境

• 安全性较低

---

2. Basic 认证

原理：将“用户名:密码”进行 Base64 编码后传输。

Authorization: Basic base64(username:password)

特点：

• 使用方便

• Base64 不是加密，仅是编码

• 存在被解码风险

---

3. HTTPS 证书认证

基于 CA 签发的证书进行身份验证。

                             

单向认证

客户端验证服务端身份，常见于普通网站访问。

双向认证

客户端和服务端互相验证身份，常见于金融系统等高安全场景。

特点：

• 安全级别最高

• 双方都需要证书

生产环境通常推荐使用证书认证。

---

四、API Server 的认证策略

不同组件访问 API Server 的方式有所不同。

1. 集群核心组件

例如：

• Controller Manager

• Scheduler

特点：

• 通常与 API Server 在同一节点

• 通过本地地址通信

• 不需要复杂认证

---

2. 客户端工具

例如：

• kubectl

• kube-proxy

特点：

• 使用证书认证

• 认证信息通常保存在 kubeconfig 文件中

---

3. kubelet

特点：

• 自动申请证书

• 加入集群时完成认证

• 支持证书轮换

---

五、Pod 如何访问 API Server

部分运行在 Pod 中的组件需要访问 API Server，例如：

• 网络插件（Calico）

• DNS 服务（CoreDNS）

Pod 是动态创建和销毁的，如果为每个 Pod 单独签发证书，会带来以下问题：

• 证书管理复杂

• 性能开销大

• 安全风险难控制

因此 Kubernetes 引入了 ServiceAccount 机制。

---

六、ServiceAccount 工作机制

1. 默认行为

每个 Namespace 都会自动创建一个 default ServiceAccount。

如果 Pod 未显式指定，则默认使用该账户。

---

2. 自动挂载凭证

当 Pod 使用 ServiceAccount 时，系统会自动创建对应的 Secret，并挂载到容器中：

/run/secrets/kubernetes.io/serviceaccount/

---

3. 挂载内容

通常包含以下三个文件：

ca.crt
token
namespace

---

4. 各文件作用

文件	说明
ca.crt	用于验证 API Server 的证书
token	用于身份认证（JWT）
namespace	当前 Pod 所属命名空间

其中 token 是由 API Server 签发的 JWT，用于 Pod 访问 API Server。

---

七、实验验证

1. 创建命名空间

kubectl create namespace test-sa

---

2. 查看 ServiceAccount

kubectl get serviceaccount -n test-sa

可以看到默认的 default ServiceAccount。

---

3. 查看 Pod 中的挂载信息

kubectl get pod -A

kubectl exec -it -n <namespace> <pod-name> -- /bin/sh

cd /run/secrets/kubernetes.io/serviceaccount/
ls

输出如下：

ca.crt
namespace
token

---

八、创建 ServiceAccount

方式一：命令行

kubectl create serviceaccount my-sa -n my-namespace

查看 YAML：

kubectl create serviceaccount my-sa -n my-namespace \
  --dry-run=client -o yaml

---

方式二：YAML 文件

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-serviceaccount
  namespace: my-namespace

应用：

kubectl apply -f my-serviceaccount.yaml

---

九、总结

Kubernetes 的认证体系可以从以下几个方面理解：

核心流程

认证 → 鉴权 → 准入控制

---

关键设计

• API Server 作为统一入口

• 提供多种认证方式

• 使用 ServiceAccount 解决 Pod 身份问题

---

设计目标

• 降低证书管理成本

• 提升整体安全性

• 适配动态资源场景

---

总结一句话

Kubernetes 通过 3A 模型构建访问控制体系，并通过 ServiceAccount 机制解决了 Pod 的身份认证问题。