GKE环境中kubectl logs命令突发授权错误求助

核心问题定位 #

执行kubectl logs --tail=100 -f jerry-proxy-****时出现的授权错误，本质是kube-apiserver用户缺少访问nodes/proxy子资源的get权限。虽然你执行的是Pod日志命令，但kubectl获取日志时可能需要通过Node Proxy转发请求，因此触发了该权限校验。上周正常现在报错，大概率是集群内RBAC规则、ServiceAccount权限或kube-apiserver配置被修改所致。

排查与修复步骤 #

• 检查kube-apiserver的RBAC权限绑定
  先确认kube-apiserver对应的ServiceAccount（通常在kube-system命名空间）是否拥有nodes/proxy资源的get权限，执行以下命令查看相关ClusterRole和绑定关系：

  kubectl get clusterroles | grep -i node
  kubectl get clusterrolebindings | grep -i kube-apiserver
  

  找到关联kube-apiserver的ClusterRole，检查其rules字段是否包含：

  - apiGroups: [""]
    resources: ["nodes/proxy"]
    verbs: ["get"]
  

  若缺失，需更新对应ClusterRole添加该权限，或创建新的ClusterRoleBinding，将包含该权限的ClusterRole绑定到kube-apiserver用户/ServiceAccount。

• 排查近期RBAC变更记录
  查看kube-system命名空间下的事件，或集群审计日志，确认是否有RBAC规则被删除、修改：

  kubectl get events -n kube-system | grep -i rbac
  # 若启用审计日志，直接查看日志文件（默认路径多为/var/log/kubernetes/audit.log，以集群实际配置为准）
  

• 验证kube-apiserver启动参数
  检查kube-apiserver的Pod配置，确认授权模式是否被变更（比如从RBAC切换为其他模式，或新增了严格的授权插件）：

  kubectl edit pod kube-apiserver-<节点名称> -n kube-system
  

  重点查看--authorization-mode相关参数，确保RBAC模式正常启用，无不合理的权限限制。

• 直接验证Node Proxy权限
  执行以下命令直接访问Node Proxy接口，确认权限问题是否真实存在：

  kubectl get --raw /api/v1/nodes/<节点名称>/proxy
  

  若同样报错，可确认问题根源就是nodes/proxy的权限缺失，集中修复RBAC规则即可。

内容的提问来源于stack exchange，提问作者Dean Christian Armada