Um material publicado no blog da CNCF recomenda tratar o controle de acesso a clusters Kubernetes como parte da lista de configuração básica, juntamente com redes e armazenamento, especialmente em ambientes autogerenciados que normalmente não oferecem integração IAM ou SSO pronta como ocorre nos serviços Kubernetes gerenciados. A ideia central é usar um provedor de identidade compatível com OIDC, como o Keycloak, registrando o cliente como um cliente público que usa PKCE, e não como um cliente confidencial portador de uma chave compartilhada.
Em muitos clusters locais, o acesso depende de um certificado de cliente estático ou de um token de longa duração emitido uma única vez. Esses dados continuam válidos mesmo após a saída do funcionário, a mudança de sua função ou a perda do dispositivo que os contém. Além disso, revogar o acesso exige encontrar todas as cópias do arquivo de certificado ou do token, um processo cuja conclusão é difícil de garantir quando há vários dispositivos e usuários. Com o aumento do número de pessoas e a diferença entre os níveis de permissão, distribuir e gerenciar arquivos se transforma em uma tarefa operacional contínua.
O que muda com o OIDC?
Em vez de vincular a permissão a um arquivo de certificado, ela passa a estar vinculada à conta do usuário e à sua associação a grupos do provedor de identidade. A integração é composta por três partes interligadas: a ferramenta kubectl com a extensão kubelogin ou kubectl oidc-login, o provedor de identidade, que autentica o usuário e emite o token de identidade, e o servidor kube-apiserver, que valida o token, extrai o nome de usuário e os grupos e então deixa que o Kubernetes RBAC determine as operações permitidas.
O kubectl não se conecta primeiro ao servidor da API para iniciar o login. A extensão exec-credential inicia o login pelo navegador no provedor de identidade e depois devolve o token de identidade ao kubectl para que seja enviado como credencial do portador do token. O servidor da API valida o token usando as chaves públicas de assinatura do provedor de identidade. Segundo o material, o servidor não precisa de uma conexão contínua com o provedor de identidade, exceto para buscar essas chaves quando necessário.
Por que o cliente deve ser público?
O cliente confidencial emite uma chave que é adicionada às configurações da extensão kubelogin e distribuída a cada dispositivo que precisa de acesso. O material considera que uma chave que precisa ser distribuída a todos os clientes já não é realmente secreta, mas sim uma credencial estática compartilhada difícil de rotacionar. Em aplicações de linha de comando e aplicações nativas, a opção mais adequada é um cliente público sem segredo, com PKCE, ou Proof Key for Code Exchange, habilitado.
O cliente cria localmente um valor aleatório e envia um hash dele na solicitação inicial de login; depois, comprova que possui o valor original ao trocar o código de autorização por um token de acesso. Assim, quem interceptar apenas o código de autorização não poderá concluir o processo. As configurações do Keycloak apresentadas no material recomendam desativar a autenticação do cliente, habilitar o fluxo padrão, desativar a concessão de acesso direto e exigir PKCE usando S256, além de restringir os endereços de redirecionamento e as origens web a endereços de loopback como 127.0.0.1 e localhost.
Etapas básicas de configuração
- Adicionar o mapeador de associação a grupos ao escopo do cliente no Keycloak, para que uma declaração com o nome groups apareça dentro do token de identidade.
- Configurar o kube-apiserver usando flags como oidc-issuer-url, oidc-client-id, oidc-username-claim e oidc-groups-claim.
- Adicionar oidc-ca-file se o provedor de identidade usar um certificado não assinado por uma autoridade pública confiável, para que o servidor da API possa validar a conexão TLS e buscar as chaves de assinatura.
- Modificar o kubeconfig para usar uma entrada exec-credential por meio do kubectl oidc-login, em vez de incluir certificados ou tokens estáticos, sem adicionar um campo de segredo.
- Vincular grupos do provedor de identidade a funções do Kubernetes RBAC, como vincular o grupo platform-viewer à função view.
Impacto prático e limitações
Depois desse vínculo, as alterações de acesso são feitas no provedor de identidade: adicionando o usuário a um grupo ou removendo-o dele, em vez de modificar o cluster ou redistribuir o kubeconfig. O próximo token emitido pelo usuário conterá a nova associação ao grupo, e a regra de RBAC vinculada a ela será aplicada. O material explica que o primeiro login abre o navegador, enquanto o kubelogin reutiliza o token armazenado em cache até que ele expire e, depois, usa o token de atualização sem uma nova rodada no navegador. A identidade e os grupos efetivos podem ser verificados por meio do comando kubectl auth whoami.
Isso não significa que a integração esteja livre de requisitos operacionais. É necessário configurar a declaração de grupos com precisão, validar o certificado do provedor de identidade, restringir os endereços de redirecionamento e garantir que as funções de RBAC reflitam as permissões necessárias. O material também não apresenta medições independentes do tempo de configuração ou do custo operacional; estima apenas que a preparação possa ser concluída durante um único período de trabalho, e não por meio de uma migração completa da plataforma.
O principal benefício de segurança e administração é que os registros do Kubernetes passam a estar vinculados à identidade real do usuário. Registros que dependem de uma conta geral, como cluster-admin, não distinguem os responsáveis pelas solicitações, enquanto cada solicitação emitida via OIDC contém o nome do usuário e os grupos associados a ele. Esta é uma leitura editorial baseada nos detalhes do material: a melhoria não está apenas na forma de fazer login, mas também na capacidade de atribuir as ações aos seus responsáveis, tornando a concessão e a revogação de permissões um processo centralizado de identidade, em vez de uma busca por arquivos de credenciais distribuídos.