Autenticação com OpenID Connect (OIDC)

Aprenda a configurar o GKE na AWS para usar o OpenID Connect (OIDC) para autenticação em clusters de usuários. Este tópico aborda o processo de configuração do GKE na AWS com qualquer provedor OpenID.

Para atualizar um cluster que usa autenticação OIDC para o Kubernetes 1.21, consulte Atualizar para 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 oferece suporte ao OIDC como um dos mecanismos de autenticação para interação com o servidor da API do Kubernetes de um cluster de usuários. Com o OIDC, você pode gerenciar o acesso aos clusters do Kubernetes usando os procedimentos padrão da sua organização para criar, habilitar e desabilitar contas de usuário.

Antes de começar

• Este tópico pressupõe que você esteja familiarizado com os seguintes conceitos de autenticação e OpenID:

  • OAuth 2.0
  • Conexão OpenID
  • escopos
  • reivindicações

• O Google Cloud CLI deve ser instalado na máquina local de cada desenvolvedor.

• Sistemas headless não são suportados. Para autenticar, você precisa abrir um navegador na máquina local que executa a CLI do gcloud. O navegador então solicitará que você autorize sua conta de usuário.

• Para autenticar através do Google Cloud console, cada cluster que você deseja configurar para autenticação OIDC deve ser registrado com Google Cloud .

Personas

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

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

• Administrador de cluster : essa pessoa cria um ou mais clusters de usuários 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 autenticação.

Escolha um provedor OpenID

Esta seção é para administradores de organizações .

Você pode usar qualquer provedor OpenID de sua escolha. Para obter uma lista de provedores certificados, consulte Certificação OpenID .

Criar URLs de redirecionamento

Esta seção é para administradores de organizações .

O provedor OpenID usa URLs de redirecionamento para retornar tokens de ID. Você deve criar URLs de redirecionamento para a CLI do gcloud e para oGoogle Cloud console.

Definir a URL de redirecionamento da CLI do gcloud

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

Substitua PORT pelo seu número de porta maior que 1024.

Defina o Google Cloud URL de redirecionamento do console

O URL de redirecionamento para o Google Cloud console é:

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

Ao configurar seu provedor OIDC, especifique https://console.cloud.google.com/kubernetes/oidc como uma das suas URLs de redirecionamento.

Registre seus aplicativos de cliente com o provedor OpenID

Esta seção é para administradores de organizações .

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

• Aprenda o URI do emissor do seu provedor. O CLI do gcloud ouGoogle Cloud o console envia solicitações de autenticação para este URI.

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

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

• Crie um único ID de cliente que seu provedor usa para identificar o Google Cloud CLI e oGoogle Cloud console.

• Crie um segredo de cliente único que o CLI do gcloud e o Google Cloud console usado para autenticar o provedor OpenID.

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

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

Configure seu cluster

Esta seção é para administradores de cluster .

Para configurar a autenticação OIDC, você precisa configurar o recurso AWSCluster do seu cluster de usuários com detalhes de autenticação para um cluster. Os detalhes do AWSCluster são usados ​​para configurar o OIDC para ambos Google Cloud console e o 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: Autorizando usuários e grupos

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

• IDs de usuário podem dificultar a leitura e a auditoria de políticas.
• O uso de endereços de e-mail pode criar um risco de disponibilidade (se um usuário alterar seu e-mail principal) e um risco de segurança (se um e-mail puder ser reatribuído).

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 seu arquivo de configuração assim:

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

Depois de criar seu cluster de usuários, use o controle de acesso baseado em função (RBAC) do Kubernetes para conceder acesso privilegiado aos usuários autenticados.

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

1. Defina um ClusterRole . Copie o seguinte YAML em 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 em 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
   

   Usuários com acesso concedido em read-secrets-admins agora têm acesso para ler segredos no seu cluster.

Crie uma configuração de login

Esta seção é para 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 seu diretório anthos-aws , use anthos-gke para alternar o contexto para seu cluster de usuários.

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

   Substitua CLUSTER_NAME pelo nome do seu cluster de usuário.

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 seu cluster de usuários. No Linux e no macOS, por padrão, este arquivo está em ~/.kube/config .

Este comando gera um arquivo ( kubectl-anthos-config.yaml ) contendo as informações de configuração que seus desenvolvedores usam para autenticar no cluster com a CLI do gcloud. Você não deve modificar este 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 aos usuários que precisam se autenticar nos seus clusters de usuários. Você pode distribuir a configuração das seguintes maneiras:

• Colocando o arquivo no diretório padrão.
• Distribuindo o arquivo com segurança.
• Hospedar 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 sistema operacional são os seguintes:

Linux

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

macOS

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

Windows

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

Após a configuração de login ser distribuída, seus desenvolvedores estarão prontos para configurar o gcloud CLI para acessar o cluster.

Modifique seu cluster após atualizar para o Kubernetes 1.21

Após atualizar seu cluster para o Kubernetes 1.21, você precisará configurar o Serviço de Identidade do GKE e remover as informações do OIDC da configuração do cluster. Para atualizar a configuração, siga estas etapas:

1. Siga as etapas em Atualizar seu cluster .

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

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

   Substitua CLUSTER_NAME pelo nome do seu cluster de usuário.

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 Configurando clusters para o Serviço de Identidade do GKE .

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

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

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

   Editar YAML

   Se você seguiu as instruções em Criando um cluster de usuários , seu arquivo YAML será chamado cluster-0.yaml . Abra este arquivo em um editor de texto.

   kubectl editar

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

7. Salve o arquivo. Se você estiver usando kubectl edit , kubectl aplicará as alterações automaticamente. Se estiver editando o arquivo YAML, aplique-o ao seu 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 então atualiza seu AWSCluster.

Configurando o gcloud para acessar seu cluster

Esta seção é para desenvolvedores ou administradores de cluster .

Pré-requisitos

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

• Uma configuração de login .

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

  gcloud components update
  gcloud components install anthos-auth
  

• Verifique se o gcloud CLI foi instalado com sucesso executando o seguinte comando, que deve responder com detalhes sobre os argumentos necessários e as opções disponíveis.

  gcloud anthos auth
  

Autenticar no seu cluster

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

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

• Com Connect no Google Cloud console.

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

Atualizando a configuração do OIDC

Para atualizar a configuração do OIDC no seu 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 padrão. Para atualizar a configuração, salve o arquivo. A ferramenta kubectl atualiza o recurso ClientConfig no seu cluster.

Para obter 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 de kubectl-anthos-config.yaml . Este exemplo está incluído para facilitar a compreensão do seu conteúdo. Você deve 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 explicações sobre o conteúdo dos campos, consulte Campos de autenticação .

O que vem a seguir

Implante sua primeira carga de trabalho no GKE na AWS.