Resolva problemas de acesso do utilizador

Este documento fornece orientações de resolução de problemas para problemas de acesso de utilizadores quando usa fornecedores de identidade de terceiros para autenticar clusters de membros da frota.

O dispositivo gcloud anthos create-login-config não consegue obter clientconfig

Este problema ocorre num dos seguintes casos:

  • O ficheiro kubeconfig transmitido a gcloud anthos create-login-config está incorreto.
  • O recurso personalizado ClientConfig não está presente no cluster (a autenticação de terceiros não está configurada no cluster).

Mensagem de erro

  failed to get clientconfig default in namespace kube-public

Solução

Para resolver este problema, faça o seguinte:

  1. Certifique-se de que tem o ficheiro kubeconfig correto para o seu 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 ClientConfig no cluster. Para mais informações sobre as opções de configuração de clusters, consulte o artigo Opções de configuração para clusters.

A criação do gcloud anthos create-login-config falha devido a um nome de cluster duplicado

Este problema ocorre se tentar criar uma configuração de início de sessão para um cluster num ficheiro que já contém uma configuração de início de sessão 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 este problema, use a flag --output para especificar um novo ficheiro de destino.

Se não fornecer --output, estes dados de configuração de início de sessão são escritos num ficheiro denominado kubectl-anthos-config.yaml no diretório atual.

gcloud anthos auth login falha com proxyconnect tcp

Este problema ocorre quando existe um erro nas configurações das variáveis de ambiente https_proxy ou HTTPS_PROXY. Se existir um https:// especificado nas variáveis de ambiente, as bibliotecas de clientes HTTP GoLang podem falhar se o proxy estiver configurado para processar ligações HTTPS através de outros protocolos, como o SOCK5.

Mensagem de erro

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

Solução

Para resolver este 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 quando usa o kubeconfig gerado por gcloud anthos auth login

Este problema ocorre quando o servidor da API Kubernetes não consegue autorizar o utilizador por um dos seguintes motivos:

  • Existe um erro na configuração usada para iniciar sessão com o comando gcloud anthos auth login.
  • As políticas de RBAC necessárias estão incorretas ou em falta para o utilizador.

Mensagem de erro

  Unauthorized

Solução

Para resolver este problema, faça o seguinte:

  1. Valide a configuração usada para iniciar sessão.

    Configuração do OIDC

    A secção authentication.oidc no ficheiro de configuração do cluster de utilizadores tem os campos group e username que são usados para definir os indicadores --oidc-group-claim e --oidc-username-claim no servidor da API Kubernetes. Quando o servidor da API recebe um token de identidade de um utilizador, encaminha o token para o cluster, que devolve o group-claim extraído e o username-claim ao servidor da API. O servidor da API usa a resposta para verificar se o grupo ou o utilizador correspondente tem as autorizações corretas.

    Verifique se as reivindicações definidas para group e user na secção authentication.oidc do ficheiro de configuração do cluster estão presentes no token de ID.

  2. Valide as políticas de RBAC aplicadas.

    Para saber como configurar as políticas de CABF corretas, consulte o artigo Configure o controlo de acesso baseado em funções (CABF).

As RBACs para grupos não funcionam para fornecedores OIDC

  1. Verifique 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 OIDC, o token de ID é armazenado no ficheiro kubeconfig no campo id-token. Use jwt.io para descodificar o token de ID e verificar se contém as informações do grupo do utilizador conforme esperado.

  2. Se o token de ID não tiver informações de grupo do utilizador, configure corretamente o fornecedor de OIDC para devolver as informações de grupo de acordo com a documentação do seu fornecedor de OIDC. Por exemplo, se estiver a usar a configuração do OIDC do fornecedor de identidade Okta, siga a documentação do fornecedor de identidade Okta 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 de grupo no token de ID corresponde ao campo groupsClaim configurado na secção oidc.

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

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

    então, o valor do campo groupsClaim deve ser groups na secção oidc.

    Depois de modificar a configuração na secção oidc, certifique-se de que executa novamente as instruções indicadas em Configurar o acesso do utilizador e Aceder a clusters.

Resolva problemas de fornecedores de identidade

Se tiver problemas ao usar o OIDC ou o LDAP com o seu cluster, siga os passos nesta secção para resolver esses problemas e ajudar a determinar se existe um problema com a configuração do seu fornecedor de identidade.

Ative o registo de depuração

Para ajudar a resolver problemas relacionados com a identidade no seu cluster, ative os registos de depuração para pods na aisimplementação.

  1. Aplique uma patch ao cluster existente 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 o seguinte:

    • LOG_LEVEL: para os registos mais detalhados, defina este valor como nível 3 durante a resolução de problemas.

    • KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de utilizadores.

Verifique o registo do contentor

Reveja o conteúdo dos registos do contentor para verificar se existem erros ou avisos.

  1. Para rever os registos, use kubectl logs:

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

    Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.

Reinicie o Pod

Se os registos do contentor mostrarem problemas, reinicie o pod.

  1. Para reiniciar o Pod, elimine o Pod existente. É criado automaticamente um novo Pod como substituição.

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

    Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.

Resolva problemas de conetividade com o Fornecedor de identidade

Se o Pod parecer estar a ser executado corretamente, teste a conetividade ao fornecedor de identidade remoto.

  1. Inicie um pod busybox no mesmo espaço de nomes:

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

    Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.

  2. Para verificar se consegue obter o URL de descoberta, execute o comando no pod busybox e execute o comando curl:

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

    Substitua o seguinte:

    • ISSUER_URL: o URL do emissor do seu fornecedor de identidade.
    • KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de utilizadores.

    Uma resposta bem-sucedida é um resultado JSON com os pontos finais detalhados do fornecedor de identidade.

  3. Se o comando anterior não devolver o resultado esperado, contacte o administrador do fornecedor de identidade para receber assistência adicional.

O início de sessão LDAP não funciona para o cluster de administrador do Google Distributed Cloud

Atualmente, o LDAP só é suportado para o cluster de utilizadores do Google Distributed Cloud.