本文档提供有关身份和授权问题的问题排查指南。
保持 gcloud anthos auth
最新
您可以通过验证 gcloud anthos auth
安装的组件处于最新状态,以避免许多常见问题。
因为 gcloud anthos auth
命令在 gcloud
核心组件及独立封装的 anthos-auth
组件中包含逻辑,所以必须验证两个部分。
更新 gcloud
:
gcloud components update
更新 anthos-auth
:
gcloud components install anthos-auth
提供方配置无效
如果您的身份提供方配置无效,点击登录后,身份提供方将显示错误屏幕。按照特定于提供方的说明正确配置提供方或您的集群。
权限无效
如果您完成了身份验证流程,但仍看不到集群的详细信息,请确保您已向与 OIDC 搭配使用的帐号授予了正确的 RBAC 权限。请注意,此帐号可能与您用于访问 Google Cloud 控制台的帐号不同。
缺少刷新令牌
如果授权服务器提示是否同意,但未提供所需的身份验证参数,就会出现以下问题。
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
要解决此问题,请在集群配置文件中将 prompt=consent
添加到 authentication.oidc.extraParams
字段。然后重新生成客户端身份验证文件。
刷新令牌已过期
当 kubeconfig 文件中的刷新令牌已过期时,会出现此问题:
Unable to connet to the server: Get {DISCOVERY_ENDPOINT}: x509: certificate signed by unknown authority
如需解决此问题,请再次运行 login
命令。
gkectl create-login-config 无法获取 clientconfig
如果传递到 gkectl create-login-config
的 kubeconfig 文件不适用于用户集群,或者 ClientConfig 自定义资源在集群创建过程中未出现,则会出现此问题。
Error getting clientconfig using KUBECONFIG
要解决此问题,请确保用户集群具有正确的 kubeconfig 文件。然后检查 ClientConfig 对象是否在集群中:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get clientconfig default -n kube-public
gkectl create-login-config 由于集群名称重复而失败
如果您尝试写入包含目标文件中已存在的集群名称的登录配置数据,则会出现此问题。每个登录配置文件都必须包含唯一的集群名称。
error merging with file MERGE_FILE because MERGE_FILE contains a cluster with the same name as the one read from KUBECONFIG. Please write to a new output file
如需解决此问题,请使用 --output
标志指定新的目标文件。
如果未提供 --output
,登录配置数据将写入当前目录中名为 kubectl-anthos-config.yaml
的文件。
gcloud anthos auth login 失败并显示 proxyconnect tcp
如果 https_proxy
或 HTTPS_PROXY
环境变量配置出错,就会出现此问题。如果环境变量中指定了 https://
,则当代理配置为使用其他协议(如 SOCK5)来处理 HTTPS 连接时,GoLang HTTP 客户端库可能会失败。
可能的错误消息:
proxyconnect tcp: tls: first record does not look like a TLS handshake
如需解决此问题,请修改 https_proxy
和 HTTPS_PROXY
环境变量以省略 https:// prefix
。在 Windows 上,修改系统环境变量。例如,将 https_proxy
环境变量的值从 https://webproxy.example.com:8000
更改为 webproxy.example.com:8000
。
使用 gcloud anthos auth login
生成的 kubeconfig 时集群访问失败
当 Kubernetes API 服务器无法向用户授权时,就会出现此问题。如果相应的 RBAC 不存在或错误,或者集群的 OIDC 配置存在错误,就可能发生这种情况。
Unauthorized
要解决此问题,请执行以下操作:
在
gcloud anthos auth login
生成的 kubeconfig 文件中,复制id-token
的值kind: Config … users: — name: … user: auth-provider: config: id-token: xxxxyyyy
安装 jwt-cli 并运行以下命令:
jwt ID_TOKEN
验证 OIDC 配置。
用户集群配置文件中的
authentication.oidc
具有group
和username
字段,用于在 Kubernetes API 服务器中设置--oidc-group-claim
和--oidc-username-claim
标志。当 API 服务器收到令牌时,会将令牌转发到 Anthos Identity Service,后者随后会将提取的group-claim
和username-claim
返回给 AIP 服务器。API 服务器使用响应来验证对应的组或用户具有正确的权限。验证 ID 令牌中包含集群配置文件的
authentication.oidc
部分中为group
和user
设置的声明。检查已应用的 RBAC。
针对上一步由
username-claim
指定的用户或者group-claim
中列出的某个群组,验证是否存在具有正确权限的 RBAC。RBAC 中用户或群组的名称应该带有用户集群配置文件中指定的usernameprefix
或groupprefix
前缀。请注意,如果
usernameprefix
为空,并且username
的值不是email
,则前缀默认为issuerurl#
。要停用用户名前缀,请将usernameprefix
设置为-
。如需详细了解用户和群组前缀,请参阅填充 OIDC 规范。
请注意,Kubernetes API 服务器将反斜杠视为转义字符。因此,如果用户或群组的名称包含
\\
,则 API 服务器会在解析 ID 令牌时将其作为单个\
进行读取。因此,应用到此用户或群组的 RBAC 角色绑定只能包含一个反斜杠,否则您可能会看到Unauthorized
错误。集群配置文件:
oidc: ... username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:"
ID 令牌:
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\\cluster-developer", "group": [ "Domain Users", "EXAMPLE\\developers" ], ... }
以下 RBAC 绑定会向此群组和用户授予
pod-reader
集群角色。请注意名称字段中应包含单斜杠,而不是双斜杠:群组 ClusterRoleBinding:
apiVersion: kind: ClusterRoleBinding metadata: name: example-binding subjects: — kind: Group name: "oidc:EXAMPLE\developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
用户 ClusterRoleBinding:
apiVersion: kind: ClusterRoleBinding metadata: name: example-binding subjects: — kind: User name: "EXAMPLE\cluster-developer" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
检查 Kubernetes API 服务器日志。
如果 Kubernetes API 服务器中配置的 OIDC 插件未正确启动,则 API 服务器会在收到 ID 令牌时返回
Unauthorized
错误。如需检查 API 服务器中的 OIDC 插件是否存在任何问题,请运行以下命令:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG logs statefulset/kube-apiserver -n USER_CLUSTER_NAME