Como autenticar com o serviço de identidade do GKE


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, veja se você realizou as seguintes tarefas:

Defina as configurações padrão da gcloud usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar a gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine para clusters zonais ou uma região para clusters regionais ou de Autopilot.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project PROJECT_ID
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone COMPUTE_ZONE
  • Se você estiver trabalhando com clusters de Autopilot ou regionais, defina a região do Compute padrão:
    gcloud config set compute/region COMPUTE_REGION
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Perfis

Este tópico se refere a dois perfis:

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

Como ativar o serviço de identidade para o GKE em um novo cluster

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

Por padrão, o gerenciamento de identidade e acesso é configurado como o provedor de identidade para a autenticação do cluster. Se você quiser usar o OIDC com provedores de identidade de terceiros, ative o Serviço de identidade para o GKE durante a criação do cluster com a ferramenta de linha de comando gcloud.

Para criar um cluster com o Identity Service para GKE ativado usando a ferramenta gcloud, execute o seguinte comando:

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

Substitua CLUSTER_NAME pelo nome do novo bucket.

Como ativar o serviço de identidade para o GKE em um cluster

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

Ative o Serviço de identidade para o GKE em um cluster atual usando a ferramenta de linha de comando gcloud.

Ao atualizar o cluster, especifique a opção --enable-identity-service:

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

Substitua CLUSTER_NAME pelo nome do cluster.

Como configurar o serviço de identidade para o GKE em um cluster

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

A configuração do provedor de identidade do GKE é tratada com a definição de recurso personalizada (CRD, na sigla em inglês) do Kubernetes, que contém informações como a configuração do provedor de identidade, o método de autenticação preferencial e o mapeamento de declarações de usuário e grupo.

Um arquivo de configuração ClientConfig chamado default é gerado automaticamente para o cluster no namespace kube-public.

  1. Faça o download do arquivo de configuração executando o seguinte comando:

    kubectl get clientconfig default -n kube-public -o yaml > login-config.yaml
    
  2. Atualize o arquivo de configuração ClientConfig salvo com as configurações do OIDC na seção Spec.authentication.

    apiVersion: authentication.gke.io/v2alpha1
    kind: ClientConfig
    metadata:
    annotations:
      controller-gen.kubebuilder.io/version: v0.2.4
    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: CLOUD_CONSOLE_REDIRECT_URI
         kubectlRedirectURI: KUBECTL_REDIRECT_URL
         Scopes: SCOPES
         userClaim: USER
         groupsClaim: GROUPS
         userPrefix: USER_PREFIX
         groupPrefix: GROUP_PREFIX
    

    Substitua:

    • CLIENT_ID: o ID do aplicativo cliente que faz solicitações de autenticação para o provedor OpenID.
    • OIDC_PROVIDER_CERTIFICATE: (opcional) um base64 certificado codificado em PEM codificado para o provedor OIDC. Esse campo pode ser útil caso seu provedor OIDC use certificados autoassinados. Por padrão, o Identity Service para GKE inclui um conjunto de raízes públicas.
      • Para criar a string, codifique o certificado, incluindo cabeçalhos, em base64.
      • Inclua a string resultante em certificateAuthorityData como uma única linha. Exemplo: certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==
    • EXTRA_PARAMS: parâmetros de chave-valor extras a serem enviados ao provedor OpenID. Se você estiver autorizando um grupo, transmita resource=token-groups-claim. Se o servidor de autorização solicitar consentimento, para autenticação com o Microsoft Azure e o Okta, defina extraParams como prompt=consent. Para o Cloud Identity, defina extraParams como prompt=consent,access_type=offline.
    • ISSUER_URI: o URL ao qual são enviadas solicitações de autorização para seu OpenID, 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.
    • CLOUD_CONSOLE_REDIRECT_URI: o URL de redirecionamento do Console do Cloud, por exemplo, https://console.cloud.google.com/kubernetes/oidc.
    • KUBECTL_REDIRECT_URL: o URL de redirecionamento que "kubectl" usa para autorização.
    • SCOPES: outros escopos a serem enviados ao provedor OpenID. O Microsoft Azure e o Okta exigem o escopo offline_access.
    • 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. Por exemplo, https://example.com/adfs#123123123, em que https://example.com/adfs é o ISSUER_URI, e 123123123 é a declaração do usuário do JWT. O Google recomenda o uso de um prefixo. No entanto, se você quiser desativar o prefixo, defina USER_PREFIX como -.
    • GROUP_PREFIX: prefixo anexado a declarações de grupos para evitar conflitos com nomes. Por exemplo, se você tiver dois grupos chamados foobar, adicione um prefixo gid-. O grupo resultante é gid-foobar.
  3. Depois de concluir a configuração, execute o seguinte comando para aplicar a configuração:

    kubectl apply -f login-config.yaml
    

    Depois que você aplicar essa configuração, o Identity Service for GKE será executado no cluster e atenderá às solicitações por trás de um balanceador de carga do Google Cloud. Se o cluster estiver configurado com um endpoint particular, o balanceador de carga será interno. Caso contrário, o balanceador de carga será externo e acessível pela Internet pública.

  4. 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 cliente e o provedor OIDC. Para evitar o upload da chave secreta do cliente para o kube-apiserver, não execute o comando kubectl apply novamente para aplicar a configuração.

  5. Distribua o arquivo login-config.yaml atualizado para os desenvolvedores e instrua-os a colocar o arquivo de configuração no local apropriado para a plataforma deles.

Como criar 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, suponha que você queira que um usuário visualize todos os objetos secret por todo o cluster.

Veja um manifesto para um ClusterRole chamado secret-viewer. 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"]

Veja um manifesto para um ClusterRoleBinding chamado people-who-view-secrets. 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
  1. Substitua ISSUER_URI pelo URI do emissor de spec.authentication.oidc.issuerURI no arquivo de configuração do cliente. Substitua USER pelo 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. Por exemplo, https://example.com/adfs#123123123, em que https://example.com/adfs é o ISSUER_URI e 123123123 é o identificador do usuário.

  2. Para criar o ClusterRole, salve o manifesto em um arquivo chamado secret-viewer-cluster-role.yaml e execute o seguinte comando:

    kubectl apply -f secret-viewer-cluster-role.yaml
    
  3. Para criar o ClusterRoleBinding, salve o manifesto em um arquivo chamado secret-viewer-cluster-role-binding.yaml e execute o seguinte comando:

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

Como fazer login e autenticação no cluster

Esta seção é destinada a desenvolvedores.

Agora que você tem o arquivo de configuração de autenticação do administrador, faça a autenticação nos clusters.

  1. Faça o download do arquivo login-config.yaml fornecido pelo administrador e coloque-o no local correto da sua plataforma.

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

    gcloud components install kubectl-oidc
    
  3. Faça a autenticação no cluster executando o seguinte comando:

    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 do kubectl, por exemplo:

    kubectl get pods
    

Como desativar o serviço de identidade para o GKE

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

É possível desativar o Identity Service para GKE com a ferramenta de linha de comando gcloud. Para desativar o serviço de identidade para o GKE, especifique a opção --no-enable-identity-service:

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

A seguir