Executando verificação de segurança...
2
danieldia
3 min de leitura ·

Usando o gke-gcloud-auth-plugin do WSL dentro do Lens

TL;DR

O Lens roda no Windows, mas o gke-gcloud-auth-plugin está apenas no WSL.

Então o Lens tenta executar o plugin no Windows → e falha.

A solução é fazer o kubeconfig chamar o plugin via WSL:

user:
  exec:
    apiVersion: client.authentication.k8s.io/v1beta1
    command: wsl.exe
    args:
      - bash
      - -lc
      - /home/daniel/google-cloud-sdk/bin/gke-gcloud-auth-plugin

Assim o Windows chama o WSL, o plugin roda no Linux, e o Lens conecta normalmente.

O Problema

No WSL tudo funcionava perfeitamente:

kubectl get ns

Mas ao importar o kubeconfig no Lens (Windows) apareceu o erro:

exec: executable gke-gcloud-auth-plugin not found

Isso acontece por causa de como o kubeconfig gerado pelo GKE funciona.

Quando você roda:

gcloud container clusters get-credentials ...

O gcloud adiciona no kubeconfig algo assim:

exec:
  command: gke-gcloud-auth-plugin

Ou seja:

Sempre que o kubectl precisar de credenciais, execute esse binário.

O problema é onde isso roda.

Fluxo real:

  1. Lens roda no Windows
  2. O kubeconfig é lido pelo Windows
  3. O Windows tenta executar gke-gcloud-auth-plugin
  4. Mas esse binário só existe no WSL

Resultado: autenticação falha.

Por que eu não instalei o plugin no Windows

Em alguns ambientes isso simplesmente não é possível.

No meu caso:

  • sem permissão de admin
  • sem winget
  • sem instalar componentes do gcloud
  • possíveis problemas de ARM64

Então instalar gke-gcloud-auth-plugin.exe no Windows não era uma opção.

A alternativa foi fazer o Windows chamar o plugin dentro do WSL.

A Solução: Executar o plugin via WSL

O kubeconfig permite definir qualquer comando no exec.

Então ao invés de chamar o plugin diretamente, usamos o wsl.exe.

Configuração final:

user:
  exec:
    apiVersion: client.authentication.k8s.io/v1beta1
    command: wsl.exe
    args:
      - bash
      - -lc
      - /home/daniel/google-cloud-sdk/bin/gke-gcloud-auth-plugin
    interactiveMode: IfAvailable
    provideClusterInfo: true

Por que isso funciona

Agora o Lens executa:

wsl.exe bash -lc /home/daniel/google-cloud-sdk/bin/gke-gcloud-auth-plugin

Fluxo completo:

  1. Windows executa wsl.exe
  2. WSL inicia
  3. bash inicia como login shell
  4. O plugin roda no Linux
  5. Ele retorna as credenciais em JSON
  6. O Lens recebe as credenciais e conecta no cluster

Para o Kubernetes isso continua sendo apenas um exec credential plugin normal.

Por que usar bash -lc

Esse detalhe é importante.

bash -lc garante:

  • shell de login
  • PATH correto
  • variáveis do gcloud carregadas
  • ambiente igual ao terminal

Se chamar o binário diretamente, muitas vezes falha porque o ambiente não foi inicializado.

Tradeoffs

Esse método funciona bem, mas tem alguns pontos:

  • cada refresh de token inicia o WSL
  • um pouco mais lento que plugin nativo no Windows
  • se o WSL parar, o Lens perde conexão

Mesmo assim, em ambientes restritos, funciona muito bem.

Quando usar essa abordagem

Esse método faz sentido quando:

  • você gera o kubeconfig dentro do WSL
  • não pode instalar ferramentas no Windows
  • quer continuar usando autenticação do gcloud
  • não quer criar tokens estáticos de ServiceAccount

Resultado final

Depois dessa pequena alteração no kubeconfig:

  • nenhuma instalação no Windows foi necessária
  • o Lens conecta normalmente
  • autenticação do GKE funciona via WSL

Uma pequena mudança no kubeconfig resolve um problema que pode ser bem frustrante de diagnosticar.

Carregando publicação patrocinada...