Como proteger aplicativos e recursos do GKE com o IAP

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

Para proteger recursos que não estão no Google Cloud, consulte Como proteger aplicativos e recursos locais.

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 um Ingress para HTTPS. OBSERVAÇÃO: a entrada interna requer uma assinatura do BeyondCorp Enterprise.
• Um nome de domínio registrado no endereço do 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

Como configurar a tela de consentimento do OAuth

Se você não tiver configurado a tela de permissão OAuth do seu projeto, precisará fazer isso. É necessário um endereço de e-mail e um nome de produto para a tela de permissão OAuth.

Cuidado:não insira informações confidenciais na tela de consentimento do OAuth. Qualquer informação que você salvar nessa tela poderá ficar visível publicamente para quem acessa seu URL. Os detalhes do produto e do e-mail são exibidos na tela de login e quando alguém tenta acessar um recurso sem ter permissão para isso.

1. Acesse a tela de consentimento OAuth.
   Configurar tela de consentimento
2. Em E-mail de suporte, selecione o endereço de e-mail que você quer exibir como um contato público. O endereço de e-mail precisa pertencer à conta de usuário conectada no momento ou a um grupo do Google a que o usuário pertence no momento.
3. Digite o Nome do aplicativo que você quer exibir.
4. Adicione os detalhes opcionais que você quiser.
5. Clique em Salvar.

Para alterar as informações na tela de consentimento do OAuth posteriormente, como o nome do produto ou o endereço de e-mail, repita as etapas anteriores.

Criar credenciais do OAuth

1. Acesse a página Credenciais.
   Acessar a página "Credenciais"
2. No menu suspenso Criar credenciais, selecione o ID do cliente OAuth.
3. Em Tipo de aplicativo, selecione Aplicativo da Web.
4. Adicione um Nome para seu ID do cliente OAuth.
5. Clique em Criar.

   O ID e a chave secreta do cliente OAuth são gerados e exibidos na janela Cliente OAuth.

6. Na caixa de diálogo Oauth client created, copie o ID do cliente para a área de transferência.
7. Clique em OK.
8. Clique no nome do cliente recém-criado para reabri-lo para edição.
9. No campo URIs de redirecionamento autorizados, insira a seguinte string:

   https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect

   em que CLIENT_ID é o ID do cliente OAuth que você acabou de copiar para a área de transferência.

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 a que você quer conceder acesso.
4. No painel lateral à direita, clique em Adicionar principal.
5. Na caixa de diálogo Adicionar participantes que é exibida, insira os endereços de e-mail de grupos ou indivíduos que terão o papel Usuário do app da Web protegido pelo IAP no projeto.

   Os seguintes tipos de principais podem ter este 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 Save.

Como configurar o BackendConfig

Para configurar o BackendConfig para IAP, crie um secret do Kubernetes e adicione um bloco iap ao 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 posteriores 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. Portanto, verifique a configuração de roteamento do balanceador de carga do seu ingresso para garantir que as solicitações redirecionadas sejam direcionadas ao serviço de back-end correto depois que um usuário for autenticado pelo OAuth.

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

• BackendConfig default/config-default is not valid: error retrieving secret "foo": secrets "foo" not found. Para resolver esse erro, verifique se você criou o secret do Kubernetes corretamente, conforme descrito na seção anterior.
• BackendConfig default/config-default is not valid: secret "foo" missing client_secret data. Para solucionar este erro, verifique se você criou as credenciais do 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 é definida como true e secretName é definido corretamente, o IAP é configurado para o recurso selecionado.

Observação: talvez você receba uma mensagem de aviso "Adicionar regra de firewall" na página de configuração do IAP para back-ends baseados em grupo de endpoints de rede (NEG, na sigla em inglês), mesmo que haja a regra de firewall correta. O aviso de 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.

Próximas etapas

• Defina regras de contexto mais avançadas aplicando níveis de acesso.
• Para as solicitações de acesso, ative os registros de auditoria do Cloud.
• Saiba mais sobre o IAP.
• Saiba como configurar o Cloud CDN no GKE.
• Saiba como configurar o Cloud Armor para GKE.
• Saiba mais sobre o recurso BackendConfig.