ServiceAccount关联kubeconfig失效问题及AKS多团队资源配置咨询

嘿，我正好帮过不少团队在AKS里做这种多租户权限隔离，给你一套经过实践的流程，连minikube测试和AKS适配的细节都理清楚，还有常见坑的排查方法：

一、先在minikube中完成测试验证 #

先在本地环境跑通逻辑，再迁移到AKS会更稳妥：

1. 创建团队专属Namespace #

每个团队用独立namespace做资源隔离，命令很简单：

kubectl create namespace team-retail

把team-retail换成你的团队名称就行，比如team-payments、team-logistics。

2. 创建对应Namespace的ServiceAccount #

避免用集群级的管理员账号，给每个团队创建专属的ServiceAccount（SA），限定在他们的namespace下：

kubectl create serviceaccount team-retail-sa -n team-retail

3. 定义Namespace级权限Role #

接下来要给这个SA设置具体的操作权限，比如允许他们管理自己namespace下的Pod、Deployment、ConfigMap等。创建一个team-retail-role.yaml文件：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-retail-role
  namespace: team-retail
rules:
# 核心资源权限（Pod、Service等）
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "create", "update", "delete"]
# Apps组资源权限（Deployment、StatefulSet等）
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list", "create", "update", "delete"]

根据团队实际需求调整verbs和resources——如果是运维只读团队，就只保留get、list；如果需要更细粒度的权限，比如只允许更新Deployment但不能删除，就单独配置。

然后应用这个Role：

kubectl apply -f team-retail-role.yaml

4. 绑定Role到ServiceAccount（RoleBinding） #

把刚才创建的SA和Role绑定起来，确保权限只作用于指定namespace：
创建team-retail-rolebinding.yaml：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-retail-rb
  namespace: team-retail
subjects:
- kind: ServiceAccount
  name: team-retail-sa
  namespace: team-retail
roleRef:
  kind: Role
  name: team-retail-role
  apiGroup: rbac.authorization.k8s.io

应用命令：

kubectl apply -f team-retail-rolebinding.yaml

5. 生成受限的KubeConfig文件 #

这是很多人踩坑的环节——默认kubeconfig用的是集群管理员账号，我们要生成只对应这个SA权限的kubeconfig：

手动生成步骤：

1. 获取SA关联的Secret名称：

kubectl get secrets -n team-retail | grep team-retail-sa

2. 提取SA的token（已经解码后的明文）：

kubectl get secret <你的Secret名称> -n team-retail -o jsonpath='{.data.token}' | base64 -d

3. 提取集群CA证书（base64编码格式，直接用）：

kubectl get secret <你的Secret名称> -n team-retail -o jsonpath='{.data.ca\.crt}'

4. 获取集群API地址：

kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'

然后创建team-retail-kubeconfig文件，替换下面的占位符：

apiVersion: v1
kind: Config
current-context: team-retail-context
clusters:
- name: aks-cluster
  cluster:
    certificate-authority-data: <上面拿到的CA证书base64内容>
    server: <上面拿到的集群API地址>
contexts:
- name: team-retail-context
  context:
    cluster: aks-cluster
    namespace: team-retail
    user: team-retail-sa
users:
- name: team-retail-sa
  user:
    token: <上面拿到的明文token>

批量生成脚本（更高效）

如果有多个团队，用脚本自动生成更省事，创建generate-kubeconfig.sh：

#!/bin/bash
# 配置参数
NAMESPACE="team-retail"
SA_NAME="team-retail-sa"
CLUSTER_NAME="aks-cluster"

# 自动获取所需信息
SECRET_NAME=$(kubectl get sa $SA_NAME -n $NAMESPACE -o jsonpath='{.secrets[0].name}')
TOKEN=$(kubectl get secret $SECRET_NAME -n $NAMESPACE -o jsonpath='{.data.token}' | base64 -d)
CA_CRT=$(kubectl get secret $SECRET_NAME -n $NAMESPACE -o jsonpath='{.data.ca\.crt}')
API_SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')

# 生成kubeconfig文件
cat > ${NAMESPACE}-kubeconfig <<EOF
apiVersion: v1
kind: Config
current-context: ${NAMESPACE}-context
clusters:
- name: ${CLUSTER_NAME}
  cluster:
    certificate-authority-data: ${CA_CRT}
    server: ${API_SERVER}
contexts:
- name: ${NAMESPACE}-context
  context:
    cluster: ${CLUSTER_NAME}
    namespace: ${NAMESPACE}
    user: ${SA_NAME}
users:
- name: ${SA_NAME}
  user:
    token: ${TOKEN}
EOF

echo "生成完成：${NAMESPACE}-kubeconfig"

给脚本加执行权限：chmod +x generate-kubeconfig.sh，然后运行即可。

二、AKS环境的特殊适配 #

AKS和minikube有几个关键区别，要注意：

1. 长期ServiceAccount Token #

AKS默认的SA token有效期只有1小时，过期后kubeconfig就失效了。要创建长期token，创建team-retail-long-token.yaml：

apiVersion: v1
kind: Secret
metadata:
  name: team-retail-sa-long-token
  namespace: team-retail
  annotations:
    kubernetes.io/service-account.name: team-retail-sa
type: kubernetes.io/service-account-token

应用后，用这个Secret里的token生成kubeconfig，就能避免频繁更新。

2. 安全建议 #

如果你的团队规模大，更推荐用Azure AD集成：把Azure AD组和Kubernetes的Role/ClusterRole绑定，用户用自己的AD账号登录，比SA token更安全，也不用管理token过期问题。但纯SA方案对于小型团队或者测试场景完全够用。

三、常见问题排查 #

1. kubeconfig无法访问集群：

   • 检查token是否正确解码（脚本已经处理了解码，手动生成时别漏了base64 -d）
   • 确认context里的namespace和SA的namespace一致
   • 用kubectl --kubeconfig=team-retail-kubeconfig auth can-i get pods测试权限，看是否返回yes

2. SA权限不足：

   • 用命令测试具体权限：kubectl auth can-i create deployments -n team-retail --as=system:serviceaccount:team-retail:team-retail-sa
   • 检查Role的apiGroups是否正确——比如Deployment属于apps组，不能只写""（核心组）

3. AKS token过期：

   • 用上面的长期token方案，或者定期运行脚本更新kubeconfig
   • 切换到Azure AD认证彻底解决token过期问题

内容的提问来源于stack exchange，提问作者bramvdk