Kubernetes 1.24+ SA Token生成与安全实践指南

1. Kubernetes 1.32+ 集群手动生成SA Token的完整指南

在Kubernetes 1.24及更高版本中，ServiceAccount token的认证机制发生了重大变化。这个变化直接影响了许多依赖SA token的外部系统集成，比如Prometheus监控、CI/CD系统等。作为一名长期工作在Kubernetes运维一线的工程师，我最近在配置Prometheus监控时也遇到了这个问题，经过多次实践和验证，总结出了这套可靠的解决方案。

1.1 为什么Kubernetes改变了token生成机制？

在Kubernetes 1.24之前，当我们创建一个ServiceAccount时，系统会自动生成一个对应的Secret，其中包含长期有效的token。这种方式虽然方便，但也带来了安全隐患：

1. 长期有效的token难以撤销：一旦泄露，攻击者可以长期使用
2. 缺乏细粒度的生命周期管理：无法灵活控制token的有效期
3. 审计困难：难以追踪token的使用情况

Kubernetes 1.24+引入了更安全的token管理机制：

• 只有通过kubectl create token命令生成的token才能通过API Server认证
• 手动生成的token虽然格式正确，但不会被API Server认可
• 支持设置token的有效期，默认1小时，最长10年

重要提示：虽然我们可以生成10年有效期的token，但从安全角度考虑，建议定期轮换token，特别是用于生产环境的关键服务。

2. 完整操作步骤详解

2.1 创建专用命名空间和ServiceAccount

首先，我们需要为外部监控系统创建一个独立的命名空间和专用的ServiceAccount。这样做的好处是：

1. 资源隔离：避免与其他系统资源混淆
2. 权限隔离：可以针对这个SA设置专门的权限
3. 便于管理：所有相关资源都在同一个命名空间下

bash复制# 创建专用命名空间
kubectl create namespace monitor-external

# 创建专用ServiceAccount
kubectl create sa external-monitor-sa -n monitor-external

2.2 配置最小权限RBAC

权限最小化是Kubernetes安全实践的核心原则之一。我们需要为监控SA配置仅包含必要权限的RBAC。

2.2.1 创建只读ClusterRole

yaml复制cat > external-monitor-role.yaml << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: external-monitor-role
rules:
# 监控节点/Pod/服务等核心资源的只读权限
- apiGroups: [""]
  resources:
  - nodes
  - nodes/metrics
  - pods
  - services
  - endpoints
  - namespaces
  - configmaps
  verbs: ["get", "list", "watch"]
# 监控metrics.k8s.io指标（节点/Pod指标）
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "list", "watch"]
# 监控部署类资源（可选）
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch"]
EOF

kubectl apply -f external-monitor-role.yaml

2.2.2 绑定ClusterRole到SA

yaml复制cat > external-monitor-binding.yaml << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: external-monitor-binding
subjects:
- kind: ServiceAccount
  name: external-monitor-sa
  namespace: monitor-external
roleRef:
  kind: ClusterRole
  name: external-monitor-role
  apiGroup: rbac.authorization.k8s.io
EOF

kubectl apply -f external-monitor-binding.yaml

2.3 生成K8s官方签发的token

这是最关键的一步，我们需要使用kubectl create token命令生成官方认可的token。

2.3.1 获取SA的UID

bash复制SA_UID=$(kubectl get sa external-monitor-sa -n monitor-external -o json | grep '"uid":' | head -1 | awk -F'"' '{print $4}')

2.3.2 提取集群CA证书

bash复制CA_FILE=$(find /etc/kubernetes /opt/k8s /usr/local/k8s -name "ca.crt" 2>/dev/null | head -1)
if [ -z "$CA_FILE" ]; then
  echo "ERROR: 未找到CA证书，请手动指定路径！"
  exit 1
fi
CA_CRT=$(cat "$CA_FILE" | base64 -w0)

2.3.3 生成长期有效的token

bash复制# 生成10年有效期的token
TOKEN_PLAIN=$(kubectl create token external-monitor-sa -n monitor-external --duration=87600h)
echo "K8s签发的长期token：$TOKEN_PLAIN"
TOKEN_B64=$(echo -n "$TOKEN_PLAIN" | base64 -w0)
NAMESPACE_B64=$(echo -n "monitor-external" | base64 -w0)

2.3.4 创建包含完整数据的Secret

yaml复制cat > external-monitor-token.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
  name: external-monitor-token
  namespace: monitor-external
  annotations:
    kubernetes.io/service-account.name: external-monitor-sa
    kubernetes.io/service-account.uid: $SA_UID
type: kubernetes.io/service-account-token
data:
  ca.crt: ${CA_CRT}
  namespace: ${NAMESPACE_B64}
  token: ${TOKEN_B64}
EOF
kubectl apply -f external-monitor-token.yaml

2.3.5 提取明文token和CA证书

bash复制echo -e "\n=== 长期有效Token（供外部使用）==="
TOKEN_PLAIN=$(kubectl get secret external-monitor-token -n monitor-external -o jsonpath='{.data.token}' | base64 -d)
echo $TOKEN_PLAIN

echo -e "\n=== CA证书已保存到本地 ==="
kubectl get secret external-monitor-token -n monitor-external -o jsonpath='{.data.ca\.crt}' | base64 -d > /root/external-monitor-ca.crt
echo "CA证书路径：/root/external-monitor-ca.crt"

2.4 验证token有效性

最后，我们需要验证生成的token是否真的有效。

bash复制# 获取APIServer地址
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')

# 使用token访问APIServer
curl -k $APISERVER/api/v1/pods \
  --header "Authorization: Bearer $TOKEN_PLAIN" \
  --cacert /root/external-monitor-ca.crt

如果返回了Pod列表，说明token配置成功；如果返回"Forbidden"，则需要检查RBAC权限配置。

3. 常见问题与解决方案

3.1 为什么我的token无法通过认证？

可能的原因：

1. 使用了手动拼接的token而不是通过kubectl create token生成的
2. RBAC权限配置不正确
3. token已过期（虽然我们设置了10年有效期，但最好检查一下）

解决方案：

1. 确保使用kubectl create token命令生成token
2. 使用kubectl auth can-i命令检查权限
3. 重新生成token

3.2 如何为token生成kubeconfig文件？

有时外部系统需要使用kubeconfig文件而不是直接使用token。下面是生成kubeconfig的步骤：

bash复制# 获取集群名称和上下文名称
CLUSTER_NAME=$(kubectl config view --minify -o jsonpath='{.clusters[0].name}')
CONTEXT_NAME=$(kubectl config view --minify -o jsonpath='{.current-context}')

# 生成kubeconfig文件
cat > external-monitor-kubeconfig.yaml << EOF
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /root/external-monitor-ca.crt
    server: $APISERVER
  name: $CLUSTER_NAME
contexts:
- context:
    cluster: $CLUSTER_NAME
    user: external-monitor-sa
    namespace: monitor-external
  name: $CONTEXT_NAME
current-context: $CONTEXT_NAME
users:
- name: external-monitor-sa
  user:
    token: $TOKEN_PLAIN
EOF

3.3 如何定期轮换token？

虽然我们生成了长期有效的token，但从安全角度考虑，建议定期轮换：

1. 创建一个脚本自动生成新token
2. 使用Kubernetes的CronJob定期执行这个脚本
3. 更新外部系统使用的token或kubeconfig文件

4. 安全最佳实践

1. 权限最小化：只授予SA必要的权限，不要使用cluster-admin等过高权限
2. 定期轮换：即使设置了长期有效的token，也应定期更换
3. 独立SA：为每个外部系统创建独立的SA，不要共享
4. 监控使用情况：通过审计日志监控SA token的使用情况
5. 敏感信息保护：妥善保管token和kubeconfig文件，不要提交到代码仓库

在实际工作中，我发现很多团队因为图方便而忽略了这些安全实践，结果导致安全事件。遵循这些原则可以大大降低风险。