O produto descrito nesta documentação, Anthos Clusters na AWS (geração anterior), está em modo de manutenção . Todas as novas instalações devem usar o produto da geração atual, Anthos Clusters na AWS .

Esta página foi traduzida pela API Cloud Translation.

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 utilizadores. Este tópico aborda o processo de configuração do GKE na AWS com qualquer fornecedor OpenID.

Para atualizar um cluster que usa a autenticação OIDC para o Kubernetes 1.21, consulte o artigo Atualize para a versão 1.21.

Para uma vista geral do fluxo de autenticação do GKE on AWS, consulte o artigo Autenticação.

Vista geral

O GKE na AWS suporta o OIDC como um dos mecanismos de autenticação para interagir com o servidor da API Kubernetes de um cluster de utilizadores. Com o OIDC, pode gerir o acesso aos clusters do Kubernetes através dos procedimentos padrão na sua organização para criar, ativar e desativar contas de utilizador.

Antes de começar

Este tópico pressupõe que conhece os seguintes conceitos de autenticação e OpenID:
A CLI do Google Cloud tem de estar instalada na máquina local de cada programador.
Os sistemas sem ecrã não são suportados. Para se autenticar, tem de abrir um navegador na máquina local que executa a CLI gcloud. Em seguida, o navegador pede-lhe que autorize a sua conta de utilizador.
Para autenticar através da Google Cloud consola, cada cluster que quer configurar para a autenticação OIDC tem de ser registado no Google Cloud.

Personagens fictícias

Este tópico refere-se a três perfis fictícios:

Administrador da organização: esta pessoa escolhe um fornecedor OpenID e regista aplicações cliente junto do fornecedor.
Administrador do cluster: esta pessoa cria um ou mais clusters de utilizadores e cria ficheiros de configuração de autenticação para programadores que usam os clusters.
Programador: esta pessoa executa cargas de trabalho num ou mais clusters e usa o OIDC para autenticar.

Escolha um fornecedor OpenID

Esta secção destina-se a administradores da organização.

Pode usar qualquer fornecedor OpenID à sua escolha. Para ver uma lista de fornecedores certificados, consulte a página Certificação OpenID.

Crie URLs de redirecionamento

Esta secção destina-se a administradores da organização.

O fornecedor OpenID usa URLs de redirecionamento para devolver tokens de ID. Tem de criar URLs de redirecionamento para a CLI gcloud e a consolaGoogle Cloud .

Defina o URL de redirecionamento da CLI gcloud

Quando configurar o seu fornecedor OpenID, especifique o URL de redirecionamento da CLI como http://localhost:PORT/callback

Substitua PORT pelo seu número da porta superior a 1024.

Defina o Google Cloud URL de redirecionamento da consola

O URL de redirecionamento para a consola Google Cloud é:

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

Quando configurar o seu fornecedor de OIDC, especifique https://console.cloud.google.com/kubernetes/oidc como um dos seus URLs de redirecionamento.

Registe as suas aplicações cliente junto do fornecedor do OpenID

Esta secção destina-se a administradores da organização.

Antes de os seus programadores poderem usar a CLI Google Cloud ou a Google Cloud consola com o seu fornecedor OpenID, tem de registar esses dois clientes no fornecedor OpenID. O registo inclui estes passos:

Conheça o URI do emissor do seu fornecedor. A CLI gcloud ou aGoogle Cloud consola enviam pedidos de autenticação para este URI.
Configure o seu fornecedor com o URL de redirecionamento, incluindo o número da porta, para a CLI gcloud.
Configure o seu fornecedor com o URL de redirecionamento para a Google Cloud consola, https://console.cloud.google.com/kubernetes/oidc.
Crie um único ID do cliente que o seu fornecedor usa para identificar a CLI Google Cloud e a Google Cloud consola.
Crie um único segredo do cliente que a CLI gcloud e a Google Cloud consola usam para fazer a autenticação no fornecedor OpenID.
Crie um âmbito personalizado que a CLI gcloud ou a Google Cloud consola possa usar para pedir os grupos de segurança do utilizador.
Crie um nome de reivindicação personalizado que o fornecedor usa para devolver os grupos de segurança do utilizador.

Configure o cluster

Esta secção destina-se a administradores de clusters.

Para configurar a autenticação OIDC, tem de configurar o recurso AWSCluster do cluster de utilizadores com detalhes de autenticação para um cluster. Os detalhes do AWSCluster são usados para configurar o OIDC para a Google Cloud consola e o plug-in de autenticação para o GKE. 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 seguinte descreve os campos do objeto authentication.awsIAM.adminIdentityARNs.

A tabela seguinte descreve os campos do objeto `oidc`.

Campo	Obrigatória	Descrição	Formato
adminIdentityARNs	Sim, se estiver a configurar o OIDC.	Nome de recurso da Amazon (ARN) das identidades do IAM da AWS (utilizadores ou funções) com acesso de administrador do cluster concedido pelo GKE na AWS. Exemplo: `arn:aws:iam::123456789012:group/Developers`	String

Campo	Obrigatória	Descrição	Formato
certificateAuthorityData	Não	Um certificado codificado em PEM codificado em base64 para o fornecedor OIDC. Para criar a string, codifique o certificado, incluindo os cabeçalhos, em base64. Inclua a string resultante em `certificateAuthorityData` como uma única linha. Exemplo: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	String
clientID	Sim	ID da aplicação cliente que faz pedidos de autenticação ao fornecedor OpenID.	String
clientSecret	Não	Segredo partilhado entre a aplicação cliente OIDC e o fornecedor OIDC.	String
extraParams	Não	Parâmetros de chave-valor adicionais a enviar para o fornecedor do OpenID. Se estiver a autorizar um grupo, transmita `resource=token-groups-claim`. Se o seu servidor de autorização pedir consentimento para autenticação com o Microsoft Azure e o Okta, defina `extraParams` como `prompt=consent`. Para o Cloud ID, defina `extraParams` como `prompt=consent,access_type=offline`.	Lista delimitada por vírgulas
groupsClaim	Não	Afirmação JWT que o fornecedor usa para devolver os seus grupos de segurança.	String
groupPrefix	Não	Prefixo adicionado às reivindicações de grupos para evitar conflitos com nomes existentes. Por exemplo, se tiver dois grupos denominados `foobar` add a prefix `gid-`, o grupo resultante é `gid-foobar`.	String
issuerURI	Sim	URL para onde são enviados pedidos de autorização para o seu OpenID, como `https://example.com/adfs`. O servidor da API Kubernetes usa este URL para descobrir chaves públicas para validar tokens. O URI tem de usar HTTPS.	String de URL
kubectlRedirectURI	Sim	O URL de redirecionamento que o `kubectl` usa para autorização.	String de URL
âmbitos	Sim	Âmbitos adicionais a enviar para o fornecedor OpenID. O Microsoft Azure e o Okta requerem o âmbito `offline_access`.	Lista delimitada por vírgulas
userClaim	Não	Reivindicação JWT a usar como nome de utilizador. Pode escolher outras reivindicações, como o email ou o nome, consoante o fornecedor OpenID. No entanto, as reivindicações que não sejam o email têm o prefixo do URL do emissor para evitar conflitos de nomes.	String
userPrefix	Não	Prefixo adicionado às reivindicações de nomes de utilizador para evitar conflitos com nomes existentes.	String

Exemplo: autorizar utilizadores e grupos

Muitos fornecedores codificam propriedades de identificação do utilizador, como o email e os IDs dos utilizadores, num token. No entanto, estas propriedades têm riscos implícitos para as políticas de autenticação:

Os IDs de utilizadores podem dificultar a leitura e a auditoria das políticas.
A utilização de endereços de email pode criar um risco de disponibilidade (se um utilizador alterar o respetivo email principal) e um risco de segurança (se um email puder ser reatribuído).

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

Suponhamos que o seu fornecedor cria tokens de identidade que incluem os seguintes campos:

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

Dado este formato de token, preencheria a especificação oidc do ficheiro de configuração da seguinte forma:

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

Depois de criar o cluster de utilizadores, usa o controlo de acesso baseado em funções (RBAC) do Kubernetes para conceder acesso privilegiado aos utilizadores autenticados.

No exemplo seguinte, cria um ClusterRole que concede aos respetivos utilizadores acesso apenas de leitura aos segredos do cluster e cria um recurso ClusterRoleBinding para associar a função ao grupo autenticado.

Definir um ClusterRole. Copie o seguinte YAML para um ficheiro com o nome 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"]

Definir um ClusterRoleBinding. Copie o seguinte YAML para um ficheiro com o nome 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 utilizadores aos quais foi concedido acesso no read-secrets-admins têm agora acesso para ler segredos no seu cluster.

Crie uma configuração de início de sessão

Esta secção destina-se a administradores de clusters.

Depois de criar um cluster de utilizadores, tem de gerar um ficheiro de configuração para o cluster através do gcloud anthos create-login-config.

No diretório do anthos-aws, use anthos-gke para mudar o contexto para o cluster de utilizadores.
```
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 utilizadores.
Crie a configuração com gcloud anthos.
```
gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
```
Substitua usercluster-kubeconfig pelo caminho para o ficheiro kubeconfig do cluster de utilizadores. No Linux e macOS, por predefinição, este ficheiro encontra-se em ~/.kube/config.

Este comando gera um ficheiro (kubectl-anthos-config.yaml) que contém as informações de configuração que os seus programadores usam para autenticar no cluster com a CLI gcloud. Não deve modificar este ficheiro.

Para saber mais sobre o conteúdo de kubectl-anthos-config.yaml, consulte o anexo.

Distribua o ficheiro de configuração aos utilizadores que precisam de autenticar os seus clusters de utilizadores. Pode distribuir a configuração das seguintes formas:

Colocar o ficheiro no diretório predefinido.
Distribuir o ficheiro em segurança.
Alojamento do ficheiro num servidor HTTPS.

Diretórios predefinidos de configuração de início de sessão

As localizações predefinidas para armazenar o ficheiro de configuração para cada SO são as seguintes:

Linux: $HOME/.config/google/anthos/kubectl-anthos-config.yaml, onde $HOME é o diretório home do utilizador.
macOS: $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml, onde $HOME é o diretório base do utilizador.
Windows: %APPDATA%/google/anthos/kubectl-anthos-config.yaml, onde %APPDATA% é o diretório de dados da aplicação do utilizador.

Depois de a configuração de início de sessão ter sido distribuída, os programadores estão prontos para configurar a CLI gcloud para aceder ao cluster.

Modifique o cluster após a atualização para o Kubernetes 1.21

Depois de atualizar o cluster para o Kubernetes 1.21, tem de configurar o GKE Identity Service e remover as informações do OIDC da configuração do cluster. Para atualizar a configuração, siga estes passos:

Siga os passos em Atualize o cluster.
No diretório do anthos-aws, use anthos-gke para mudar o contexto para o cluster de utilizadores.
```
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 utilizadores.
Abra o manifesto que contém o AWSCluster num editor de texto. Mantenha o ficheiro aberto e use os valores do objeto oidc para seguir os passos em Configurar clusters para o GKE Identity Service.
No diretório do anthos-aws, use anthos-gke para mudar o contexto para o seu serviço de gestão.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
Nota: anthos-gke usa as credenciais que especificou quando executou aws configure.
Abra o ficheiro YAML que criou o seu AWSCluster num editor de texto. Se não tiver o ficheiro YAML inicial, pode usar kubectl edit.
Edite o YAML
Se seguiu as instruções em Criar um cluster de utilizadores, o seu ficheiro YAML tem o nome cluster-0.yaml. Abra este ficheiro num editor de texto.
kubectl edit
Para usar o kubectl edit para editar o seu AWSCluster, execute o seguinte comando:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name
```
Substitua cluster-name pelo seu AWSCluster. Por exemplo, para editar o cluster predefinido, cluster-0, execute o seguinte comando:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0
```
Elimine o objeto oidc do manifesto do cluster.
Guarde o ficheiro. Se estiver a usar o kubectl edit, o kubectl aplica as alterações automaticamente. Se estiver a editar o ficheiro YAML, aplique-o ao seu serviço de gestão com o seguinte comando:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml
```
Em seguida, o serviço de gestão atualiza o AWSCluster.

Configurar o gcloud para aceder ao cluster

Esta secção destina-se a programadores ou administradores de clusters.

Pré-requisitos

Para concluir esta secção, tem de fazer o seguinte:

Uma configuração de início de sessão.

Uma versão atualizada da CLI gcloud com os anthos-authcomponentes.

gcloud components update
gcloud components install anthos-auth

Verifique se a CLI gcloud foi instalada com êxito executando o comando seguinte, que deve responder com detalhes sobre os argumentos necessários e as opções disponíveis.
```
gcloud anthos auth
```

Autentique o cluster

Pode autenticar-se no cluster das seguintes formas:

Com a CLI gcloud na sua máquina local.
Com a CLI gcloud numa máquina remota através de um túnel SSH.
Com a funcionalidade Estabelecer ligação na consola Google Cloud .

gcloud local

Use gcloud anthos auth login para fazer a autenticação no cluster com a sua configuração de início de sessão.

Se colocou a configuração de início de sessão na localização predefinida e tiver o nome do cluster configurado, pode usar gcloud anthos auth login sem opções. Também pode configurar o cluster, o utilizador e outros detalhes de autenticação com parâmetros opcionais.

Predefiniçã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

O elemento gcloud anthos auth login suporta 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 estão descritos na tabela seguinte.

Parâmetro	Descrição
`cluster`	O nome do cluster para autenticação. A predefinição é o cluster em `kubectl-anthos-config.yaml`.
`user`	Nome de utilizador para credenciais em `kubeconfig`. A predefinição é `{cluster-name}-anthos-default-user`.
`login-config`	O caminho para o ficheiro de configuração gerado pelo administrador do cluster para o programador ou um URL que aloja o ficheiro. A predefinição é `kubectl-anthos-config.yaml`.
`login-config-cert`	Se usar um URL para `login-config`, o caminho para o ficheiro do certificado da AC para fazer ligações HTTPS.
`kubeconfig`	Caminho para o ficheiro kubeconfig que contém tokens. A predefinição é $HOME/.kube/config`.
execução de ensaio	Teste as opções da linha de comandos sem alterar a configuração nem o cluster.

O comando gcloud anthos login inicia um navegador que pede ao utilizador para iniciar sessão com as respetivas credenciais empresariais, efetua a troca de credenciais OIDC e adquire os tokens relevantes. Em seguida, a CLI gcloud escreve os tokens num ficheiro kubeconfig. A app kubectl usa este ficheiro para se autenticar no cluster de utilizadores.

Para verificar se a autenticação foi bem-sucedida, execute qualquer comando kubectl com o seu ficheiro kubeconfig:

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

gcloud tunnel

Se quiser autenticar-se num cluster de utilizadores a partir de uma máquina remota, pode fazer a autenticação através de um túnel SSH. Para usar um túnel, o ficheiro de configuração de autenticação tem de estar na máquina remota, e tem de conseguir aceder ao fornecedor Open ID a partir da máquina local.

Na sua máquina local, execute o seguinte comando:

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Substitua o seguinte:

USERNAME com um utilizador que tenha acesso SSH à máquina remota.
REMOTE_MACHINE com o nome de anfitrião ou o endereço IP da máquina remota.
LOCAL_PORT é uma porta disponível na sua máquina local que ssh usa para criar um túnel para a máquina remota.
REMOTE_PORT é a porta que configurou para o URL de redirecionamento do OIDC. O número da porta faz parte do campo kubectlRedirectURI do ficheiro de configuração de autenticação.

Na shell SSH, execute o seguinte comando para iniciar a autenticação:

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

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

No seu computador local, num navegador, aceda a http://localhost:LOCAL_PORT/login e siga o fluxo de início de sessão do OIDC.

O ficheiro kubeconfig no seu computador remoto tem agora o token para aceder ao cluster de utilizadores.

Na shell SSH, verifique se tem acesso ao cluster de utilizadores:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Consola

Pode autenticar-se com a Google Cloud consola, iniciar o fluxo de autenticação a partir da página Clusters do Kubernetes na Google Cloud consola:

Abra a Google Cloud consola:

Visite a página Clusters do Kubernetes
Localize o seu cluster do GKE na AWS na lista e, de seguida, clique em Iniciar sessão.
Selecione Autenticar com o fornecedor de identidade configurado para o cluster e, de seguida, clique em INICIAR SESSÃO.

É feito o redirecionamento para o seu fornecedor de identidade, onde pode ter de iniciar sessão ou dar o seu consentimento para que a Google Cloud consola aceda à sua conta. Em seguida, é feito o redirecionamento de volta para a página Clusters do Kubernetes na Google Cloud consola.

A atualizar 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 seu editor predefinido. Para atualizar a configuração, guarde o ficheiro. A ferramenta kubectl atualiza o recurso ClientConfig no seu cluster.

Para ver informações sobre o conteúdo do recurso ClientConfig, consulte a secção seguinte.

Apêndice: exemplo de configuração de início de sessão

Segue-se um exemplo kubectl-anthos-config.yaml. Este exemplo é incluído para compreender o respetivo conteúdo. Deve sempre gerar o ficheiro 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 dos campos, consulte os campos de autenticação.

O que se segue?

Implemente a sua primeira carga de trabalho no GKE na AWS.

Autenticação com o OpenID Connect (OIDC) Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Vista geral

Antes de começar

Personagens fictícias

Escolha um fornecedor OpenID

Crie URLs de redirecionamento

Defina o URL de redirecionamento da CLI gcloud

Defina o Google Cloud URL de redirecionamento da consola

Registe as suas aplicações cliente junto do fornecedor do OpenID

Configure o cluster

Campos de autenticação

Exemplo: autorizar utilizadores e grupos

Crie uma configuração de início de sessão

Distribua a configuração de início de sessão

Diretórios predefinidos de configuração de início de sessão

Modifique o cluster após a atualização para o Kubernetes 1.21

Edite o YAML

kubectl edit

Configurar o gcloud para aceder ao cluster

Pré-requisitos

Autentique o cluster

gcloud local

Predefinição

Parâmetros opcionais

gcloud tunnel

Consola

A atualizar configuração do OIDC

Apêndice: exemplo de configuração de início de sessão

O que se segue?

Autenticação com o OpenID Connect (OIDC)