O produto descrito nesta documentação, os clusters do Anthos na AWS (geração anterior), agora está no modo de manutenção. Todas as novas instalações precisam usar o produto de geração atual Clusters do Anthos na AWS.

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:
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 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 CLI gcloud e o console do Google 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 console do Google Cloud

O URL de redirecionamento do Console do 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 do 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 console do Google 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 console do Google Cloud.
Crie uma única chave secreta do cliente que a CLI gcloud e o console do Google Cloud usam para fazer a autenticação no provedor OpenID.
Crie um escopo personalizado que a CLI gcloud ou o console do 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 do Google 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.

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"]

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

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.

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

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 Anthos Identity Service e remover as informações do OIDC da configuração do cluster. Para atualizar a configuração, execute as seguintes etapas:

Siga as etapas em Fazer upgrade do cluster.
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.
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.
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
```
Observação: anthos-gke usa as credenciais especificadas quando você executou aws configure.
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
```
Exclua o objeto oidc do manifesto do cluster.
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 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 CLI 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 CLI 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

É possível autenticar com o console do Google Cloud e iniciar o fluxo de autenticação na página de clusters do Kubernetes no console do Google Cloud:

Abra o Console do Google Cloud:

Acessar a página de clusters do Kubernetes
Localize os clusters do Anthos no cluster da AWS na lista e clique em Fazer login.
Selecione Autenticar com o provedor de identidade configurado para o cluster e clique em LOGIN.

Você será redirecionado para o provedor de identidade, onde talvez seja necessário fazer login ou consentir para que o Console do Google Cloud acesse sua conta. Em seguida, você será redirecionado de volta para a página de clusters do Kubernetes no console do Google 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"
    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 a primeira carga de trabalho nos clusters do Anthos na AWS.

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

Visão geral

Antes de começar

Perfis

Escolher um provedor OpenID

Criar URLs de redirecionamento

Definir o URL de redirecionamento da CLI gcloud

Definir o URL de redirecionamento do console do Google Cloud

Registrar seus aplicativos cliente com o provedor OpenID

Configurar o cluster

Campos de autenticação

Exemplo: como autorizar usuários e grupos

Criar uma configuração de login

Distribuir a configuração de login

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

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

Editar YAML

kubectl edit

Como configurar o gcloud para acessar o cluster

Pré-requisitos

Fazer a autenticação no cluster

gcloud local

Padrão

Parâmetros opcionais

túnel gcloud

Console

Como atualizar a configuração do OIDC

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

A seguir