Resolver problemas de acesso do usuário

Neste documento, fornecemos orientações de solução de problemas para acesso do usuário no GKE Identity Service.

gcloud anthos create-login-config não consegue acessar clientconfig

Esse problema ocorre em um dos seguintes casos:

• O arquivo kubeconfig transmitido para gcloud anthos create-login-config está incorreto.
• O recurso personalizado ClientConfig não está presente no cluster. O GKE Identity Service não está instalado no cluster.

Mensagem de erro

  failed to get clientconfig default in namespace kube-public
  

Solução

Para resolver esse problema, faça o seguinte:

1. Verifique se você tem o arquivo kubeconfig correto para o cluster.

2. Para verificar se o recurso personalizado ClientConfig está no cluster, execute o seguinte comando:

   kubectl --kubeconfig KUBECONFIG  get clientconfig default -n kube-public
   

   Se o ClientConfig não estiver presente no cluster, instale e configure o GKE Identity Service no cluster. Para mais informações sobre as opções de configuração de cluster, consulte Opções de configuração de clusters.

gcloud anthos create-login-config falha devido a um nome de cluster duplicado

Esse problema ocorre se você tentar criar uma configuração de login para um cluster em um arquivo que já contenha uma configuração de login para este cluster.

Mensagem de erro

  error merging with file FILENAME because FILENAME contains a
    cluster with the same name as the one read from KUBECONFIG.
  

Solução

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.

gcloud anthos auth login falha com 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

  proxyconnect tcp: tls: first record does not look like a TLS handshake
  

Solução

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 por um dos seguintes motivos:

• Há um erro na configuração usada para fazer login com o comando gcloud anthos auth login.
• As políticas do RBAC necessárias estão incorretas ou ausentes para o usuário.

Mensagem de erro

  Unauthorized
  

Solução

Para resolver esse problema, faça o seguinte:

1. Verifique a configuração usada para fazer login.

   Configuração do OIDC

   A seção authentication.oidc no arquivo de configuração do cluster de usuário tem os campos group e username usados para definir as sinalizações --oidc-group-claim e --oidc-username-claim no servidor da API Kubernetes. Quando o servidor da API é apresentado com o token de identidade de um usuário, ele encaminha o token para o GKE Identity Service, que retorna o group-claim e o username-claim extraídos de volta para o servidor da API. 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 e user na seção authentication.oidc do arquivo de configuração do cluster estão presentes no token de ID.

2. Verificar as políticas de RBAC aplicadas.

   Para saber como configurar as políticas corretas do RBAC para o GKE Identity Service, consulte Configurar o controle de acesso baseado em função (RBAC).

RBACs para grupos que não funcionam com provedores OIDC

Observação: as instruções de solução de problemas a seguir são aplicáveis apenas se o provedor estiver configurado na seção oidc do recurso personalizado ClientConfig e o campo enableAccessToken estiver definido como false.

1. Verificar se o token de ID tem as informações do grupo

   Depois de executar o comando gcloud anthos auth login para iniciar o fluxo de autenticação do OIDC, o token de ID será armazenado no arquivo kubeconfig no campo id-token. Use jwt.io para decodificar o token de ID e verificar se ele contém as informações de grupo do usuário, conforme o esperado.

2. Se o token de ID não tiver informações do grupo do usuário, configure corretamente o provedor OIDC para retornar as informações do grupo de acordo com a documentação do provedor OIDC. Por exemplo, se estiver usando a configuração OIDC do provedor de identidade Okta, siga a documentação do provedor para configurar grupos no token de ID.

3. Se o token de ID tiver informações de grupo, verifique se a chave de informações no token de ID corresponde ao campo groupsClaim configurado na seção oidc.

   Por exemplo, se o token de ID contiver informações do grupo na chave groups:

   "groups" : ["group1", "group2" ...]
   

   o valor do campo groupsClaim será groups na seção oidc.

   Depois de modificar a configuração na seção oidc, execute as instruções listadas em Configurar o acesso do usuário e Como acessar clusters novamente.

Solução de problemas de provedores de identidade

Se você tiver problemas para usar o OIDC ou LDAP com o cluster do GKE, siga as etapas desta seção para resolver problemas do GKE Identity Service e ajudar a determinar se há um problema com a configuração do provedor de identidade.

Ativar o registro de depuração do GKE Identity Service

Para ajudar a resolver problemas relacionados à identidade no cluster, ative o registro de depuração do GKE Identity Service.

1. Corrija o cluster atual com kubectl patch:

   kubectl patch deployment ais \
     -n anthos-identity-service --type=json \
     -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \
     --kubeconfig KUBECONFIG
   

   Substitua:

   • LOG_LEVEL: para registros mais detalhados, defina esse valor no nível 3 ao resolver problemas.

     Observação: esse valor pode ser definido como 9. No entanto, nesse nível, ele pode revelar algumas informações de credenciais no seu console.

   • KUBECONFIG: o caminho para o arquivo kubeconfig do cluster de usuário.

Verificar o registro de contêiner do GKE Identity Service

Analise se há erros ou avisos no conteúdo dos registros de contêiner do GKE Identity Service.

1. Para analisar os registros, use kubectl logs:

   kubectl logs -f -l k8s-app=ais \
     -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.

Reinicie o pod do GKE Identity Service

Se os registros do contêiner mostrarem problemas, reinicie o pod do GKE Identity Service.

1. Para reiniciar o pod do GKE Identity Service, exclua o pod atual. Um novo pod é criado automaticamente como substituição.

   kubectl delete pod -l k8s-app=ais \
     -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.

Resolver problemas de conectividade com o provedor de identidade

Se o pod do GKE Identity Service estiver em execução corretamente, teste a conectividade com o provedor de identidade remoto.

1. Inicie um pod movimentado no mesmo namespace que o pod do GKE Identity Service:

   kubectl run curl --image=radial/busyboxplus:curl \
     -n anthos-identity-service -- sleep 3000 \
     --kubeconfig KUBECONFIG
   

   Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.

2. Para verificar se é possível buscar o URL de descoberta, execute no pod movimentado e execute o comando curl:

   kubectl exec pod/curl -n anthos-identity-service -- \
     curl ISSUER_URL \
     --kubeconfig KUBECONFIG
   

   Substitua:

   • ISSUER_URL: o URL do emissor do provedor de identidade.
   • KUBECONFIG: o caminho para o arquivo kubeconfig do cluster de usuário.

   Uma resposta bem-sucedida é um resultado JSON com os endpoints detalhados do provedor de identidade.

3. Se o comando anterior não retornar o resultado esperado, entre em contato com o administrador do provedor de identidade para receber mais ajuda.

O login LDAP não está funcionando no cluster de administrador do Google Distributed Cloud

No momento, o LDAP é compatível apenas com o cluster de usuário do Google Distributed Cloud.