É possível se autenticar nos clusters do Anthos em clusters bare metal usando o OpenID Connect (OIDC). O OIDC é uma camada de autenticação criada com base no OAuth 2.0 que especifica uma API HTTP RESTful e usa JSON como formato de dados.
Com o OIDC, você usa seu provedor de identidade atual para gerenciar a autenticação de usuários e grupos em clusters do Anthos em clusters bare metal. Com o OIDC, você pode gerenciar o acesso a clusters do Anthos em um cluster bare metal usando os procedimentos padrão na sua organização para criar, ativar e desativar contas. Também é possível usar os grupos de segurança da sua organização para configurar o acesso a um cluster ou a serviços específicos em um cluster. O acesso gerenciado funciona em qualquer tipo de Anthos no cluster Bare Metal: administrador, usuário, híbrido ou independente.
Os clusters do Anthos em bare metal são compatíveis com provedores de identidade locais e acessíveis ao público. Por exemplo, no local, é possível usar um componente dos Serviços de federação do Active Directory. Também é possível usar serviços de provedor de identidade de acesso público do Google ou da Okta. Além disso, os certificados de provedor de identidade podem ser emitidos por uma autoridade de certificação pública (CA, na sigla em inglês) conhecida ou por uma CA particular.
Há dois métodos de autenticação do OIDC disponíveis para os usuários:
Autenticação OIDC por meio de uma interface de linha de comando (CLI, na sigla em inglês) em que os usuários executam um comando gcloud e são autenticados por meio de uma página de login/consentimento no navegador.
Autenticação OIDC por meio da IU do console do Google Cloud: os usuários fazem login em um cluster diretamente da página de clusters do Kubernetes. Este método exige que seu cluster esteja registrado no Google Cloud. Os clusters são registrados automaticamente durante o Anthos em uma instalação de cluster Bare Metal.
O OIDC não é compatível com fluxos de trabalho sem cabeçalho: o OIDC requer uma autenticação baseada em navegador para redirecionar os usuários à página da Web do provedor de identidade e para solicitar o consentimento e o login/senha de conta.
Controle de acesso do OIDC e Kubernetes
A autenticação OIDC é frequentemente combinada com o Controle de acesso baseado em papéis do Kubernetes (RBAC, na sigla em inglês). Com o RBAC, é possível criar políticas de autorização granulares que definem quais usuários ou grupos podem executar operações específicas em um determinado conjunto de recursos do cluster.
Visão geral da autenticação do OIDC
Uma autenticação típica do OIDC inclui as seguintes etapas:
- Um usuário faz login em um provedor de 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 e é retornado por meio de um URL de callback pré-configurado.
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 de ID usando o certificado do provedor e analisa o token para aprender a identidade do usuário e, se presente, os grupos do usuário.
Geralmente, há três perfis envolvidos na configuração e autenticação do OIDC:
O administrador da organização, que escolhe um provedor OpenID e registra aplicativos cliente com o provedor.
Um administrador de plataforma que cria um ou mais clusters e arquivos de configuração de autenticação para usuários que usam os clusters.
Um operador ou desenvolvedor de aplicativos que executa cargas de trabalho em um ou mais clusters e usa o OIDC para autenticação.
Você pode usar qualquer provedor OpenID certificado (os provedores são certificados pela OpenID Foundation). O processo de registro específico depende do provedor, mas normalmente inclui as seguintes etapas:
Descobrir o URI do emissor do provedor. É aqui que a CLI gcloud ou o Console do Google Cloud envia solicitações de autenticação.
Informe ao provedor os URLs de redirecionamento para a CLI gcloud e o console do Google Cloud.
Estabeleça um ID e uma chave secreta do cliente. A CLI gcloud e o console do Google Cloud usam esse ID/chave secreta do cliente para autenticar no provedor do OpenID.
Estabeleça um escopo personalizado e uma reivindicação para grupos de segurança. Em geral, você precisa definir as políticas de RBAC de cluster com base em grupos, em vez de usuários para tornar as políticas mais estáveis e auditáveis. A maioria dos provedores OIDC inclui reivindicações de grupo em tokens de ID se os escopos apropriados forem solicitados. As declarações e os escopos de grupos específicos são diferentes entre os provedores OIDC. Portanto, estabelecer esses escopos e declarações específicos do provedor requer personalização.
Antes de instalar um novo cluster Anthos em um cluster bare metal, o administrador da plataforma normalmente recebe a configuração OIDC do administrador da organização e configura os campos OIDC relevantes na configuração do cluster.
Após a instalação do cluster, o administrador da plataforma recebe os arquivos de configuração de autenticação e os compartilha com os usuários da CLI. Normalmente, o administrador da plataforma compartilha a configuração de autenticação hospedando os arquivos em um host seguro ou usando ferramentas internas para enviar os arquivos de configuração para a máquina de cada usuário. Em seguida, os usuários da CLI autenticam o novo cluster com os arquivos de configuração compartilhados.
O administrador da plataforma também pode armazenar os detalhes da configuração de autenticação para vários clusters em um único arquivo de configuração de autenticação.
Observe que os usuários do console do Google Cloud não precisam desses arquivos de configuração.
Quando os usuários acessam o console do Google Cloud, eles podem selecionar Authenticate
with the Identity Provider configurados para o cluster e clicar em Login.