Como ativar o IAP para o GKE

Nesta página, você aprenderá como proteger uma instância do Google Kubernetes Engine (GKE) com o Identity-Aware Proxy (IAP).

Visão geral

O IAP integra-se ao GKE por meio do objeto Ingress. É essa integração que permite controlar o acesso de funcionários no nível do recurso, em vez de usar uma VPN.

Em um cluster do GKE, o tráfego de entrada é processado pelo balanceamento de carga HTTP(S), um componente do Cloud Load Balancing. Normalmente, o balanceador de carga HTTP(S) é configurado pelo controlador Ingress do Kubernetes (em inglês). Esse controlador recebe as informações de configuração de um objeto Ingress do Kubernetes associado a um ou mais objetos Service. Cada objeto Service contém informações de roteamento que são usadas para direcionar uma solicitação de entrada para um determinado pod e porta.

A partir do Kubernetes versão 1.10.5-gke.3, adicione configurações do balanceador de carga associando um serviço a um objeto BackendConfig. BackendConfig é uma definição de recurso personalizado (CRD, na sigla em inglês) que é definida no repositório kubernetes/ingress-gce (ambos os links em inglês).

O controlador do Kubernetes Ingress lê as informações de configuração do BackendConfig e configura o balanceador de carga de acordo. Um BackendConfig contém informações de configuração específicas do Cloud Load Balancing e permite que você defina uma configuração separada para cada serviço de back-end de balanceamento de carga HTTP(S).

Antes de começar

Para ativar o IAP para o GKE, você precisará destes elementos:

• Um projeto do console do Google Cloud com o faturamento ativado.
• Um grupo com uma ou mais instâncias do GKE, exibido por um balanceador de carga HTTPS. O balanceador de carga precisa ser criado automaticamente quando você cria um objeto de entrada em um cluster do GKE.
  • Saiba mais sobre como criar uma entrada para HTTPS.
• Um nome de domínio registrado no endereço do seu balanceador de carga.
• O código do app para verificar se todas as solicitações têm uma identidade.
  • Saiba mais sobre como conseguir a identidade do usuário.

Como ativar o IAP

Se você não tiver configurado a tela de permissão OAuth do seu projeto, solicitado a fazer isso. Para configurar a tela de permissão OAuth, consulte Como configurar a tela de permissão OAuth.

Como configurar o acesso do IAP

1. Acesse a página Identity-Aware Proxy.
   Acessar a página "Identity-Aware Proxy"
2. Selecione o projeto que você quer proteger com o IAP.

3. Marque a caixa de seleção ao lado do recurso ao qual você quer conceder acesso.

   Se você não encontrar um recurso, verifique se ele foi criado e se o controlador de entrada do Compute Engine BackendConfig foi sincronizado.

   Para verificar se o serviço de back-end está disponível, execute o seguinte Comando gcloud:

   gcloud compute backend-services list
4. No painel à direita, clique em Adicionar principal.
5. Na caixa de diálogo Adicionar participantes, insira os endereços de e-mail dos grupos ou pessoas que precisam ter o papel Usuário do app da Web protegido pelo IAP no projeto.

   Os seguintes tipos de administradores podem ter esse papel:

   • Conta do Google: [e-mail]
   • grupo do Google: [e-mail]
   • Conta de serviço: [e-mail]
   • Domínio do Google Workspace: example.com

   Inclua uma Conta do Google a que você tenha acesso.

6. Selecione Cloud IAP > Usuário do app da Web protegido pelo IAP na lista suspensa Papéis.
7. Clique em Salvar.

Como configurar o BackendConfig

Para configurar o BackendConfig para o IAP, crie um objeto Secret do Kubernetes e inclua um bloco iap em BackendConfig.

Como criar um objeto Secret do Kubernetes

O BackendConfig usa uma chave secreta do Kubernetes para incorporar o cliente OAuth criado anteriormente. Secrets são gerenciados como outros objetos do Kubernetes, usando a interface de linha de comando (CLI, na sigla em inglês) kubectl (em inglês). Para criar um secret, execute o seguinte comando, em que client_id_key e client_secret_key são as chaves do arquivo JSON que você fez o download quando criou as credenciais do OAuth:

kubectl create secret generic my-secret --from-literal=client_id=client_id_key \
    --from-literal=client_secret=client_secret_key

O comando acima exibe a seguinte resposta para confirmar que o Secret foi criado com sucesso:

secret "my-secret" created

Como incluir um bloco iap em BackendConfig

Para configurar o BackendConfig para o IAP, especifique os valores de enabled e secretName. Para especificar esses valores, é necessário que você tenha a permissão compute.backendServices.update e inclua o bloco iap no BackendConfig. Nesse bloco, my-secret é o nome do secret do Kubernetes que você criou anteriormente:

Observação: não é possível ativar o IAP e o Cloud CDN em um BackendConfig. Se o BackendConfig não tiver um bloco de IAP, todas as atuais configurações do IAP no serviço de back-end serão herdadas.

Para as versões 1.16.8-gke.3 e mais recentes do GKE, use a versão da API "cloud.google.com/v1". Se você estiver usando uma versão anterior do GKE, use "cloud.google.com/v1beta1".

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: config-default
  namespace: my-namespace
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

Você também precisa associar as portas de serviço ao BackendConfig para acionar a ativação do IAP. Uma forma de fazer isso é tornar todas as portas de serviço como padrão para seu BackendConfig. Para isso, inclua a anotação a seguir no recurso Service:

metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "config-default"}'

Para testar a configuração, execute kubectl get event. Se aparecer a mensagem "no BackendConfig for service port exists", significará que a porta de serviço foi associada ao seu BackendConfig, mas o recurso BackendConfig não foi encontrado. Esse erro poderá ocorrer se o recurso BackendConfig ainda não tiver sido criado, se ele tiver sido criado no namespace errado ou se a referência na anotação do Service tiver sido digitada com incorretamente.

Observação: o IAP adiciona o parâmetro de consulta gcp-iap-mode=AUTHENTICATING à solicitação redirecionada que ocorre após a autenticação OAuth. Verifique a configuração de roteamento do balanceador de carga de entrada para garantir que as solicitações redirecionadas sejam enviadas ao serviço de back-end correto depois que um usuário for autenticado pelo OAuth.

Se o secretName referenciado não existir ou não estiver estruturado corretamente, uma das mensagens de erro a seguir será exibida:

• BackendConfig default/config-default is not valid: error retrieving secret "foo": secrets "foo" not found. Para solucionar este erro, verifique se você criou o objeto Secret do Kubernetes corretamente, conforme descrito na seção anterior.
• BackendConfig default/config-default is not valid: secret "foo" missing client_secret data. Para resolver esse erro, verifique se você criou as credenciais OAuth corretamente. Além disso, verifique se você referenciou corretamente as chaves client_id e client_secret no JSON que fez o download anteriormente.

Quando a sinalização enabled estiver definida como true e o valor de secretName estiver correto, o IAP será configurado para o recurso selecionado.

Observação:talvez você receba uma mensagem de aviso "Adicionar regra de firewall" no IAP página de configuração para back-ends baseados em grupo de endpoints de rede (NEG), mesmo que exista a regra de firewall correta. O alerta da regra de firewall é informativo e pode ser ignorado com segurança.

Como desativar o IAP

Para desativar o IAP, defina enabled como false no BackendConfig. Se você excluir o bloco do IAP do BackendConfig, as configurações serão mantidas. Por exemplo, se o IAP estiver ativado com secretName: my_secret e você excluir o bloco, o IAP ainda assim será ativado com as credenciais do OAuth armazenadas em my_secret.

A seguir

• Saiba como configurar o Cloud CDN no GKE.
• Saiba como configurar o Cloud Armor para GKE.
• Saiba mais sobre o recurso BackendConfig.