Como fazer a autenticação com o OpenID Connect (OIDC)

Saiba como configurar o GKE na AWS para usar o OpenID Connect (OIDC) para autenticação em clusters de usuário. Neste tópico, abordamos o processo de configuração do GKE na AWS com qualquer provedor OpenID.

Para fazer upgrade de um cluster que usa a autenticação OIDC para o Kubernetes 1.21, consulte Fazer upgrade para a versão 1.21.

Para uma visão geral do fluxo de autenticação do GKE na AWS, consulte Autenticação.

Visão geral

O GKE na AWS é compatível com o OIDC como um dos mecanismos de autenticação para interagir com o servidor da API Kubernetes de um cluster de usuário. Com o OIDC, é possível gerenciar o acesso aos clusters do Kubernetes usando os procedimentos padrão na organização para criar, ativar e desativar contas de usuário.

Antes de começar

• Este tópico pressupõe que você já conhece os seguintes conceitos de autenticação e OpenID:

  • OAuth 2.0
  • OpenID Connect
  • Escopos
  • declarações.

• A Google Cloud CLI precisa ser instalada na máquina local de cada desenvolvedor.

• Sistemas headless não são compatíveis. Para autenticar, é preciso abrir um navegador na máquina local executando a CLI gcloud. O navegador solicitará que você autorize sua conta de usuário.

• Para autenticar pelo console Google Cloud , cada cluster que você quer configurar para autenticação OIDC precisa ser registrado com Google Cloud.

Perfis

Este tópico se refere a três perfis:

• Administrador da organização: essa pessoa escolhe um provedor OpenID e registra aplicativos cliente com o provedor.

• Administrador de cluster: essa pessoa cria um ou mais clusters de usuário e cria arquivos de configuração de autenticação para desenvolvedores que usam os clusters.

• Desenvolvedor: essa pessoa executa cargas de trabalho em um ou mais clusters e usa o OIDC para fazer a autenticação.

Escolher um provedor OpenID

Esta seção é destinada a administradores da organização.

É possível usar qualquer provedor OpenID da sua escolha. Para ver uma lista de provedores certificados, consulte Certificação OpenID.

Criar URLs de redirecionamento

Esta seção é destinada a administradores da organização.

O provedor OpenID usa URLs de redirecionamento para retornar tokens de ID. É preciso criar URLs de redirecionamento para a CLI gcloud e o consoleGoogle Cloud .

Definir o URL de redirecionamento da CLI gcloud

Ao configurar o provedor OpenID, especifique o URL de redirecionamento da CLI como http://localhost:PORT/callback

Substitua PORT pelo número da porta maior que 1024.

Definir o URL de redirecionamento do Google Cloud console

O URL de redirecionamento do console Google Cloud é:

https://console.cloud.google.com/kubernetes/oidc

Ao configurar o provedor OIDC, especifique https://console.cloud.google.com/kubernetes/oidc como um dos URLs de redirecionamento.

Registrar seus aplicativos cliente com o provedor OpenID

Esta seção é destinada a administradores da organização.

Antes que os desenvolvedores possam usar a Google Cloud CLI ou o console Google Cloud com seu provedor OpenID, você precisa registrar esses dois clientes com o provedor OpenID. O registro inclui estas etapas:

• Saiba o URI do emissor do provedor. A CLI gcloud ou o consoleGoogle Cloud envia solicitações de autenticação para esse URI.

• Configure seu provedor com o URL de redirecionamento, incluindo seu número de porta, para a CLI gcloud.

• Configure seu provedor com o URL de redirecionamento do console do Google Cloud , https://console.cloud.google.com/kubernetes/oidc.

• Crie um único ID do cliente que seu provedor use para identificar a Google Cloud CLI e o consoleGoogle Cloud .

• Crie uma única chave secreta do cliente que a CLI gcloud e o console Google Cloud usam para fazer a autenticação no provedor do OpenID.

• Crie um escopo personalizado que a CLI gcloud ou o console Google Cloud podem usar para solicitar os grupos de segurança do usuário.

• Crie um nome de declaração personalizado que o provedor usa para retornar os grupos de segurança do usuário.

Configurar o cluster

Esta seção é destinada aos administradores de cluster.

Para configurar a autenticação do OIDC, você precisa configurar o recurso AWSCluster do cluster do usuário com os detalhes da autenticação de um cluster. Os detalhes do AWSCluster são usados para configurar o OIDC do console Google Cloud e do plug-in de autenticação para o GKE Enterprise. A configuração inclui as seguintes informações do OIDC:

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET 
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

Campos de autenticação

A tabela a seguir descreve os campos do objeto authentication.awsIAM.adminIdentityARNs.

Exemplo: como autorizar usuários e grupos

Muitos provedores codificam propriedades de identificação do usuário, como IDs de e-mail e usuário, em um token. No entanto, essas propriedades têm riscos implícitos para políticas de autenticação:

• Os IDs do usuário podem dificultar a leitura e a auditoria das políticas.
• O uso de endereços de e-mail pode criar um risco de disponibilidade (se um usuário alterar o e-mail principal) e um risco de segurança (se for possível reatribuir um e-mail).

Em vez de atribuir IDs de usuário, recomendamos políticas de grupo, que podem ser persistentes e mais fáceis de auditar.

Suponha que seu provedor crie tokens de identidade que incluam os seguintes campos:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

Dado esse formato de token, você preencheria a especificação oidc do arquivo de configuração da seguinte maneira:

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

Depois de criar o cluster de usuário, use o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes para conceder acesso privilegiado aos usuários autenticados.

No exemplo a seguir, você cria um ClusterRole que concede aos usuários acesso somente leitura aos secrets do cluster e cria um recurso ClusterRoleBinding para vincular o papel ao grupo autenticado.

1. Defina um ClusterRole. Copie o seguinte YAML para um arquivo chamado secret-reader-role.yaml.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-reader
   rules:
   - apiGroups: [""]
     # The resource type for which access is granted
     resources: ["secrets"]
     # The permissions granted by the ClusterRole
     verbs: ["get", "watch", "list"]
   

2. Defina um ClusterRoleBinding. Copie o seguinte YAML para um arquivo chamado secret-reader-admins.yaml.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: read-secrets-admins
   subjects:
     # Allows anyone in the "us-east1-cluster-admins" group to
     # read Secrets in any namespace within this cluster.
   - kind: Group
     name: gid-us-east1-cluster-admins # Name is case sensitive
     apiGroup: rbac.authorization.k8s.io
     # Allows this specific user to read Secrets in any
     # namespace within this cluster
   - kind: User
     name: uid-u98523-4509823
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-reader
     apiGroup: rbac.authorization.k8s.io
   

3. Aplique secret-reader-role.yaml e secret-reader-admins.yaml ao seu cluster com kubectl.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl apply -f secret-reader-role.yaml && \
     kubectl apply -f secret-reader-admins.yaml
   

   Os usuários que receberam acesso em read-secrets-admins agora têm acesso para ler secrets no cluster.

Criar uma configuração de login

Esta seção é destinada aos administradores de cluster.

Depois de criar um cluster de usuário, você precisa gerar um arquivo de configuração para o cluster usando gcloud anthos create-login-config.

1. No diretório anthos-aws, use anthos-gke para alternar o contexto para o cluster de usuário.

   cd anthos-aws
   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials CLUSTER_NAME

   Substitua CLUSTER_NAME pelo nome do cluster de usuários.

2. Crie a configuração com gcloud anthos.

   gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
   

   Substitua usercluster-kubeconfig pelo caminho para o arquivo kubeconfig do cluster de usuário. No Linux e no macOS, esse arquivo fica em ~/.kube/config por padrão.

Este comando gera um arquivo (kubectl-anthos-config.yaml) com as informações de configuração que os desenvolvedores usarão para autenticação no cluster com a CLI gcloud. Não modifique esse arquivo.

Para entender mais sobre o conteúdo de kubectl-anthos-config.yaml, consulte o apêndice.

Distribuir a configuração de login

Distribua o arquivo de configuração para os usuários que precisam se autenticar nos clusters de usuário. Para distribuir a configuração, faça o seguinte:

• Coloque o arquivo no diretório padrão.
• Distribua o arquivo de forma segura.
• Hospede o arquivo em um servidor HTTPS.

Diretórios padrão de configuração de login

Os locais padrão para armazenar o arquivo de configuração para cada SO são os seguintes:

Linux

$HOME/.config/google/anthos/kubectl-anthos-config.yaml, em que $HOME é o diretório inicial do usuário.

macOS

$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml, em que $HOME é o diretório inicial do usuário.

Windows

%APPDATA%/google/anthos/kubectl-anthos-config.yaml, em que %APPDATA% é o diretório de dados do aplicativo do usuário.

Depois que a configuração de login for distribuída, seus desenvolvedores estarão prontos para configurar a CLI gcloud para acessar o cluster.

Modificar seu cluster após o upgrade para o Kubernetes 1.21

Depois de fazer upgrade do cluster para o Kubernetes 1.21, você precisa configurar o GKE Identity Service e remover as informações do OIDC da configuração do cluster. Para atualizar a configuração, execute as seguintes etapas:

1. Siga as etapas em Fazer upgrade do cluster.

2. No diretório anthos-aws, use anthos-gke para alternar o contexto para o cluster de usuário.

   cd anthos-aws
   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials CLUSTER_NAME

   Substitua CLUSTER_NAME pelo nome do cluster de usuários.

3. Abra o manifesto que contém o AWSCluster em um editor de texto. Mantenha o arquivo aberto e use os valores do objeto oidc para seguir as etapas em Como configurar clusters para o GKE Identity Service.

4. No diretório anthos-aws, use anthos-gke para alternar o contexto para o serviço de gerenciamento.

   cd anthos-aws
   anthos-gke aws management get-credentials

5. Abra o arquivo YAML que criou o AWSCluster em um editor de texto. Se você não tiver o arquivo YAML inicial, poderá usar kubectl edit.

   Editar YAML

   Se você tiver seguido as instruções em Como criar um cluster de usuário, seu arquivo YAML será chamado de cluster-0.yaml. Abra esse arquivo em um editor de texto.

   kubectl edit

   Para usar kubectl edit para editar seu AWSCluster, execute o seguinte comando:

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl edit awscluster cluster-name
   

   Substitua cluster-name pelo AWSCluster. Por exemplo, para editar o cluster padrão, cluster-0, execute o seguinte comando:

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl edit awscluster cluster-0
   

6. Exclua o objeto oidc do manifesto do cluster.

7. Salve o arquivo. Se você estiver usando kubectl edit, kubectl aplicará as alterações automaticamente. Se você estiver editando o arquivo YAML, aplique-o ao serviço de gerenciamento com o seguinte comando:

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl apply -f cluster-0.yaml
   

   O serviço de gerenciamento atualiza seu AWSCluster.

Como configurar o gcloud para acessar o cluster

Esta seção é destinada a desenvolvedores ou administradores de clusters.

Pré-requisitos

Para concluir esta seção, você precisa concluir o seguinte:

• Uma configuração de login.

• Uma versão atualizada da CLI gcloud com os componentes anthos-auth.

  gcloud components update
  gcloud components install anthos-auth
  

• Para confirmar se a CLI gcloud foi instalada com êxito, execute o comando a seguir, que precisa responder com detalhes sobre os argumentos necessários e as opções disponíveis.

  gcloud anthos auth
  

Fazer a autenticação no cluster

Você pode se autenticar em seu cluster das seguintes maneiras:

• Com a CLI gcloud na sua máquina local.
• Com a CLI gcloud em uma máquina remota usando um túnel SSH.

• Com o Connect no console Google Cloud .

gcloud anthos auth login --cluster CLUSTER_NAME

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Como atualizar a configuração do OIDC

Para atualizar a configuração do OIDC no cluster, use o comando kubectl edit.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

A ferramenta kubectl carrega o recurso ClientConfig no editor padrão. Para atualizar a configuração, salve o arquivo. A ferramenta kubectl atualiza o recurso ClientConfig no cluster.

Para informações sobre o conteúdo do recurso ClientConfig, consulte a seção a seguir.

Apêndice: exemplo de configuração de login

Segue um exemplo kubectl-anthos-config.yaml. Este exemplo é incluído para entender o conteúdo. É necessário sempre gerar o arquivo com gcloud anthos create-login-config.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

Para ver explicações sobre o conteúdo do campo, consulte Campos de autenticação.

A seguir

Implante sua primeira carga de trabalho no GKE na AWS.