Usar provedores de identidade externos para autenticar no GKE

Padrão

---

Nesta página, você verá como configurar um provedor de identidade externo para se autenticar nos clusters do Google Kubernetes Engine (GKE).

Visão geral

O serviço de identidade do GKE estende as soluções de identidade para autenticação nos clusters do GKE. Com suporte para OpenID Connect (OIDC), é possível gerenciar o acesso aos clusters do Kubernetes usando os procedimentos padrão na sua organização para criar, ativar e desativar contas de usuários. O serviço de identidade para o GKE é limitado a provedores de identidade OIDC.

Antes de começar

• Este tópico pressupõe que você já conhece os seguintes conceitos de autenticação e OpenID:

  • OAuth 2.0
  • OpenID Connect
  • Escopos
  • declarações.

• Sistemas headless não são compatíveis. Um fluxo de autenticação baseado em navegador é usado para solicitar consentimento e autorizar a conta de usuário.

Antes de começar, verifique se você realizou as tarefas a seguir:

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
  Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Definindo os locais padrão, você evita erros como este na CLI gcloud: One of [--zone, --region] must be supplied: Please specify location.

Quem usa o serviço de identidade para o GKE

As tarefas neste documento se aplicam a você se for:

• Administrador de cluster: cria um ou mais clusters de usuário e cria arquivos de configuração de autenticação para desenvolvedores que usam os clusters.

• Desenvolvedor: executa cargas de trabalho em um ou mais clusters e usa o OIDC para fazer a autenticação.

Como funciona

Para configurar e usar o serviço de identidade para o GKE no cluster do GKE, os administradores do cluster precisam:

1. Habilitar o serviço de identidade para o GKE em um cluster.
2. Configurar o serviço de identidade para o GKE.
3. Criar uma política de RBAC para o cluster.

Depois que os administradores do cluster configurarem o serviço de identidade para o GKE, os desenvolvedores poderão fazer login e autenticar no cluster.

Habilitar o serviço de identidade para o GKE em um cluster

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

Por padrão, o gerenciamento de identidade e acesso (IAM, na sigla em inglês) é configurado como o provedor de identidade para a autenticação do cluster. Se você quiser usar o OIDC com provedores de identidade de terceiros, habilite o serviço de identidade para o GKE em clusters novos ou atuais usando a Google Cloud CLI.

Observação:Para que o serviço de identidade do GKE funcione corretamente, o GKE implementa pods nos nós com Permissões do RBAC elevadas, como a capacidade de representar usuários e grupos. Essas permissões são necessárias para que o Identity Service para GKE facilite a validação e a comunicação de identidade com base na sua configuração.

Habilitar o serviço de identidade para o GKE em um novo cluster

Para criar um cluster com o serviço de identidade para o GKE habilitado, execute este comando:

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

Substitua CLUSTER_NAME pelo nome do novo bucket.

Habilitar o serviço de identidade para o GKE em um cluster atual

Para habilitar o serviço de identidade para o GKE em um cluster atual, execute este comando

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

Substitua CLUSTER_NAME pelo nome do cluster.

Objetos do Kubernetes criados pelo serviço de identidade para GKE

Na tabela a seguir, descrevemos os objetos do Kubernetes criados quando você habilita o serviço de identidade para o GKE em um cluster:

Objetos do Kubernetes
anthos-identity-service	Namespace Usado no serviço de identidade para implantações do GKE.
kube-public	Namespace Usado para o default arquivo de configuração do cliente.
gke-oidc-envoy	LoadBalancer O endpoint para solicitações de OIDC. Externo por padrão. Se criado em um cluster particular ou com uma política de rede rígida, o endpoint será interno à nuvem privada virtual do cluster. Criado no namespace anthos-identity-service.
gke-oidc-service	ClusterIP Facilita a comunicação entre a implantação gke-oidc-envoy e a implantação gke-oidc-service. Criado no namespace anthos-identity-service.
gke-oidc-envoy	Deployment Executa um proxy exposto ao gke-oidc-envoyLoadBalancer. Se comunica com gke-oidc-service para validar tokens de identidade. Atua como um proxy para o servidor da API Kubernetes e representa os usuários ao transmitir solicitações para o servidor da API. Criado no anthos-identity-servicenamespace.
gke-oidc-service	Deployment Valida os tokens de identidade e fornece um webhook de admissão de validação para recursos ClientConfig. Criado no namespace anthos-identity-service.
gke-oidc-operator	Deployment Reconcilia a configuração do cliente e o LoadBalancer gke-oidc-envoy. Criado no namespace anthos-identity-service.
gke-oidc-certs	Secret Contém a autoridade certificadora (CA) do cluster e os certificados TLS do LoadBalancer. Criado no namespace anthos-identity-service
default	ClientConfig CRD Contém parâmetros do OIDC, como método de autenticação de preferência, configuração do provedor de identidade e mapeamentos de declarações de usuário e grupo. Usado para validação de token de identidade. Usado pelos administradores de cluster para definir as configurações do OIDC antes de distribuir para os desenvolvedores. Criado no namespace kube-public

Configurar o serviço de identidade para o GKE

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

É possível configurar os parâmetros do serviço de identidade para o GKE fazendo o download e modificando o ClientConfig default.

1. Faça o download do ClientConfig default:

   kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml
   

2. Atualize a seção spec.authentication com as configurações que preferir:

   apiVersion: authentication.gke.io/v2alpha1
   kind: ClientConfig
   metadata:
     name: default
     namespace: kube-public
   spec:
     name: cluster-name
     server: https://192.168.0.1:6443
     authentication:
     - name: oidc
       oidc:
         clientID: CLIENT_ID
         certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
         extraParams: EXTRA_PARAMS
         issuerURI:  ISSUER_URI
         cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
         kubectlRedirectURI: KUBECTL_REDIRECT_URL
         scopes: SCOPES
         userClaim: USER
         groupsClaim: GROUPS
         userPrefix: USER_PREFIX
         groupPrefix: GROUP_PREFIX
   

   Substitua:

   • CLIENT_ID: ID do aplicativo cliente que faz solicitações de autenticação para o provedor OIDC.
   • OIDC_PROVIDER_CERTIFICATE: (opcional) um certificado PEM para o provedor OIDC. Esse campo pode ser útil caso o provedor OIDC use certificados autoassinados. O serviço de identidade para GKE inclui um conjunto de raízes públicas por padrão.
   • EXTRA_PARAMS: parâmetros de chave-valor extras a serem enviados ao provedor OpenID.
     • Para autorizar grupos, use resource=token-groups-claim.
     • Para autenticar o Microsoft Azure e o Okta, use prompt=consent.
     • Para o Cloud Identity, use prompt=consent,access_type=offline.
   • ISSUER_URI: o URL para enviar solicitações de autorização do OIDC, como https://example.com/adfs. O servidor da API Kubernetes usa esse URL para descobrir chaves públicas de verificação de tokens. O URI precisa usar HTTPS. Para o Cloud Identity, use https://accounts.google.com.
   • KUBECTL_REDIRECT_URL: o URL de redirecionamento que kubectl oidc login usa para autorização. Normalmente, é no formato http://localhost:PORT/callback, em que PORT é qualquer porta acima de 1024 que estará disponível em estações de trabalho do desenvolvedor, por exemplo, http://localhost:10000/callback de dados. Registre o URL no seu provedor do OIDC como um URL de redirecionamento autorizado para o aplicativo do cliente. Se você usa o Google Identity como seu provedor do OIDC, leia Definir um URI de redirecionamento para instruções.
   • SCOPES: outros escopos a serem enviados ao provedor do OIDC.
     • O Microsoft Azure e o Okta exigem o offline_access escopo.
     • Para o Cloud Identity, use openid, email para conseguir os tokens de ID que contêm o endereço de e-mail na email declaração.
   • USER: a declaração do usuário do token de identidade.
   • GROUPS: a declaração do grupo do token de identidade.
   • USER_PREFIX: prefixo anexado a declarações de usuários para evitar conflitos com nomes atuais. Por padrão, um prefixo de emissor é anexado ao userID fornecido ao servidor da API Kubernetes (a menos que a declaração do usuário seja email). O identificador de usuário resultante é ISSUER_URI#USER. Recomendamos o uso de um prefixo, mas é possível desativá-lo definindo USER_PREFIX como -.
   • GROUP_PREFIX: prefixo anexado a declarações de grupos para evitar conflitos com nomes atuais. Por exemplo, se você tiver dois grupos chamados foobar, adicione um prefixo gid-. O grupo resultante é gid-foobar.

3. Aplique a configuração atualizada:

   kubectl apply -f client-config.yaml
   

   Depois de aplicar essa configuração, o serviço de identidade para o GKE será executado dentro do cluster e atenderá às solicitações por trás do balanceador de carga gke-oidc-envoy. O endereço IP no campo spec.server precisa ser o endereço IP do balanceador de carga. Se você alterar o campo spec.server, os comandos kubectl podem falhar.

4. Faça uma cópia do arquivo de configuração client-config.yaml:

   cp client-config.yaml login-config.yaml
   

5. Atualize o arquivo de configuração login-config.yaml novamente com a configuração clientSecret na seção spec.authentication.oidc.

   clientSecret: CLIENT_SECRET
   

   Substitua CLIENT_SECRET pela chave secreta compartilhada entre o aplicativo do cliente e o provedor do OIDC.

6. Distribua o arquivo login-config.yaml atualizado para seus desenvolvedores.

Configurar o serviço de identidade para o GKE em clusters com políticas rígidas

Para configurar o serviço de identidade para o GKE para que funcione conforme o esperado em clusters com políticas de rede rígidas em vigor, como clusters particulares, faça o seguinte:

1. Adicione uma regra de firewall para a porta TCP 15000 para permitir que o plano de controle se comunique com o ClientConfig webhook de validação.
2. Se o gke-oidc-envoy for criado como um balanceador de carga interno, exponha-o na VPC.
3. Se você tiver políticas que neguem o tráfego no cluster, adicione uma regra de firewall para a porta TCP 8443 para permitir que a implantação gke-oidc-envoy se comunique com a implantação gke-oidc-service.

O Identity Service para GKE versão 0.2.20 e posterior não usa a porta TCP 15000. Se a versão do componente for 0.2.20 ou posterior, não será necessário adicionar uma regra de firewall para a porta 15000. Para verificar a versão do componente, execute o seguinte comando:

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

Adicionar propriedades personalizadas ao balanceador de carga

Depois de configurar o serviço de identidade para o GKE, é possível adicionar anotações e propriedades personalizadas, como um endereço IP estático, ao balanceador de carga gke-oidc-envoy. Para criar o serviço gke-oidc-envoy, execute este comando:

kubectl edit service gke-oidc-envoy -n anthos-identity-service

Consulte a documentação sobre como configurar o balanceamento de carga TCP/UDP para o GKE.

Crie uma política de RBAC para o cluster

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

Os administradores podem usar o controle de acesso baseado em papéis (RBAC) do Kubernetes para conceder acesso a usuários de cluster autenticados. Para configurar o RBAC no cluster, os administradores precisam conceder papéis do RBAC para cada desenvolvedor. Para conceder acesso a recursos em um namespace específico, crie um Papel e um RoleBinding . Para conceder acesso a recursos em um cluster inteiro, crie um ClusterRole e um ClusterRoleBinding.

Por exemplo, considere um usuário que precisa visualizar todos os objetos de secret no cluster. As etapas a seguir concedem os papéis do RBAC necessários a esse usuário.

1. Salve o seguinte manifesto ClusterRole como secret-viewer-cluster-role.yaml. Uma pessoa que tem esse papel pode receber, observar e listar qualquer secret no cluster.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-viewer
   rules:
   - apiGroups: [""]
     # The resource type for which access is granted
     resources: ["secrets"]
     # The permissions granted by the ClusterRole
     verbs: ["get", "watch", "list"]
   

2. Aplique o manifesto ClusterRole:

   kubectl apply -f secret-viewer-cluster-role.yaml
   

3. Salve o manifesto ClusterRoleBinding a seguir como secret-viewer-cluster-role-binding.yaml. A vinculação concede o papel secret-viewer a um nome de usuário definido no arquivo de configuração do cliente.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  people-who-view-secrets
   subjects:
   - kind: User
     name: ISSUER_URI#USER
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

   Substitua:

   • ISSUER_URI: o URI do emissor de spec.authentication.oidc.issuerURI no arquivo de configuração do cliente.
   • USER: o identificador do usuário no token com o nome da declaração configurado em spec.authentication.oidc.userClaim no arquivo de configuração do cliente.

4. Aplique o manifesto ClusterRoleBinding:

   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

Fazer login e autenticar no cluster

Esta seção é destinada aos desenvolvedores.

Ao receber o arquivo de configuração do OIDC do administrador, é possível fazer a autenticação nos clusters.

1. Faça o download do arquivo login-config.yaml fornecido pelo administrador.

2. Instale o SDK da Google Cloud CLI, que oferece um componente OIDC separado. Para isso, execute o seguinte comando:

   gcloud components install kubectl-oidc
   

3. Autentique-se no cluster:

   kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml
   

   Um navegador da Web é aberto para concluir o processo de autenticação.

4. Após a autenticação, será possível executar comandos kubectl, por exemplo:

   kubectl get pods
   

Desativar o serviço de identidade para o GKE

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

É possível desativar o serviço de identidade para o GKE com a gcloud CLI. Para desativar o serviço de identidade para o GKE, execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

A seguir

• Saiba mais sobre Como implantar cargas de trabalho.
• Saiba mais sobre o OpenID Connect (em inglês).
• Saiba mais sobre escopos e declarações.