Usar provedores de identidade externos para autenticar no GKE


Neste documento, 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

  • Antes de ler este documento, você precisa conhecer 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, veja se você realizou as seguintes tarefas:

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

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