如何修改K8S默认服务账号权限？关于集群默认服务账号异常全权限问题的排查与解决方案咨询

首先明确一个核心事实：Kubernetes 开箱即用的状态下，每个命名空间里的 default ServiceAccount 是没有任何权限的——它既没有预定义的 RoleBinding，也没有 ClusterRoleBinding，连读取自身命名空间内的资源都做不到。你遇到的"全集群读写权限"肯定是集群的 RBAC 配置被修改过了，咱们一步步拆解问题：

1. 默认服务账号应该有基础角色绑定吗？ #

完全不应该。K8s 的安全设计就是让 default ServiceAccount 保持最小权限，作为一个"空白账号"存在，仅当你需要给某个 Pod 赋予特定权限时，才手动给它绑定对应的角色。官方绝对不会默认给它配置任何权限。

2. 为啥没绑定关系，却有全集群权限？ #

问题大概率出在针对宽泛用户组的 ClusterRoleBinding上。因为每个 ServiceAccount 都会自动加入几个系统组：

• system:authenticated：所有经过认证的实体（包括 ServiceAccount、用户）都会加入这个组
• system:serviceaccounts：所有命名空间的 ServiceAccount 都会加入这个组
• system:serviceaccounts:<命名空间>：当前命名空间下的所有 ServiceAccount 组

如果有人给这几个组中的任意一个绑定了 cluster-admin（集群超级管理员权限）或者其他高权限 ClusterRole，那所有 ServiceAccount（包括每个命名空间的 default）都会继承这些权限。

你可以用这条命令快速排查：

kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[]? | .kind == "Group" and (.name == "system:authenticated" or .name == "system:serviceaccounts"))'

这条命令会列出所有绑定到上述关键组的 ClusterRoleBinding，看看是不是有绑定了 cluster-admin 的条目——这几乎就是问题根源。

3. 如何让默认服务账号彻底失去所有权限？ #

要解决这个问题，分两步走：

第一步：清理不合理的宽范围权限绑定 #

先通过上面的命令找到违规的 ClusterRoleBinding，比如发现一个绑定了 system:authenticated 到 cluster-admin 的条目，直接删除它：

kubectl delete clusterrolebinding <绑定名称>

⚠️ 注意：操作前一定要确认这个绑定不是集群运行必需的——有些测试集群为了图方便会加这种配置，但生产环境绝对不能存在！

第二步：给默认服务账号绑定"空权限"角色（可选但更安全） #

虽然默认情况下 default ServiceAccount 已经没有权限，但为了彻底锁死（防止后续误配置），你可以给每个命名空间的 default ServiceAccount 绑定一个没有任何允许规则的 Role：

单个命名空间操作：

# 创建一个空角色（没有任何可执行的操作或资源）
kubectl create role default-sa-no-perms --verb="" --resource="" -n <你的命名空间>
# 绑定到当前命名空间的 default ServiceAccount
kubectl create rolebinding default-sa-lockdown --role=default-sa-no-perms --serviceaccount=<你的命名空间>:default -n <你的命名空间>

批量处理所有命名空间：

如果集群有很多命名空间，可以用脚本一键处理：

for ns in $(kubectl get namespaces -o name | cut -d/ -f2); do
  # 忽略已存在的资源报错
  kubectl create role default-sa-no-perms --verb="" --resource="" -n $ns 2>/dev/null
  kubectl create rolebinding default-sa-lockdown --role=default-sa-no-perms --serviceaccount=$ns:default -n $ns 2>/dev/null
done

额外安全建议 #

从最佳实践来说，应该避免使用 default ServiceAccount。给每个应用单独创建专属的 ServiceAccount，只赋予它运行所需的最小权限（遵循最小权限原则）——这能大幅降低权限泄露的风险。

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