Você sabia que o kubectl pode executar binários arbitrários, incluindo shell scripts, com os privilégios totais do seu usuário e sem que você perceba?
Sempre que você baixa ou gera automaticamente um kubeconfig, o campo users[n].exec.command pode especificar um executável para buscar credenciais em seu nome. Embora este seja um recurso poderoso para autenticação com provedores de identidade externos (IAM), ele abre uma brecha crítica de segurança: você confia plenamente em todos os executáveis que seu kubeconfig está chamando?
Se houver um ataque de supply-chain no código que gera o arquivo ou se o pipeline de CI/CD for comprometido, um invasor pode executar códigos maliciosos na máquina de desenvolvedores e administradores de sistemas. Para mitigar esse risco e dar mais controle aos times de infraestrutura, o Kubernetes v1.35 introduziu a política de plugins de credenciais e a allowList como um recurso em beta.
O Impacto Prático para Empresas Brasileiras
No cenário brasileiro, onde muitas empresas utilizam múltiplos provedores de cloud e ferramentas de autenticação customizadas, o controle sobre o que é executado localmente é vital para o SecOps. Esta atualização permite que as organizações definam padrões de segurança não apenas no cluster, mas no próprio ambiente de trabalho da engenharia.
Disponível para todos os clientes que utilizam a biblioteca client-go, a v1.35 permite configurar o kubectl para impor políticas através do arquivo de configuração kuberc. Ao adicionar os campos credentialPluginPolicy e credentialPluginAllowlist, você restringe quais plugins o kubectl tem permissão para disparar.
Como funciona na prática
Abaixo, exploramos as novas opções de configuração no kuberc. O recurso está em beta e não exige o uso de feature gates.
O exemplo a seguir mantém o comportamento padrão: todos os plugins são permitidos.
apiversion: kubectl.config.k8s.io/v1beta1
kind: Preference
Para maior clareza e governança, o ideal é ser explícito:
apiversion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: AllowAll
Se você deseja adotar uma postura de Zero Trust em suas estações de trabalho, pode bloquear tudo preventivamente:
apiversion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: DenyAll
Ao tentar executar um comando com essa política, o kubectl retornará um erro caso um plugin tente ser acionado:
Unable to connect to the server: getting credentials: plugin "cloudco-login" not allowed: policy set to "DenyAll"
Permitindo Plugins Seletivamente
Para empresas que dependem de plugins como o aws-iam-authenticator ou gke-gcloud-auth-plugin, a opção Allowlist é a mais adequada. Ela permite listar exatamente quais binários são confiáveis:
apiversion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
- name: /usr/local/bin/cloudco-login
- name: get-identity
Note que você pode usar o caminho completo ou apenas o nome base (que será resolvido via exec.LookPath). Recomendamos o uso do caminho completo para evitar ataques de substituição de binários no PATH do sistema.
Evolução e Próximos Passos
O SIG CLI já planeja melhorias para as versões futuras, como a verificação de checksum (sha256). Isso garantirá que o binário não foi apenas permitido pelo nome, mas que o seu conteúdo é exatamente o esperado.
Para gestores de TI no Brasil, essa mudança sinaliza a importância de olhar para a segurança do client-side com o mesmo rigor dedicado ao RBAC dos clusters. Implementar um kuberc padronizado via ferramentas de gestão de máquinas (MDM) pode reduzir drasticamente o risco de exfiltração de credenciais através de arquivos kubeconfig maliciosos.
Artigo originalmente publicado por Peter Engelbert (Microsoft) e Ben Petersen (Microsoft) em Kubernetes Blog.
