Modelo de blueprint do Anthos: como aplicar restrições de localidade para clusters no Google Cloud

Neste documento, descrevemos como gerenciar recursos para que eles estejam disponíveis apenas em regiões específicas. Ele inclui uma visão geral de como e por que você precisa atender às restrições de local e descrição dos controles do Google Cloud usados para essa tarefa.

O documento faz parte de uma série de projetos de segurança que fornecem orientações sobre como trabalhar com o Anthos.

Introdução

Muitas empresas precisam atender aos requisitos de residência específicos do local. Ou seja, elas exigem que os serviços (e, em muitos casos, os clusters em que os serviços estão sendo executados) sejam implantados ou possam ser acessados apenas de locais específicos. Pode haver vários motivos: requisitos regulatórios, de latência ou comerciais para oferecer o serviço apenas em países específicos.

Para atender aos requisitos de residência específicos do local, considere o seguinte:

  • Onde os serviços precisam estar localizados
  • Se você precisa restringir o acesso aos seus serviços de regiões específicas
  • De quais serviços do Google Cloud seus serviços dependem
  • Se você usa o GKE no Google Cloud ou o GKE On-Prem
  • Quais são os fluxos e operações permitidos dentro, para e do aplicativo

Ao entender esses problemas, é possível determinar como configurar cada um dos controles de segurança aplicáveis para atender aos requisitos de residência específicos do local.

Noções básicas dos controles de segurança necessários

Nesta seção, discutiremos os controles que podem ser usados para ajudar a atingir o nível de restrição de localidade que atende aos seus requisitos.

Namespaces

Como rotular recursos que precisam usar as mesmas políticas

Os namespaces permitem fornecer um escopo para recursos relacionados em um cluster, por exemplo, pods, serviços e controladores de replicação. Ao usar namespaces, é possível delegar a responsabilidade de administração dos recursos relacionados como uma unidade. Portanto, os namespaces são essenciais para a maioria dos padrões de segurança.

Os namespaces são um recurso importante para o isolamento do plano de controle. No entanto, eles não fornecem isolamento de nós, de plano de dados ou de rede.

Uma abordagem comum é criar namespaces para aplicativos individuais. Por exemplo, é possível criar o namespace myapp-frontend para o componente de IU de um aplicativo.

Políticas da organização

Como restringir os locais em que é possível implantar os clusters

O serviço de política da organização é usado para configurar restrições em recursos compatíveis na sua organização do Google. As restrições são configuradas em relação aos recursos compatíveis.

Ao restringir serviços a uma localidade, você usa a restrição de local de recursos. Essa restrição define o conjunto de locais em que os recursos do Google Cloud baseados em local podem ser criados. As políticas dessa restrição podem especificar diferentes locais permitidos ou negados. Por exemplo, as políticas podem especificar várias regiões, como Ásia e Europa, regiões como us-east1 ou europe-west1 ou zonas individuais, como europe-west1-b. Cada local a ser permitido ou negado precisa estar listado explicitamente.

Anthos Config Management

Como aplicar configurações aos clusters do Anthos

Uma prática recomendada ao gerenciar clusters do Anthos é usar o Anthos Config Management, que mantém os clusters inscritos sincronizados com os configs. Um config é um arquivo YAML ou JSON armazenado no seu repositório, e que contém os mesmos tipos de detalhes de configuração que podem ser aplicados manualmente a um cluster usando o comando kubectl apply. O Anthos Config Management permite que você gerencie suas políticas e implantações de infraestrutura como faz com seus aplicativos, adotando uma abordagem de política como código.

Use o Anthos Config Management com um repositório Git que atua como a única fonte confiável para as políticas declaradas. O Anthos Config Management pode gerenciar políticas de controle de acesso, como RBAC, cotas de recursos, namespaces e implantações de infraestrutura no nível da plataforma. O Anthos Config Management é declarativo. Ele verifica continuamente o estado do cluster e aplica o estado declarado na configuração para aplicar políticas.

Redes autorizadas para acesso ao cluster mestre

Como restringir os locais que podem acessar o servidor da API Kubernetes

Com as redes autorizadas, é possível permitir (colocar na lista de permissões) intervalos CIDR específicos e permitir que endereços IP nesses intervalos acessem o endpoint mestre do cluster usando HTTPS. Os clusters particulares não expõem endereços IP externos e, opcionalmente, executam o mestre do cluster sem um endpoint acessível publicamente.

Uma prática recomendada é seguir as orientações no guia de proteção do GKE que recomenda o uso de clusters particulares em combinação com a ativação de redes autorizadas.

Como selecionar um tipo de cluster

Para entender qual tipo de cluster é apropriado para seu caso de uso, você precisa entender regiões e zonas, e os locais em que os recursos podem ser implantados. Regiões são áreas geográficas independentes que consistem em zonas. Por exemplo, Londres (europe-west2) é uma região dentro da Europa, e Oregon (us-west1) é uma região dentro das Américas.

Uma zona é uma área de implantação de recursos do Google Cloud em uma região. As zonas podem ser consideradas um domínio de falha único dentro de uma região. Para implantar aplicativos tolerantes a falhas com alta disponibilidade, implante seus aplicativos em várias zonas em uma região.

Locais dentro de regiões tendem a ter latências de rede de ida e volta de menos de um milésimo de segundo no 95º percentil. Um exemplo de local é Tóquio, Japão, que tem três zonas e está na região asia-northeast1.

O GKE tem três tipos de clusters:

  • Cluster de zona única. Um cluster de zona única tem um único plano de controle (mestre) em execução em uma zona. Este plano de controle gerencia cargas de trabalho em nós em execução na mesma zona.
  • Cluster de várias zonas. Um cluster com várias zonas tem uma única réplica do plano de controle em execução em uma única zona, e tem nós em execução em várias zonas.
  • Cluster regional Os clusters regionais replicam os mestres e nós de cluster em várias zonas de uma região. Por exemplo, um cluster regional na região us-east1 cria réplicas do plano de controle e nós em três zonas de us-east1: us-east1-b, us-east1-c e us-east1-d.

Selecione o cluster que atende às suas necessidades de disponibilidade. Por exemplo, se você precisar que suas cargas de trabalho estejam altamente disponíveis, use um cluster regional.

Resumo geral

Para integrar os controles, determine seus requisitos de restrição de localidade. Em seguida, mapeie o escopo dos controles abordados neste guia e o estágio em que eles precisam ser configurados, da seguinte maneira:

  1. Defina seus requisitos regionais.
  2. Identifique o local apropriado para o cluster.
  3. Crie uma política da organização de localização de recursos para restringir a criação dos clusters do GKE apenas aos locais que atendem aos seus requisitos.
  4. Crie seus clusters particulares seguindo as orientações no guia de proteção de cluster do GKE. Ao criar o cluster, siga o guia de proteção e use a sinalização --enable-network-policy. Políticas de rede são necessárias, e esta etapa permite implementar posteriormente regras de firewall que restringem o tráfego que flui entre os pods em um cluster.
  5. Adicione redes autorizadas aos clusters particulares.

Se você precisar restringir onde os clientes podem acessar seus serviços, faça o seguinte:

  • Para clusters do GKE no Google Cloud, defina uma política de segurança do Google Cloud Armor para aplicar o controle de acesso com base na localização geográfica do tráfego de entrada. Anexe a política de segurança a cada um dos back-ends associados ao recurso de entrada.
  • Use o Anthos Config Management para definir políticas que restringem quem pode acessar seus clusters.