Uma nova versão dos clusters do Anthos na AWS (GKE na AWS) foi lançada em 3 de junho. 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. Este tópico abrange o processo em geral para ajudar você a entender como configurar qualquer provedor OpenID.

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.

Como escolher um provedor de 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 do OpenID.

Como 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.

Como configurar 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.

Como 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.

Como registrar aplicativos cliente com o provedor de 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.

Como configurar o cluster

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

Para configurar a autenticação do OIDC, você precisa configurar o AWSCluster CRD 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

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.

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
    

Como realizar a autenticação

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.

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:   AUTHORITY_DATA
      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

A seguir

Implante a primeira carga de trabalho nos clusters do Anthos na AWS.