Este documento fornece orientações para a solução de problemas de identidade e autorização.
Mantenha a gcloud anthos auth
atualizada
Para evitar muitos problemas comuns, verifique se os componentes da instalação do gcloud anthos auth
estão atualizados.
Há duas partes que precisam ser verificadas, porque o comando
gcloud anthos auth
tem lógica no componente principal gcloud
e um componente anthos-auth
empacotado separadamente.
Atualize gcloud
:
gcloud components update
Atualize anthos-auth
:
gcloud components install anthos-auth
Configuração de provedor inválida
Se a configuração do provedor de identidade for inválida, você verá uma tela de erro do provedor de identidade depois de clicar em LOGIN. Siga as instruções específicas do provedor para configurar corretamente o provedor ou o cluster.
Permissões inválidas
Se você concluir o fluxo de autenticação, mas ainda não vir os detalhes do cluster, verifique se concedeu as permissões RBAC corretas à conta usada com o OIDC. Ela pode ser uma conta diferente daquela que você usa para acessar o console do Google Cloud.
Token de atualização ausente
O problema a seguir ocorre quando o servidor de autorização solicita consentimento, mas o parâmetro de autenticação necessário não foi fornecido.
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
Para resolver esse problema, adicione prompt=consent
ao campo authentication.oidc.extraParams
no
arquivo de configuração do cluster. Em seguida, gere novamente o arquivo
de autenticação do cliente.
O token de atualização expirou
Esse problema ocorre quando o token de atualização no arquivo kubeconfig expirou:
Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509: certificate signed by unknown authority
Para resolver esse problema, execute o comando login
novamente.
Falha do gkectl create-login-config para getconfig
Esse problema ocorre quando o arquivo kubeconfig transmitido para
gkectl create-login-config
não é para um cluster de usuário ou o recurso personalizado ClientConfig
não é exibido durante a criação do cluster.
Error getting clientconfig using KUBECONFIG
Para resolver esse problema, verifique se você tem o arquivo kubeconfig correto para o cluster de usuário. Em seguida, verifique se o objeto ClientConfig está no cluster:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get clientconfig default -n kube-public
O gkectl create-login-config falha devido ao nome do cluster duplicado
Esse problema ocorre quando você tenta gravar dados de configuração de login que contêm um nome de cluster que já existe no arquivo de destino. Cada arquivo de configuração de login precisa conter nomes exclusivos de cluster.
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
Para resolver esse problema, use a sinalização --output
para especificar um novo arquivo
de destino.
Se você não fornecer --output
, esses dados de configuração de login serão gravados em um
arquivo chamado kubectl-anthos-config.yaml
no diretório atual.
Falha no login de autenticação do gcloud anthos com o proxyconnect tcp
Esse problema ocorre quando há um erro nas configurações da variável de ambiente
https_proxy
ou HTTPS_PROXY
. Se houver um https://
especificado nas
variáveis de ambiente, as bibliotecas de cliente HTTP do GoLang poderão falhar se o
proxy estiver configurado para processar conexões HTTPS usando outros protocolos, como
SOCK5.
Mensagem de erro possível:
proxyconnect tcp: tls: first record does not look like a TLS handshake
Para resolver esse problema, modifique as variáveis de ambiente https_proxy
e HTTPS_PROXY
para omitir o https:// prefix
. No Windows, modifique as variáveis
de ambiente do sistema. Por exemplo, altere o valor da variável de ambiente
https_proxy
de https://webproxy.example.com:8000
para
webproxy.example.com:8000
.
O acesso ao cluster falha ao usar o kubeconfig gerado por gcloud anthos auth login
Esse problema ocorre quando o servidor da API Kubernetes não consegue autorizar o usuário. Isso pode acontecer se os RBACs apropriados estiverem ausentes ou incorretos ou se houver um erro na configuração do OIDC para o cluster.
Unauthorized
Para resolver o problema:
No arquivo kubeconfig gerado pelo
gcloud anthos auth login
, copie o valor deid-token
.kind: Config … users: — name: … user: auth-provider: config: id-token: xxxxyyyy
Instale jwt-cli e execute:
jwt ID_TOKEN
Verifique a configuração do OIDC.
O
authentication.oidc
no arquivo de configuração do cluster do usuário tem os camposgroup
eusername
, que são usados para definir as sinalizações--oidc-group-claim
e--oidc-username-claim
no servidor da API Kubernetes. Ao receber o token, o servidor da API encaminha o token para o Anthos Identity Service, que retorna ogroup-claim
e ousername-claim
extraídos para o servidor AIP. O servidor da API usa a resposta para verificar se o grupo ou usuário correspondente tem as permissões corretas.Verifique se as declarações definidas para
group
euser
na seçãoauthentication.oidc
do arquivo de configuração do cluster estão presentes no token de ID.Verifique os RBACs que foram aplicados.
Verifique se há um RBAC com as permissões corretas para o usuário especificado por
username-claim
ou para um dos grupos listadosgroup-claim
da etapa anterior. O nome do usuário ou grupo no RBAC precisa ter o prefixousernameprefix
ougroupprefix
que foi especificado no arquivo de configuração do cluster de usuário.Se
usernameprefix
estiver em branco eusername
for um valor diferente deemail
, o prefixo será padronizado comoissuerurl#
. Para desativar os prefixos de nome de usuário, definausernameprefix
como-
.Para mais informações sobre prefixos de usuários e grupos, consulte Como autenticar com o OIDC.
Observe que o servidor da API Kubernetes trata uma barra invertida como um caractere de escape. Portanto, se o nome do usuário ou grupo contiver
\\
, o servidor de API o lerá como um único\
ao analisar o token de ID. Portanto, a vinculação do RBAC aplicada a esse usuário ou grupo deve conter somente uma única barra invertida. Caso contrário, você verá um erroUnauthorized
.Arquivo de configuração do cluster:
oidc: ... username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:"
Token de ID:
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\\cluster-developer", "group": [ "Domain Users", "EXAMPLE\\developers" ], ... }
As seguintes vinculações do RBAC concedem a esse grupo e ao usuário o papel de cluster
pod-reader
. Observe uma única barra no campo de nome em vez de uma barra dupla:ClusterRoleBinding do grupo:
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 do usuário:
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
Verifique os registros do servidor da API Kubernetes.
Se o plug-in OIDC configurado no servidor da API Kubernetes não for iniciado corretamente, o servidor da API retornará um erro
Unauthorized
quando apresentado com o token de ID. Para ver se houve algum problema com o plug-in OIDC no servidor da API, execute:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG logs statefulset/kube-apiserver -n USER_CLUSTER_NAME