403 Forbidden 错误表明请求已通过认证但被 RBAC 或 Azure RBAC 拒绝授权；需先运行 az aks show --query aadProfile.enableAzureRbac 判断权限模型，再检查用户身份、token 有效性及对应 RoleBinding/ClusterRoleBinding 配置。
当你执行 kubectl get pods 或调用 Kubernetes API 时收到 403 Forbidden 错误，说明请求已通过认证（不是 401），但被 RBAC 或 Azure RBAC 拒绝授权——此时 API Server 明确认出了你是谁，却判定你无权访问目标资源。
确认当前集群使用的 RBAC 类型
先判断权限模型是原生 Kubernetes RBAC 还是 Azure 托管的 Azure RBAC，二者配置方式完全不同：
运行 az aks show -g <RG> -n <CLUSTER> --query aadProfile.enableAzureRbac。
若返回 【true】，走 Azure RBAC 路径；若返回 【false】 或 【null】，则走 Kubernetes RBAC 路径；
注意：返回 null 表示未启用 Azure AD 集成，此时只能使用 --admin 凭据临时验证，但该凭据不可用于生产环境长期调用。
检查当前用户身份与绑定状态
方法一：查看当前 kubectl 使用的用户和上下文kubectl config current-context → 若输出含 user=clusterUser 或类似非 admin 用户名，说明你正以普通身份操作。
再运行 kubectl config view --minify --output 'jsonpath={.users[0].user.auth-provider.config.expiry}'，确认 token 是否过期——过期 token 会导致请求被降级为 system:anonymous，进而触发 403（实际是匿名用户无任何权限）。
方法二：直接查当前用户在集群中的角色绑定kubectl auth can-i list pods --list --all-namespaces，这条命令会列出所有匹配的 RoleBinding/ClusterRoleBinding 及其来源命名空间；
若结果中显示 no，且无任何 binding 条目，则说明该用户确实未被授予任何 pod 相关权限。
快速验证是否为匿名用户问题
第一步：检查错误消息中的用户名
如果报错里明确出现 User "system:anonymous"，那根本不是权限不足，而是认证失败——你的请求压根没带有效凭证。
第二步：确认 kubeconfig 中是否遗漏 user 字段或 token 已失效
运行 kubectl config view --minify | grep -A5 user:，看是否有 token: 或 client-certificate-data:；
若只有 exec: 块（常见于 AKS + Azure CLI 登录），需确保 az login 已执行且账户有对应权限；
【关键点】：AKS 中若启用了 Azure RBAC，必须给该 Azure 用户/组在集群资源上分配 Kubernetes Cluster User Role 或更高权限的内置角色，仅给 Reader 等 Azure 内置角色无效。
针对 Kubernetes RBAC 的修复操作
① 查看是否存在可用的高权限 ClusterRolekubectl get clusterrole cluster-admin -o yaml，确认该角色存在且未被删除。
② 创建 ClusterRoleBinding 将当前用户绑定到 cluster-adminkubectl create clusterrolebinding debug-user-binding --clusterrole=cluster-admin --user=<your-aad-user-upn-or-serviceaccount-name>；
若不确定用户名，先运行 kubectl config view --minify --output 'jsonpath={.users[0].name}' 获取当前 user 名。
③ 验证是否生效kubectl get nodes —— 成功即说明权限已通；
若仍失败，检查绑定对象类型是否匹配：用 --user 绑定的是 Azure AD 用户（UPN 格式如 user@contoso.com），用 --serviceaccount 绑定的是 SA，二者不能混用。
