Usar provedores de identidade externos para autenticar no GKE

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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:

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

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.

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