Uma nova versão dos clusters do Anthos na AWS (GKE na AWS) foi lançada em 29 de setembro. Consulte as Notas de lançamento para mais informações.

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

Saiba como configurar os clusters do Anthos na AWS (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 de clusters do Anthos na AWS (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 dos clusters do Anthos no fluxo de autenticação da AWS, consulte Autenticação.

Visão geral

Os clusters do Anthos na AWS são compatíveis 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:

  • O SDK do Cloud e a ferramenta de linha de comando gcloud precisam ser instalados no computador local de cada desenvolvedor.

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

  • Para autenticar por meio do Console do Google Cloud, cada cluster que você quer configurar para autenticação OIDC precisa ser registrado no 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 ferramenta gcloud e o Console do Cloud.

Definir o URL de redirecionamento da ferramenta 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 Console do Cloud

O URL de redirecionamento do Console do 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 seus desenvolvedores possam usar a ferramenta de linha de comando gcloud ou o Console do Cloud com seu provedor de OpenID, você precisa registrar esses dois clientes com o provedor OpenID. O registro inclui estas etapas:

  • Saiba o URI do emissor do provedor. A ferramenta gcloud ou o Console do 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 ferramenta gcloud.

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

  • Crie um único ID do cliente que seu provedor usa para identificar a ferramenta de linha de comando gcloud e o Console do Cloud.

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

  • Crie um escopo personalizado que a ferramenta gcloud ou o Console do Cloud possa 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 do Cloud e do plug-in de autenticação para o Anthos. 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.

A tabela a seguir descreve os campos do oidc.
Campo Obrigatório Descrição Formato
adminIdentityARNs Sim, se você estiver configurando o OIDC. O Amazon Resource Name (ARN) das identidades do IAM da AWS (usuários ou papéis) concedeu acesso de administrador do cluster pelos clusters do Anthos na AWS. Exemplo: arn:aws:iam::123456789012:group/Developers String
Campo Obrigatório Descrição Formato
certificateAuthorityData Não Um certificado codificado em PEM codificado em base64 para o provedor OIDC. Para criar a string, codifique o certificado, incluindo cabeçalhos, em base64. Inclua a string resultante em certificateAuthorityData como uma única linha. Exemplo: certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT== String
clientID Sim ID do aplicativo cliente que faz solicitações de autenticação para o provedor OpenID. String
clientSecret Não Senha secreta compartilhada entre o aplicativo cliente do OIDC e o provedor OIDC. String
parâmetros extras Não Parâmetros de chave-valor extras a serem enviados ao provedor OpenID. Se você estiver autorizando um grupo, transmita resource=token-groups-claim.

Se o servidor de autorização solicitar consentimento, para autenticação com o Microsoft Azure e o Okta, defina extraParams como prompt=consent. Para o Cloud Identity, defina extraParams como prompt=consent,access_type=offline.

Lista delimitada por vírgulas
groupsClaim Não Declaração do JWT que o provedor usa para retornar grupos de segurança. String
groupPrefix Não Prefixo anexado a declarações de grupo para evitar conflitos com nomes existentes. Por exemplo, se você tiver dois grupos chamados foobar, adicione um prefixo gid-, o grupo de resultados será gid-foobar. String
issuerURI Sim URL ao qual são enviadas solicitações de autorização para seu OpenID, como https://example.com/adfs. O servidor da API Kubernetes usa esse URL a fim de descobrir chaves públicas para verificação de tokens. O URI precisa usar HTTPS. String do URL
kubectlRedirectURI Sim O URL de redirecionamento "kubectl" usa para autorização. String do URL
scopes Sim Outros escopos a serem enviados ao provedor OpenID. O Microsoft Azure e o Okta exigem o escopo offline_access. Lista delimitada por vírgulas
userClaim Não Declaração do JWT a ser usada como nome de usuário. É possível escolher outras declarações, como e-mail ou nome, dependendo do provedor OpenID. No entanto, as declarações diferentes de e-mail são prefixadas com o URL do emissor para evitar conflitos de nomenclatura. String
userPrefix Não Prefixo anexado a declarações de nome de usuário para evitar conflitos com nomes que já existem. String

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 ferramenta 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 ferramenta 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 Anthos 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 Anthos 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 ferramenta 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 ferramenta gcloud na sua máquina local.
  • Com a ferramenta gcloud em uma máquina remota usando um túnel SSH.
  • Com o Connect no Console do Google Cloud.

gcloud local

Use gcloud anthos auth login para autenticar no cluster com a configuração de login.

Se você colocou a configuração de login no local padrão e tiver o nome do cluster configurado, poderá usar gcloud anthos auth login sem opções. Também é possível configurar o cluster, o usuário e outros detalhes de autenticação com parâmetros opcionais.

Padrão

gcloud anthos auth login --cluster CLUSTER_NAME

Substitua CLUSTER_NAME por um nome de cluster totalmente qualificado. Por exemplo, projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a.

Parâmetros opcionais

gcloud anthos auth login é compatível com os seguintes parâmetros opcionais:

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

Os parâmetros são descritos na tabela a seguir.

Parâmetro Descrição
cluster O nome do cluster para autenticação. O padrão é o cluster em "kubectl-anthos-config.yaml".
user Nome de usuário para credenciais em kubeconfig. O padrão é {cluster-name}-anthos-default-user.
login-config O caminho que redireciona ao arquivo de configuração gerado pelo administrador do cluster para o desenvolvedor ou um URL que hospeda o arquivo. O padrão é kubectl-anthos-config.yaml.
login-config-cert Se você estiver usando um URL para login-config, é o caminho que redireciona ao arquivo de certificado de CA para criar conexões HTTPS.
kubeconfig Caminho para o arquivo kubeconfig que contém tokens. O padrão é $HOME/.kube/config`.
Simulação Teste as opções de linha de comando sem alterar a configuração ou o cluster.

O comando gcloud anthos login inicia um navegador que solicita que o usuário faça login com as credenciais empresariais, realize a troca de credenciais OIDC e adquira os tokens relevantes. Em seguida, a ferramenta gcloud grava os tokens em um arquivo kubeconfig. kubectl usa este arquivo para se autenticar no cluster do usuário.

Para confirmar se a autenticação foi bem-sucedida, execute qualquer comando kubectl com o arquivo kubeconfig:

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

túnel gcloud

Se você quiser se autenticar em um cluster de usuário a partir de uma máquina remota, realize a autenticação usando um túnel SSH. Para usar um túnel, o arquivo de configuração de autenticação precisa estar na máquina remota e você precisa acessar o provedor de Open ID na máquina local.

Na máquina local, execute o comando a seguir:

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Substitua:

  • USERNAME por um usuário que tenha acesso SSH à máquina remota.

  • REMOTE_MACHINE pelo nome do host ou endereço IP da máquina remota.

  • LOCAL_PORT é uma porta disponível na máquina local que ssh usa para fazer o túnel para a máquina remota.

  • REMOTE_PORT é a porta que você configurou para o URL de redirecionamento do OIDC. O número da porta faz parte do campo kubectlRedirectURI do seu arquivo de configuração de autenticação.

No shell SSH, execute o comando a seguir para iniciar a autenticação:

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

Substitua AUTH_CONFIG_FILE pelo caminho do arquivo de configuração de autenticação na máquina remota. A ferramenta gcloud executa um servidor da Web na máquina remota.

Na máquina local, em um navegador, acesse http://localhost:LOCAL_PORT/login e siga o fluxo de login do OIDC.

O arquivo kubeconfig na sua máquina remota agora tem o token para acessar o cluster do usuário.

No shell SSH, verifique se você tem acesso ao cluster de usuário:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Console

Autentique-se com o Console do Google Cloud, inicie o fluxo de autenticação na página de clusters do Kubernetes no Console do Cloud:

  1. Abra o Console do Cloud:

    Acessar a página de clusters do Kubernetes

  2. Localize os clusters do Anthos no cluster da AWS na lista e clique em Fazer login.

  3. Selecione Autenticar com o provedor de identidade configurado para o cluster e clique em LOGIN.

    Você será redirecionado para seu provedor de identidade, onde talvez seja necessário fazer login ou consentimento para o Console do Cloud acessar sua conta. Em seguida, você será redirecionado de volta para a página de clusters do Kubernetes no Console do Cloud.

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"
  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 a primeira carga de trabalho nos clusters do Anthos na AWS.