O GKE On-Prem é compatível com o OpenID Connect (OIDC) para autenticação em clusters de usuários por meio da linha de comando. Veja os seguintes tópicos:
Para fazer login por meio do Console do Google Cloud, o GKE On-Prem usa um token de portador da conta de serviço do Kubernetes. Consulte Como fazer login em .
Este tópico pressupõe que você conheça o OAuth 2.0 e o OpenID Connect. Também é necessário conhecer escopos e declarações no contexto da autenticação do OpenID.
Visão geral
Use o OIDC para gerenciar o acesso a um cluster do Kubernetes com os procedimentos padrão da organização para criar, ativar e desativar contas de funcionários. Também é possível usar os grupos de segurança da sua organização para configurar o acesso a um cluster do Kubernetes ou a serviços específicos no cluster.
Um usuário faz login em um provedor OpenID apresentando um nome de usuário e uma senha.
O provedor de OpenID emite um token de ID para o usuário. O token é assinado pelo provedor.
Um aplicativo, atuando em nome do usuário, envia uma solicitação HTTPS para o servidor da API Kubernetes. O aplicativo inclui o token de ID do usuário no cabeçalho da solicitação.
O servidor da API Kubernetes verifica o token usando o certificado do provedor.
Se sua empresa executa um servidor de Serviços de federação do Active Directory (ADFS, na sigla em inglês). O servidor ADFS pode servir como seu provedor de OpenID. Outra opção é usar um terceiro como seu provedor de OpenID, por exemplo, Google, Microsoft, Facebook e Twitter são todos provedores de OpenID.
Como usar o plug-in do Kubectl para OIDC para chamar o servidor da API Kubernetes
Normalmente, um usuário insere um comando
kubectl
e, como resultado, kubectl chama o servidor da API Kubernetes.
Para que isso funcione, o token de ID do usuário precisa estar no arquivo kubeconfig. O GKE On-Prem fornece o plug-in do Kubectl para OIDC para incluir o token e outros valores OIDC no kubeconfig.
O servidor da API Kubernetes e o token de ID
Quando kubectl chama o servidor da API Kubernetes em nome do usuário, o servidor da API
verifica o token usando o certificado público do provedor OpenID.
Em seguida, o servidor da API analisa o token para saber a identidade do usuário e os
grupos de segurança dele.
O servidor da API determina se o usuário está autorizado a fazer essa chamada, comparando os grupos de segurança do usuário com a política de controle de acesso baseado em papéis (RBAC, na sigla em inglês) do cluster.