ServiceAccount：Pod 身份、Token 投射与轮换

1. 为什么需要 ServiceAccount？#

先看一个实际场景。

假设我们部署了一个应用程序，它运行在 Kubernetes 的 Pod 中。

这个应用程序需要完成以下工作：

1. 获取当前 Namespace 中所有 Pod。
2. 监听 Pod 状态变化。
3. 根据 Pod 状态执行一些自动化操作。

例如，一个自定义控制器需要持续监听 Deployment 和 Pod 的变化。

但是，Pod 本质上只是一个容器运行环境。容器本身并不会天然拥有访问 Kubernetes API 的身份。

因此，需要给 Pod 分配一个身份。

这个身份就是 ServiceAccount。

flowchart TB
    P["Kubernetes Pod"] -->|"运行"| A["业务程序 / Controller"]
    P -->|"serviceAccountName"| S["ServiceAccount<br/>dev-sa"]
    A -->|"携带 ServiceAccount Token"| K["Kubernetes API Server<br/>验证身份并检查 RBAC 权限"]

注意：

ServiceAccount 只提供身份，并不意味着它自动拥有访问所有 Kubernetes 资源的权限。

身份和权限仍然是两个独立的概念。

2. ServiceAccount 的基本结构#

2.1 ServiceAccount 是什么？#

ServiceAccount 是 Kubernetes 中的一种 API 资源。

它属于某个 Namespace。

查看当前集群中的 ServiceAccount：

1
kubectl get serviceaccount -A

也可以简写：

1
kubectl get sa -A

通常你会发现，每个 Namespace 默认都有一个名为 default 的 ServiceAccount。

例如：

1
kubectl get sa -n default

输出类似：

1
NAME      SECRETS   AGE
2
default   0         10d

这里的 SECRETS 为 0 并不表示没有 Token。

较新版本 Kubernetes 默认采用 TokenRequest API 和投射卷机制为 Pod 提供短期 Token，而不是自动创建长期有效的 Secret。

2.2 每个 Namespace 为什么都有 default？#

当你创建一个 Namespace 时，Kubernetes 通常会自动创建一个名为 default 的 ServiceAccount。

如果创建 Pod 时没有指定 ServiceAccount：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: nginx
5
  namespace: default
6
spec:
7
  containers:
8
    - name: nginx
9
      image: nginx

Kubernetes 会默认使用：

1
spec:
2
  serviceAccountName: default

也就是说：

没有指定 ServiceAccount 的 Pod，默认使用所在 Namespace 的 default ServiceAccount。

可以通过以下命令查看 Pod 使用的身份：

1
kubectl get pod nginx \
2
  -o jsonpath='{.spec.serviceAccountName}'

也可以查看完整配置：

1
kubectl describe pod nginx

关注：

1
Service Account: default

2.3 创建自己的 ServiceAccount#

实际开发中，不建议所有应用程序都使用 default ServiceAccount。

应该根据应用程序的职责创建独立身份。

例如：

1
kubectl create serviceaccount dev-sa \
2
  -n dev

也可以使用 YAML：

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: dev-sa
5
  namespace: dev

3. Pod 如何使用 ServiceAccount？#

创建 ServiceAccount 后，需要将它关联到 Pod。

3.1 指定 ServiceAccount#

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: app
5
  namespace: dev
6
spec:
7
  serviceAccountName: dev-sa
8
  containers:
9
    - name: app
10
      image: nginx

关键配置：

1
spec:
2
  serviceAccountName: dev-sa

它告诉 Kubernetes：

这个 Pod 使用 dev Namespace 中的 dev-sa 作为自己的身份。

注意：ServiceAccount 和 Pod 必须位于同一个 Namespace。

3.2 Kubernetes 如何向 Pod 提供 Token？#

当 Pod 使用 ServiceAccount 时，Kubernetes 通常会自动将身份凭据挂载到容器内部。

默认挂载路径：

1
/var/run/secrets/kubernetes.io/serviceaccount/

通常可以看到：

1
ca.crt
2
namespace
3
token

三个文件的作用：

这里需要区分两个概念：

• Token：证明自己是谁。
• CA 证书：验证自己连接的 API Server 是否可信。

它们分别解决客户端身份认证和服务端身份验证问题。

4. ServiceAccount Token 的工作原理#

这个 Token 是谁生成的？如何进入 Pod？什么时候失效？

这涉及 Kubernetes 的 Token 投射机制。

4.1 传统方式：Secret Token#

在较早版本的 Kubernetes 中，创建 ServiceAccount 后，通常会自动创建一个长期有效的 Token Secret。

结构类似：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: dev-sa-token
5
  namespace: dev
6
  annotations:
7
    kubernetes.io/service-account.name: dev-sa
8
type: kubernetes.io/service-account-token

Secret 中包含：

1
data:
2
  ca.crt: ...
3
  namespace: ...
4
  token: ...

这种方式存在一些问题：

• Token 生命周期较长。
• Token 泄露后可能长期被滥用。
• 需要额外管理 Token 的创建、存储和轮换。

因此，现代 Kubernetes 已经不再默认自动为每个 ServiceAccount 创建长期有效的 Token Secret。

4.2 现代方式：TokenRequest API#

从 Kubernetes 1.22 开始，Bound ServiceAccount Token 成为默认机制。

它通过 TokenRequest API 申请短期有效的 Token。

整个过程可以理解为：

flowchart TB
    P["Pod 创建<br/>serviceAccountName: dev-sa"] --> K["Kubelet"]
    K -->|"TokenRequest API 申请 Token"| S["API Server"]
    S -->|"签发绑定 ServiceAccount、Pod 的 Token"| K
    K -->|"写入并管理凭据"| V["Projected Volume"]
    V -->|"投射到容器文件系统"| A["应用程序读取 Token"]
    A -->|"携带 Token 访问 Kubernetes API"| S

这里有一个重要细节：

Token 并不是简单地由容器自己生成，而是由 Kubernetes API Server 签发，Kubelet 负责请求和管理投射到 Pod 中的凭据。

4.3 Token 的主要特点#

现代 ServiceAccount Token 通常具有以下特点：

1. 有时效性：Token 有过期时间。
2. 身份绑定：可以绑定到特定 Pod。
3. 自动轮换：Kubelet 会在 Token 到期前更新投射的凭据。
4. Audience 限制：Token 可以限定适用的接收方。

Token 的 JWT Payload 示例：

1
{
2
  "iss": "https://kubernetes.default.svc",
3
  "sub": "system:serviceaccount:dev:dev-sa",
4
  "aud": [
5
    "https://kubernetes.default.svc"
6
  ],
7
  "exp": 1790000000,
8
  "kubernetes.io": {
9
    "namespace": "dev",
10
    "serviceaccount": {
11
      "name": "dev-sa",
12
      "uid": "..."
13
    },
14
    "pod": {
15
      "name": "app",
16
      "uid": "..."
17
    }
18
  }
19
}

重点认识三个字段：

例如：

1
system:serviceaccount:dev:dev-sa

表示：

• system:serviceaccount：ServiceAccount 身份类型。
• dev：Namespace。
• dev-sa：ServiceAccount 名称。

注意：JWT Payload 解码不等于验证 Token 的真实性。真正的签名、有效期、受众及身份绑定校验由 API Server 等验证方完成。

4.4 Token 自动轮换#

假设一个 Pod 运行了 30 天，而 Token 的有效期远短于 30 天。

如果 Token 不会自动更新，应用程序就可能因为 Token 过期而无法访问 API Server。

Kubernetes 通过 Kubelet 的 Token 投射与轮换机制解决这个问题。

需要注意两点：

• Kubelet 会更新投射卷中的 Token 文件。
• 应用程序应当重新读取 Token 文件，不能一直使用启动时读取并缓存的旧 Token。

使用 Kubernetes 官方客户端库时，通常可以利用客户端库提供的凭据刷新能力。

如果是自己编写的程序，就需要正确处理文件更新和重新读取。

5. Projected Volume：理解 Token 投射#

前面提到了 Projected Volume，它是 Kubernetes 将多个数据源组合到同一个目录中的一种机制。

ServiceAccount Token 就是其中一种典型应用。

5.1 查看 Pod 的 Token 挂载#

1
kubectl describe pod app -n dev

关注：

1
Mounts:
2
  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-xxxxx (ro)
3

4
Volumes:
5
  kube-api-access-xxxxx:
6
    Type: Projected

这说明 Kubernetes 使用 Projected Volume 为 Pod 提供访问 API Server 所需的凭据。

它可能组合以下数据源：

• ServiceAccount Token。
• API Server CA 证书。
• Pod 所属 Namespace 信息。

5.2 自定义 Projected Volume#

除了默认挂载方式，我们还可以自己定义 Token 投射。

例如：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: projected-token
5
  namespace: dev
6
spec:
7
  serviceAccountName: dev-sa
8
  containers:
9
    - name: app
10
      image: nginx
11
      volumeMounts:
12
        - name: token-volume
13
          mountPath: /var/run/custom-token
14
          readOnly: true
15
  volumes:
16
    - name: token-volume
17
      projected:
18
        sources:
19
          - serviceAccountToken:
20
              path: token
21
              expirationSeconds: 3600
22
              audience: https://kubernetes.default.svc
23
          - configMap:
24
              name: kube-root-ca.crt
25
              items:
26
                - key: ca.crt
27
                  path: ca.crt

这里：

注意：

expirationSeconds 是请求的有效期，实际签发期限由 API Server 配置和策略决定。通常不能设置低于 600 秒的请求期限。

自定义 Token 投射与默认 Token 挂载可以并存，但如果自定义 Token 已经满足应用需求，应该避免无意义地挂载多份凭据。

6. 如何禁止 Pod 自动挂载 Token？#

这是一个非常重要的安全知识点。

不是所有 Pod 都需要访问 Kubernetes API。

例如：

• Nginx Web 服务。
• 普通 Java 微服务。
• 静态资源服务。
• 不需要访问集群 API 的任务容器。

这些应用如果没有 API 访问需求，就不应该默认获得 ServiceAccount Token。

6.1 在 Pod 中关闭#

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: nginx
5
  namespace: dev
6
spec:
7
  automountServiceAccountToken: false
8
  containers:
9
    - name: nginx
10
      image: nginx

6.2 在 ServiceAccount 中关闭#

也可以在 ServiceAccount 层面设置：

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: dev-sa
5
  namespace: dev
6
automountServiceAccountToken: false

这样，使用这个 ServiceAccount 的 Pod 默认不会自动挂载 Token。

如果 Pod 和 ServiceAccount 都设置了该字段，Pod 级别的设置优先。

生产环境建议

遵循最小权限原则：

• 不需要访问 API 的 Pod：关闭自动挂载。
• 需要访问 API 的 Pod：使用专属 ServiceAccount。
• 只授予完成业务所需的最小 RBAC 权限。

7. Pod 如何真正访问 Kubernetes API Server？#

假设有一个应用程序运行在 Pod 中，它需要获取 dev Namespace 中的 Pod 列表。

完整过程是：

flowchart TB
    P["Pod 使用 dev-sa ServiceAccount"] --> K["Kubelet 将 Token 投射并挂载到 Pod"]
    K --> A["应用程序读取 Token"]
    A -->|"HTTPS 请求携带 Bearer Token"| S["API Server 验证 Token"]
    S --> R["RBAC 检查权限"]
    R -->|"授权成功"| D["返回 dev Namespace 的 Pod 列表"]

7.1 Kubernetes API Server 地址#

在 Pod 内部，通常可以通过 Kubernetes Service 访问 API Server：

1
https://kubernetes.default.svc

查看 Kubernetes Service：

1
kubectl get svc kubernetes

输出类似：

1
NAME         TYPE        CLUSTER-IP
2
kubernetes   ClusterIP   10.96.0.1

其中：

• kubernetes 是默认 Service 名称。
• default 是 Namespace。
• svc 是 Kubernetes Service DNS 域名的一部分。

7.2 给 ServiceAccount 授予权限#

先创建一个 Role：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: Role
3
metadata:
4
  name: pod-reader
5
  namespace: dev
6
rules:
7
  - apiGroups: [""]
8
    resources: ["pods"]
9
    verbs: ["get", "list", "watch"]

再创建 RoleBinding：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: RoleBinding
3
metadata:
4
  name: dev-sa-pod-reader
5
  namespace: dev
6
subjects:
7
  - kind: ServiceAccount
8
    name: dev-sa
9
    namespace: dev
10
roleRef:
11
  kind: Role
12
  name: pod-reader
13
  apiGroup: rbac.authorization.k8s.io

7.3 使用 Token 调用 API Server#

Pod 内部使用 Token 调用 API 的命令示例：

1
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
2

3
CACERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

访问 API Server：

1
curl --cacert "$CACERT" \
2
  -H "Authorization: Bearer $TOKEN" \
3
  https://kubernetes.default.svc/api/v1/namespaces/dev/pods

如果权限配置正确，API Server 会返回 JSON 格式的 Pod 列表。

8. ServiceAccount Token 的手动生成与管理#

8.1 手动生成 Token#

1
kubectl create token dev-sa -n dev

指定有效期：

1
kubectl create token dev-sa \
2
  -n dev \
3
  --duration=1h

指定 Audience：

1
kubectl create token dev-sa \
2
  -n dev \
3
  --audience=https://kubernetes.default.svc

这个命令通过 TokenRequest API 申请 Token。

注意：手动生成的 Token 默认不是绑定到某个 Pod 的 Token，不能简单地认为它与 Pod 自动挂载的 Token 完全相同。

8.2 查看 ServiceAccount#

1
kubectl get sa -n dev

1
kubectl describe sa dev-sa -n dev

8.3 查看 Pod 使用的 ServiceAccount#

1
kubectl get pod app -n dev \
2
  -o jsonpath='{.spec.serviceAccountName}'

8.4 查看 ServiceAccount 对应的权限#

1
kubectl auth can-i --list \
2
  --as=system:serviceaccount:dev:dev-sa \
3
  -n dev

8.5 查看 Token 是否自动挂载#

1
kubectl get pod app -n dev \
2
  -o jsonpath='{.spec.automountServiceAccountToken}'

注意：如果输出为空，不代表关闭了自动挂载，而是表示 Pod 没有显式设置该字段，需要继续检查 ServiceAccount 配置及默认行为。

9. 生产环境中的 ServiceAccount 设计#

假设有一个实际的微服务集群：

合理的设计方式：

9.1 最小权限设计#

flowchart LR
    N["Nginx"] --> N1["automountServiceAccountToken: false<br/>不挂载 Token"]
    P["Prometheus"] --> P1["独立 ServiceAccount + 只读 RBAC<br/>只读权限"]
    C["Controller"] --> C1["独立 ServiceAccount + 精确资源授权<br/>按需授权"]

生产环境尤其需要注意：

1. 不要让所有 Pod 共用具有高权限的 ServiceAccount。
2. 不要随意创建长期有效的 ServiceAccount Token Secret。
3. 不需要访问 API Server 的应用应关闭 Token 自动挂载。
4. 尽量限制 Token 的 Audience 和有效期。
5. 不要将 Token 写入镜像、代码仓库或日志。
6. 对 Controller 等程序，精确限制其可操作的资源和 Namespace。