Este documento ajuda a resolver problemas de autenticação no Google Distributed Cloud. São fornecidas informações e orientações gerais para solução de problemas, além de informações específicas para o OpenID Connect (OIDC) e o protocolo leve de acesso a diretórios (LDAP).
A autenticação OIDC e LDAP usa o GKE Identity Service. Antes de usar o serviço de identidade do GKE com o Google Distributed Cloud, configure um provedor de identidade. Se você não tiver configurado um provedor de identidade para o GKE Identity Service, siga as instruções de um dos provedores mais comuns:
Consulte o guia de solução de problemas do provedor de identidade do serviço de identidade do GKE para informações sobre como ativar e revisar registros de identidade e testar a conectividade.
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.Solução de problemas gerais
As dicas de solução de problemas a seguir ajudam com problemas gerais de autenticação e autorização com o Google Distributed Cloud. Se esses problemas não se aplicarem ou se você tiver problemas com o OIDC ou LDAP, avance para a seção de solução de problemas do GKE Identity Service.
Manter o gcloud anthos auth
atualizado
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. O comando gcloud anthos auth
tem lógica no componente principal da Google Cloud CLI e um componente anthos-auth
empacotado separadamente.
Para atualizar a Google Cloud CLI:
gcloud components update
Para atualizar o componente
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.
Configuração inválida
Se o console do Google Cloud não conseguir ler a configuração do OIDC do cluster, o botão LOGIN será desativado. Para solucionar problemas de configuração do OIDC do cluster, consulte a seção a seguir como resolver problemas do OIDC neste documento.
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. Essa pode ser uma conta diferente da 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 recurso ClientConfig
. Em seguida, gere novamente o arquivo
de autenticação do cliente.
O token de atualização expirou
O problema a seguir ocorre quando o token de atualização no arquivo kubeconfig expira:
Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
certificate signed by unknown authority
Para resolver esse problema, execute o comando gcloud anthos auth login
novamente.
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.
A seguinte mensagem de erro de exemplo pode ser retornada:
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. Este exemplo de erro pode ser exibido:
Unauthorized
Para resolver esse problema, siga estas etapas:
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 recurso
ClientConfig
tem os camposgroup
eusername
. Esses campos 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 GKE Identity Service, que retorna ogroup-claim
e ousername-claim
extraídos 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
euser
no recursoClientConfig
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 ser prefixado comusernameprefix
ougroupprefix
que foi especificado no recursoClientConfig
.Se
usernameprefix
estiver em branco eusername
for um valor diferente deemail
, o prefixo seráissuerurl#
por padrão. 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.
Recurso
ClientConfig
: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 logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Substitua:
USER_CLUSTER_NAME
: o nome do cluster de usuários para ver os registros.ADMIN_CLUSTER_KUBECONFIG
: o arquivo kubeconfig do cluster de administrador.
Falha do gkectl create-login-config para getconfig
Esse problema ocorre quando o arquivo kubeconfig transmitido para
gkectl create-login-config
não é de um cluster de usuário ou o recurso ClientConfig
não foi 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 recurso ClientConfig
está no cluster:
kubectl get clientconfig default -n kube-public \
--kubeconfig USER_CLUSTER_KUBECONFIG
Substitua USER_CLUSTER_KUBECONFIG
pelo caminho para o arquivo kubeconfig do
cluster de usuário.
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.
Resolver problemas do OIDC
Quando a autenticação do OIDC não está funcionando para o Google Distributed Cloud, normalmente a especificação
do OIDC no recurso ClientConfig
foi configurada incorretamente.
O recurso ClientConfig
fornece instruções para analisar registros e a especificação do OIDC
para ajudar a identificar a causa de um problema do OIDC.
Consulte o guia de solução de problemas do provedor de identidade do serviço de identidade do GKE para informações sobre como ativar e revisar registros de identidade e testar a conectividade. Depois de confirmar que o GKE Identity Service funciona conforme o esperado ou depois de identificar um problema, analise as seguintes informações de solução de problemas do OIDC.
Verificar a especificação do OIDC no seu cluster
As informações do OIDC do cluster são especificadas no recurso ClientConfig
no namespace kube-public
.
Use
kubectl get
para imprimir o recurso OIDC para o cluster de usuário:kubectl --kubeconfig KUBECONFIG -n kube-public get \ clientconfig.authentication.gke.io default -o yaml
Substitua
KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.Revise os valores do campo para confirmar que a especificação está configurada corretamente para o provedor OIDC.
Se você identificar um problema de configuração na especificação, reconfigure o OIDC.
Se você não conseguir diagnosticar e resolver o problema por conta própria, entre em contato com o suporte do Google Cloud.
O suporte do Google Cloud precisa dos registros do serviço de identidade do GKE e da especificação do OIDC para diagnosticar e resolver problemas do OIDC.
Verificar se a autenticação OIDC está ativada
Antes de testar a autenticação do OIDC, verifique se ela está ativada no seu cluster.
Analise os registros do GKE Identity Service:
kubectl logs -l k8s-app=ais -n anthos-identity-service
O exemplo de saída abaixo mostra que a autenticação OIDC está ativada corretamente:
... I1011 22:14:21.684580 33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started. ...
Se a autenticação OIDC não estiver ativada corretamente, erros semelhantes ao exemplo a seguir serão exibidos:
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
Analise os erros específicos informados e tente corrigi-los.
Testar a autenticação do OIDC
Para usar o recurso OIDC, use uma estação de trabalho com a IU e o navegador ativados. Não é possível realizar essas etapas em uma sessão SSH baseada em texto. Para testar se o OIDC funciona corretamente no cluster, siga estas etapas:
- Faça o download da Google Cloud CLI.
Para gerar o arquivo de configuração de login, execute o seguinte comando
gcloud anthos create-login-config
:gcloud anthos create-login-config \ --output user-login-config.yaml \ --kubeconfig KUBECONFIG
Substitua
KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.Para autenticar o usuário, execute o seguinte comando:
gcloud anthos auth login --cluster CLUSTER_NAME \ --login-config user-login-config.yaml \ --kubeconfig AUTH_KUBECONFIG
Substitua:
- CLUSTER_NAME pelo nome do cluster de usuários a ser conectado.
- AUTH_KUBECONFIG pelo novo arquivo kubeconfig a ser criado, que inclui as credenciais para acessar seu cluster. Para mais informações, consulte Autenticar no cluster.
Você receberá uma página de consentimento de login aberta no navegador da Web padrão da estação de trabalho local. Forneça informações válidas de autenticação a um usuário nessa solicitação de login.
Depois que você concluir a etapa de login anterior, um arquivo kubeconfig será gerado no diretório atual.
Para testar o novo arquivo kubeconfig que inclui suas credenciais, liste os pods no cluster de usuário:
kubectl get pods --kubeconfig AUTH_KUBECONFIG
Substitua AUTH_KUBECONFIG pelo caminho para o novo arquivo kubeconfig gerado na etapa anterior.
A mensagem de exemplo a seguir pode ser retornada, mostrando que é possível autenticar com êxito, mas não há controles de acesso com base em papéis (RBACs) atribuídos à conta:
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
Analisar registros de autenticação do OIDC
Se você não conseguir se autenticar com o OIDC, os registros do GKE Identity Service fornecerão as informações mais relevantes e úteis para depurar o problema.
Use
kubectl logs
para imprimir os registros do GKE Identity Service:kubectl --kubeconfig KUBECONFIG \ -n anthos-identity-service logs \ deployment/ais --all-containers=true
Substitua
KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.Analise os registros em busca de erros que possam ajudar a diagnosticar problemas do OIDC.
Por exemplo, o recurso
ClientConfig
pode ter um erro de digitação no campoissuerURL
, comohtps://accounts.google.com
(ausente emt
emhttps
). Os registros do GKE Identity Service conteriam uma entrada como a do exemplo a seguir:OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
Se você identificar um problema de configuração nos registros, reconfigure o OIDC e corrija os problemas de configuração.
Se você não conseguir diagnosticar e resolver o problema por conta própria, entre em contato com o suporte do Google Cloud. O suporte do Google Cloud precisa dos registros do serviço de identidade do GKE e da especificação do OIDC para diagnosticar e resolver problemas do OIDC.
Problemas comuns do OIDC
Se você tiver problemas com a autenticação do LDA, consulte os seguintes problemas comuns. Siga as orientações para resolver o problema.
Nenhum endpoint disponível para o serviço "ais"
Quando você salva o recurso ClientConfig
, a seguinte mensagem de erro é
retornada:
Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
no endpoints available for service "ais"
Esse erro é causado pelo endpoint não íntegro do GKE Identity Service. O pod do GKE Identity Service não consegue exibir o webhook de validação.
Para confirmar se o pod de serviço do GKE Identity não está íntegro, execute o seguinte comando:
kubectl get pods -n anthos-identity-service \ --kubeconfig KUBECONFIG
Substitua
KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.A saída de exemplo a seguir significa que o pod do GKE Identity Service apresenta falha:
NAME READY STATUS RESTARTS AGE ais-5949d879cd-flv9w 0/1 ImagePullBackOff 0 7m14s
Para entender por que o pod tem um problema, veja os eventos dele:
kubectl describe pod -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG
Substitua
KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.A saída de exemplo a seguir informa um erro de permissão ao extrair a imagem:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 10m default-scheduler Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5 Normal Pulling 8m23s (x4 over 10m) kubelet Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00" Warning Failed 8m21s (x4 over 10m) kubelet Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized Warning Failed 8m21s (x4 over 10m) kubelet Error: ErrImagePull Warning Failed 8m10s (x6 over 9m59s) kubelet Error: ImagePullBackOff Normal BackOff 4m49s (x21 over 9m59s) kubelet Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
Se os eventos do pod relatarem um problema, continue a solução de problemas nas áreas afetadas. Se precisar de ajuda, fale com o suporte do Google Cloud.
Falha ao ler os bytes da resposta do servidor
Você pode encontrar os seguintes erros nos registros do GKE Identity Service:
E0516 07:24:38.314681 65 oidc_client.cc:207] Failed fetching the Discovery URI
"https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
Failed reading response bytes from server.
E0516 08:24:38.446504 65 oidc_client.cc:223] Failed to fetch the JWKs URI
"https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
Failed reading response bytes from server.
Esses erros de rede podem aparecer nos registros de uma das seguintes maneiras:
Aparece pouco no registro: os erros de reserva provavelmente não são o problema principal e podem ser intermitentes.
O plug-in OIDC do GKE Identity Service tem um processo daemon para sincronizar periodicamente o URL de descoberta do OIDC a cada cinco segundos. Se a conexão de rede estiver instável, essa solicitação de saída poderá falhar. A falha ocasional não afeta a autenticação do OIDC. Os dados armazenados em cache podem ser reutilizados.
Se você encontrar erros extras nos registros, continue com as outras etapas de solução de problemas.
Eles aparecem constantemente no registro ou o GKE Identity Service nunca alcança com sucesso o endpoint conhecido: esses problemas constantes indicam um problema de conectividade entre o GKE Identity Service e seu provedor de identidade OIDC.
As seguintes etapas de solução de problemas podem ajudar a diagnosticar esses problemas de conectividade:
- Verifique se um firewall não está bloqueando as solicitações de saída do GKE Identity Service.
- Verifique se o servidor do provedor de identidade está sendo executado corretamente.
- Verifique se o URL do emissor do OIDC no recurso
ClientConfig
está configurado corretamente. - Se você tiver ativado o campo do proxy no recurso
ClientConfig
, revise o status ou o registro do servidor proxy de saída. - Teste a conectividade entre o pod do Identity Service do GKE e o servidor do provedor de identidade OIDC.
Você deve estar conectado ao servidor (não autorizado)
Ao tentar fazer login usando a autenticação OIDC, você talvez receba a seguinte mensagem de erro:
You must be logged in to the server (Unauthorized)
Esse erro é um problema geral de autenticação do Kubernetes que não fornece informações adicionais. No entanto, esse erro indica um problema de configuração.
Para determinar o problema, revise as seções anteriores sobre Verificar a especificação do OIDC no cluster e Configurar o recurso ClientConfig
.
Falha ao fazer a solicitação do autenticador de webhook
Nos registros do GKE Identity Service, você pode encontrar o seguinte erro:
E0810 09:58:02.820573 1 webhook.go:127] Failed to make webhook authenticator request:
error trying to reach service: net/http: TLS handshake timeout
Esse erro indica que o servidor da API não pode estabelecer a conexão com o pod do GKE Identity Service.
Para verificar se o endpoint do serviço de identidade do GKE pode ser acessado de fora, execute este comando
curl
:curl -k -s -o /dev/null -w "%{http_code}" -X POST \ https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
Substitua
APISERVER_HOST
pelo endereço do servidor da API.A resposta esperada é um código de status
HTTP 400
. Se a solicitação expirar, reinicie o pod do GKE Identity Service. Se o erro persistir, isso significa que o servidor HTTP do GKE Identity Service não consegue iniciar. Para receber mais ajuda, entre em contato com o suporte do Google Cloud.
URL de login não encontrado
O problema a seguir ocorre quando o console do Google Cloud não consegue se conectar ao provedor
de identidade. Uma tentativa de login é redirecionada para uma página com um erro URL not found
.
Para resolver esse problema, consulte as etapas a seguir. Após cada etapa, tente fazer login novamente:
Se o provedor de identidade não estiver acessível pela Internet pública, ative o proxy HTTP do OIDC para fazer login usando o console do Google Cloud. Edite o recurso personalizado
ClientConfig
e definauseHTTPProxy
comotrue
:kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
Substitua
USER_CLUSTER_KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.Se o proxy HTTP estiver ativado e você ainda encontrar esse erro, poderá haver um problema na inicialização do proxy. Veja os registros do proxy:
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
Substitua
USER_CLUSTER_KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.Mesmo que o provedor de identidade tenha uma AC conhecida, forneça um valor para
oidc.caPath
no recurso personalizadoClientConfig
para que o proxy HTTP seja iniciado corretamente.Se o servidor de autorização solicitar consentimento e você não tiver incluído os parâmetros
extraparam
prompt=consent
, edite o recurso personalizadoClientConfig
e adicioneprompt=consent
aos parâmetrosextraparams
:kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
Substitua
USER_CLUSTER_KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.Se as configurações forem alteradas no serviço de armazenamento, talvez seja necessário sair explicitamente das sessões atuais. No console do Google Cloud, acesse a página de detalhes do cluster e selecione Sair.
Resolver problemas no LDAP
Se você tiver problemas com a autenticação LDAP, verifique se configurou seu ambiente seguindo um dos documentos de configuração apropriados:
Também é necessário preencher a chave secreta da conta de serviço LDAP e configurar o recurso ClientConfig
para ativar a autenticação LDAP.
Consulte o guia de solução de problemas do provedor de identidade do serviço de identidade do GKE para informações sobre como ativar e revisar registros de identidade e testar a conectividade. Depois de confirmar que o GKE Identity Service funciona conforme o esperado ou depois identificar um problema, analise as seguintes informações de solução de problemas do LDAP.
Verificar se a autenticação LDAP está ativada
Antes de testar a autenticação LDAP, verifique se ela está ativada no seu cluster.
Analise os registros do GKE Identity Service:
kubectl logs -l k8s-app=ais -n anthos-identity-service
O exemplo de saída abaixo mostra que a autenticação LDAP está ativada corretamente:
... I1012 00:14:11.282107 34 plugin_list.h:139] LDAP[0] started. ...
Se a autenticação LDAP não estiver ativada corretamente, serão exibidos erros semelhantes ao seguinte exemplo:
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
Analise os erros específicos informados e tente corrigi-los.
Testar a autenticação LDAP
Para usar o recurso LDAP, use uma estação de trabalho com a IU e o navegador ativados. Não é possível realizar essas etapas em uma sessão SSH baseada em texto. Para testar se a autenticação LDAP funciona corretamente no cluster, siga estas etapas:
- Faça o download da Google Cloud CLI.
Para gerar o arquivo de configuração de login, execute o seguinte comando gcloud anthos create-login-config:
gcloud anthos create-login-config \ --output user-login-config.yaml \ --kubeconfig KUBECONFIG
Substitua
KUBECONFIG
pelo caminho para o arquivo kubeconfig do cluster de usuário.Para autenticar o usuário, execute o seguinte comando:
gcloud anthos auth login --cluster CLUSTER_NAME \ --login-config user-login-config.yaml \ --kubeconfig AUTH_KUBECONFIG
Substitua:
CLUSTER_NAME
pelo nome do cluster de usuários a ser conectado.AUTH_KUBECONFIG
pelo novo arquivo kubeconfig a ser criado, que inclui as credenciais para acessar seu cluster. Para mais informações, consulte Autenticar no cluster.
Você receberá uma página de consentimento de login aberta no navegador da Web padrão da estação de trabalho local. Forneça informações válidas de autenticação a um usuário nessa solicitação de login.
Depois que você concluir a etapa de login anterior, um arquivo kubeconfig será gerado no diretório atual.
Para testar o novo arquivo kubeconfig que inclui suas credenciais, liste os pods no cluster de usuário:
kubectl get pods --kubeconfig AUTH_KUBECONFIG
Substitua AUTH_KUBECONFIG pelo caminho para o cluster de usuário kubeconfig que foi gerado na etapa anterior.
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
Problemas comuns do LDAP
Se você tiver problemas com a autenticação LDAP, analise os seguintes problemas comuns. Siga as orientações para resolver o problema.
Os usuários não podem fazer a autenticação com vírgulas na CN
Quando você usa o LDAP, pode ter problemas em que os usuários não podem fazer a autenticação quando o CN contém uma vírgula, como CN="a,b"
. Se você ativar o registro de depuração do
GKE Identity Service, a seguinte mensagem de erro será exibida:
I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
Encountered the following error: Empty entries.
Esse problema ocorre porque o plug-in LDAP do GKE Identity Service faz o escape duplo da vírgula. Esse problema só acontece nas versões do Google Distributed Cloud 1.13 e anteriores.
Para corrigir esse problema, siga uma destas etapas:
- Faça upgrade do cluster para o Google Distributed Cloud 1.13 ou mais recente.
- Escolha um
identifierAttribute
diferente, comosAMAccountName
, em vez de usar a CN. - Remova as vírgulas da CN do seu diretório LDAP.
Falha de autenticação com a Google Cloud CLI 1.4.2
Com a Google Cloud CLI anthos-auth
1.4.2, você pode ver a seguinte mensagem de erro
ao executar o comando gcloud anthos auth login
:
Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
ERROR: Configuring Anthos authentication failed
No registro do GKE Identity Service você também encontra o seguinte erro:
I0728 12:43:01.980012 26 authentication_plugin.cc:79] Stopping STS authentication, unable to decrypt the STS token:
Decryption failed, no keys in the current key set could decrypt the payload.
Para resolver esse erro, siga estas etapas:
Verifique se você usa a versão 1.4.2 da
anthos-auth
do Google Cloud CLI:gcloud anthos auth version
O exemplo de saída abaixo mostra que a versão é 1.4.2:
Current Version: v1.4.2
Se você executar a Google Cloud CLI
anthos-auth
versão 1.4.2, faça upgrade para a versão 1.4.3 ou posterior.
Problemas comuns
Esta seção detalha problemas comuns de autenticação e como resolvê-los.
Perda de acesso à estação de trabalho do administrador devido ao erro de chave SSH permission denied
O erro a seguir ocorre quando você tenta se conectar à estação de trabalho do administrador e
recebe uma mensagem "Permission denied"
semelhante ao exemplo a seguir:
Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).
Esse erro ocorre devido ao uso de uma chave privada incorreta ou de nenhuma chave quando você se conecta à estação de trabalho do administrador usando SSH.
Para resolver esse problema, encontre e use a chave SSH correta. Se você não encontrar a chave SSH correta, gere um novo par de chaves SSH para a estação de trabalho do administrador usando as seguintes etapas:
Criar uma VM de resgate temporária. Essa VM de resgate precisa se conectar à mesma rede e Datastore que a VM atual da estação de trabalho do administrador.
Desligue a VM da estação de trabalho do administrador e a VM de resgate.
Anexe o disco de dados da VM da estação de trabalho do administrador à VM de resgate. O disco de dados geralmente tem 512 MB, a menos que você especifique um tamanho de disco diferente no arquivo de configuração da estação de trabalho do administrador, que é diferente do disco de inicialização.
Ligue a VM de resgate.
Conecte-se à VM de resgate usando SSH.
No computador local, gere um novo par de chaves SSH.
No computador local, copie a nova chave pública SSH para a VM de resgate usando o comando
ssh-copy-id
:ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
Substitua:
NEW_SSH_KEY
pelo nome da nova chave SSH que você criou na etapa anterior.RESCUE_VM
pelo endereço IP ou FQDN da VM de resgate.
Na VM de resgate, ative o disco de dados nela:
sudo mkdir -p /mnt/ext-disk sudo mount DEVICE /mnt/ext-disk
Substitua
DEVICE
pelo identificador exclusivo do seu disco, como/dev/sdb1
.Na VM de resgate, copie a nova chave pública SSH no arquivo
authorized_keys
no disco de dados montado da VM da estação de trabalho do administrador.Visualize o conteúdo do arquivo
authorized_keys
na VM de resgate, que inclui a nova chave pública SSH copiada com o comandossh-copy-id
em uma etapa anterior:ls ~/.ssh/authorized_keys
Copie a última entrada de chave pública SSH do arquivo
authorized_keys
e feche-o.Edite o arquivo
authorized_keys
no disco de dados montado da VM da estação de trabalho do administrador:vi /mnt/ext-disk/.ssh/authorized_keys
Cole o conteúdo da chave pública SSH do arquivo
authorized_keys
da VM de resgate.Salve e feche o arquivo
authorized_keys
no disco de dados montado na VM da estação de trabalho de administrador.Verifique se os arquivos em
/mnt/ext-disk/.ssh/
têm as permissões corretas aplicadas a eles:chown -R ubuntu /mnt/ext-disk/.ssh/* chmod -R 600 /mnt/ext-disk/.ssh/*
Saia da conexão SSH para a VM de resgate.
Encerre a VM de resgate.
Desconecte o disco de dados da VM de resgate e conecte-o novamente à VM da estação de trabalho de administrador.
Ligue a estação de trabalho de administrador.
Depois que a VM estiver em execução, conecte-se à estação de trabalho do administrador usando SSH e o novo par de chaves SSH.
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM
Substitua:
NEW_SSH_KEY
pelo nome da nova chave SSH que você criou em uma etapa anterior e copiou para a VM da estação de trabalho do administrador.RESCUE_VM
pelo endereço IP ou FQDN da VM da estação de trabalho do administrador.
Verifique se é possível se conectar usando SSH.
Exclua a VM de resgate.