Visão geral da segurança

O Google Kubernetes Engine oferece várias opções para proteger suas cargas de trabalho. A proteção de cargas de trabalho no Google Kubernetes Engine envolve muitas camadas da pilha, incluindo o conteúdo da imagem de contêiner, o ambiente de execução de contêiner, a rede de cluster e o acesso ao servidor da API de cluster.

É melhor adotar uma abordagem em camadas para proteger clusters e cargas de trabalho. Você pode aplicar o princípio do menor privilégio ao nível de acesso fornecido aos usuários e ao aplicativo. Em cada camada, pode haver diferentes compensações que permitam o nível correto de flexibilidade e segurança para sua organização implantar e manter com segurança as respectivas cargas de trabalho. Por exemplo, algumas configurações de segurança podem ser muito restritas para certos tipos de aplicativos ou casos de uso para funcionar sem refatoração significativa.

Neste documento, você terá uma visão geral de cada camada da sua infraestrutura e verá como configurar seus recursos de segurança para melhor atender às suas necessidades.

Autenticação e autorização

O Kubernetes é compatível com dois tipos de autenticação (em inglês):

  1. Contas de usuário são contas conhecidas, mas não gerenciadas pelo Kubernetes. Por exemplo, não é possível criá-las ou excluí-las usando a kubectl.
  2. Contas de serviço são contas criadas e gerenciadas pelo Kubernetes, mas que só podem ser usadas por entidades criadas pelo Kubernetes, como pods (em inglês).

Em um cluster do Google Kubernetes Engine, as contas de usuário do Kubernetes são gerenciadas pelo Google Cloud Platform (GCP) e podem ser um dos dois tipos a seguir:

  1. Conta do Google
  2. Conta de serviço do Google Cloud Platform (GCP)

Uma vez autenticado, você precisa autorizar essas identidades para criar, ler, atualizar ou excluir recursos do Kubernetes.

Embora tenham nomes semelhantes, as contas de serviço do Kubernetes e as do GCP são entidades diferentes. As contas de serviço do Kubernetes fazem parte do cluster em que elas são definidas e normalmente são usadas dentro desse cluster. Já as contas de serviço do GCP fazem parte de um projeto do GCP e podem receber permissões em clusters e nos próprios clusters de projeto do Google Cloud Platform, bem como em qualquer recurso do GCP usando o Cloud Identity & Access Management (Cloud IAM). Isso torna as contas de serviço do GCP mais eficientes do que as do Kubernetes. Para seguir o princípio de segurança de menor privilégio, considere usar contas de serviço do GCP somente quando seus recursos forem necessários.

Para configurar um acesso mais granular aos recursos do Kubernetes no nível do cluster ou nos namespaces do Kubernetes, use o controle de acesso baseado em papéis (RBAC, na sigla em inglês). O RBAC permite criar políticas detalhadas que definem quais operações e recursos você permite que usuários e contas de serviço acessem. Com o RBAC, você pode controlar o acesso de Contas do Google e de contas de serviço do GCP e do Kubernetes. Para simplificar e agilizar ainda mais sua estratégia de autenticação e autorização do Google Kubernetes Engine, confirme se o controle de acesso baseado em atributos legado está desativado para que o RBAC do Kubernetes e o Cloud IAM sejam as fontes confiáveis.

Para mais informações:

Segurança do plano de controle

No Google Kubernetes Engine, os componentes principais do Kubernetes (em inglês) são gerenciados e mantidos pelo Google. Eles hospedam o software que executa o plano de controle do Kubernetes, incluindo o servidor da API, o programador, o gerenciador do controlador e o banco de dados etcd (em inglês) em que a configuração do Kubernetes é mantida.

Por padrão, os componentes principais usam um endereço IP público. É possível proteger o servidor da API Kubernetes usando as principais redes autorizadas e clusters particulares, que permitem atribuir um endereço IP particular ao mestre e desativar o acesso no endereço IP público.

Para processar a autenticação de cluster no Google Kubernetes Engine, use o Cloud IAM como o provedor de identidade. No entanto, a autenticação baseada em senha e nome de usuário legada é ativada por padrão no Google Kubernetes Engine. Para aprimorar a segurança da autenticação, defina uma senha e um nome de usuário em branco para a configuração MasterAuth. Dessa forma, a Autenticação básica (em inglês) será desativada. Na mesma configuração, desative o certificado de cliente. Assim, você terá uma chave a menos para se preocupar ao bloquear o acesso ao seu cluster.

Outra maneira de proteger o mestre do Kubernetes é garantir que você esteja fazendo a rotação de credenciais regularmente. Quando a rotação de credenciais é iniciada, os certificados SSL e a autoridade de certificação de cluster são rotacionados. Esse processo é automatizado pelo Google Kubernetes Engine e também garante que seu endereço IP principal seja rotacionado.

Para mais informações:

Segurança de nós

O Google Kubernetes Engine implanta suas cargas de trabalho em instâncias do Compute Engine em execução no projeto do GCP. Essas instâncias estão anexadas ao seu cluster do Google Kubernetes Engine como nós. Veja nas seções a seguir como aproveitar os recursos de segurança de nós disponíveis no GCP.

Container-Optimized OS

Por padrão, os nós do Google Kubernetes Engine usam o Container-Optimized OS do Google como o sistema operacional em que o Kubernetes e os respectivos componentes são executados. O Container-Optimized OS implementa vários recursos avançados para aprimorar a segurança dos clusters do Google Kubernetes Engine, incluindo:

  • firewall bloqueado;
  • sistema de arquivos somente leitura, quando possível;
  • contas de usuário limitadas e login raiz desativado.

Upgrades de nós

Uma prática recomendada é aplicar patches ao seu sistema operacional regularmente. Às vezes, pode ser necessário fazer upgrade dos nós com mais urgência por conta de problemas de segurança no ambiente de execução do contêiner, no próprio Kubernetes ou no sistema operacional dos nós. Quando você faz o upgrade do seu nó, o software dele é atualizado para as versões mais recentes.

É possível fazer o upgrade manual dos nós no seu cluster, mas o Google Kubernetes Engine também permite ativar upgrades automáticos.

Como proteger nós de cargas de trabalho não confiáveis

Para clusters que executam cargas de trabalho desconhecidas ou não confiáveis, uma prática recomendada é proteger o sistema operacional no nó da carga de trabalho não confiável em execução em um pod.

Por exemplo, clusters multilocatários, como provedores de Software as a Service (SaaS), geralmente executam código desconhecido enviado por usuários. A pesquisa de segurança é outro aplicativo em que cargas de trabalho podem precisar de isolamento mais forte do que os nós fornecem por padrão.

É possível ativar o GKE Sandbox no cluster para isolar cargas de trabalho não confiáveis em sandboxes no nó. O GKE Sandbox é criado com o gVisor (em inglês), um projeto de código aberto.

Como proteger metadados de instâncias

Os nós do Google Kubernetes Engine são executados como instâncias do Compute Engine e têm acesso a metadados de instâncias por padrão. Esses metadados são usados para fornecer aos nós credenciais e configurações usadas no processo de bootstrap e na conexão com os nós principais do Kubernetes. No entanto, um pod em execução em um nó não precisa necessariamente dessas informações, que contêm dados confidenciais, como a chave da conta de serviço do nó. Para bloquear caminhos de metadados de instância confidenciais, desative as APIs legadas e use a ocultação de metadados. Essa ocultação filtra solicitações para campos como kube-env a fim de garantir que os pods em execução no cluster não consigam acessar dados confidenciais.

Segurança de rede

A maioria das cargas de trabalho em execução no Google Kubernetes Engine precisa se comunicar com outros serviços que podem estar em execução dentro ou fora do cluster. Há vários métodos diferentes para controlar o tráfego que pode fluir pelos seus clusters e os respectivos pods.

Como limitar a comunicação entre pods

Por padrão, todos os pods em um cluster podem ser acessados pela rede por meio do endereço IP do pod. Da mesma forma, por padrão, o tráfego de saída permite conexões de saída para qualquer endereço acessível na VPC em que o cluster foi implantado.

Os administradores e usuários de clusters podem bloquear as conexões de entrada e saída criadas de e para os pods em um namespace. Bastar usar políticas de rede (em inglês). Por padrão, quando não há políticas de rede definidas, todo o tráfego de entrada e saída pode entrar e sair de todos os pods. As políticas de rede permitem que você use tags para definir o tráfego que passa pelos seus pods.

Depois que uma política de rede é aplicada em um namespace, todo o tráfego é descartado nos pods que não correspondem aos rótulos configurados. Como parte da criação de clusters e/ou namespaces, você pode aplicar o tráfego de negação padrão à entrada e à saída de cada pod para garantir que todas as novas cargas de trabalho adicionadas ao cluster autorizem explicitamente o tráfego de que precisam.

Para mais informações:

Como filtrar o tráfego com balanceamento de carga

Para balancear a carga de seus pods do Kubernetes com um balanceador de carga de rede, você precisa criar um Service do tipo LoadBalancer que corresponda aos rótulos do seu pod. Com o Service criado, você terá um IP externo que realiza mapeamentos em portas nos pods do Kubernetes. A filtragem do tráfego autorizado é realizada no nível do nó por meio do kube-proxy, que faz isso com base no endereço IP.

Para configurar essa filtragem, use a configuração loadBalancerSourceRanges do objeto Service. Com esse parâmetro de configuração, é possível fornecer uma lista de intervalos de CIDR que você quer colocar na lista de permissões para acesso ao Service. Se você não configurar loadBalancerSourceRanges, todos os endereços terão permissão para acessar o Service por meio do respectivo IP externo.

Quando o acesso ao Service não é obrigatório, pense em usar um balanceador de carga interno. O balanceador de carga interno também respeita o loadBalancerSourceRanges quando é necessário filtrar o tráfego de dentro da VPC.

Para mais informações:

Como proteger suas cargas de trabalho

O Kubernetes permite que os usuários provisionem, dimensionem e atualizem rapidamente as cargas de trabalho baseadas em contêiner. Nesta seção, descrevemos as táticas que os administradores e usuários podem usar para limitar o efeito que um contêiner em execução pode ter em outros contêineres no mesmo cluster, nos nós em que eles podem ser executados e nos serviços do GCP ativados nos projetos dos usuários.

Como limitar os privilégios de processos em contêiner de pod

A limitação dos privilégios de processos em contêiner é importante para a segurança geral do seu cluster. O Google Kubernetes Engine permite que você defina opções relacionadas à segurança por meio do contexto de segurança em pods e contêineres. Com essas configurações, é possível alterar as definições de segurança dos seus processos, como:

  • usuário e grupo de execução;
  • recursos disponíveis do Linux;
  • capacidade de escalonar privilégios.

Para alterar essas configurações no nível do cluster, e não no pod ou no contêiner, implemente uma PodSecurityPolicy. Os administradores do cluster podem usar PodSecurityPolicies para garantir que todos os pods em um cluster cumpram uma política de valor de referência mínima definida por você.

Os sistemas operacionais dos nós do Google Kubernetes Engine (Container-Optimized OS e Ubuntu) aplicam as políticas de segurança AppArmor padrão do Docker a todos os contêineres iniciados pelo Kubernetes. É possível ver o modelo do perfil no GitHub (em inglês). Entre outras coisas, o perfil nega os seguintes recursos aos contêineres:

  • Gravar arquivos diretamente em /proc/.
  • Gravar em arquivos que não estão em um diretório de ID de processo (/proc/<number>).
  • Gravar em arquivos em um /proc/sys diferente de /proc/sys/kernel/shm*.
  • Ativar sistemas de arquivos.

Para mais informações:

Como conceder aos pods acesso aos recursos do GCP

Seus contêineres e pods podem precisar de acesso a outros recursos no GCP. Existem três maneiras de fazer isso.

A maneira mais simples e segura de autorizar os pods a acessar recursos do GCP é usar a Identidade da carga de trabalho. Ela permite que uma conta de serviço do Kubernetes seja executada como uma conta de serviço do GCP. Os pods executados como conta de serviço do Kubernetes têm as permissões da conta de serviço do GCP.

A Identidade da carga de trabalho pode ser usada com o GKE Sandbox.

Conta de serviço de nó

Seus pods também podem ser autenticados no GCP usando as credenciais de conta de serviço dos clusters do Kubernetes a partir de metadados. No entanto, essas credenciais podem ser conseguidas por qualquer pod em execução no cluster. Crie e configure uma conta de serviço personalizada que tenha os papéis mínimos do IAM exigidos por todos os pods em execução no cluster.

Essa abordagem não é compatível com o GKE Sandbox porque ele bloqueia o acesso ao servidor de metadados.

Chave JSON de conta de serviço

Uma terceira opção para conceder credenciais de recursos do GCP a aplicativos é usar manualmente a chave da conta de serviço. Essa abordagem definitivamente não é recomendada devido à dificuldade de gerenciar chaves de conta com segurança.

Use contas de serviço do GCP específicas do aplicativo a fim de fornecer credenciais para que os aplicativos tenham as permissões mínimas necessárias. Cada conta de serviço é atribuída apenas aos papéis do Cloud IAM necessários para que o aplicativo pareado funcione. Manter a conta de serviço específica a certos aplicativos facilita a revogação do acesso no caso de um comprometimento sem afetar outros aplicativos. Depois de ter atribuído à sua conta de serviço os papéis corretos do Cloud IAM, crie uma chave de conta de serviço JSON e ative-a no seu pod usando um secret do Kubernetes.

Como usar a autorização binária

A autorização binária é um serviço do GCP que fornece segurança de cadeia de fornecimento de software para aplicativos executados no Cloud. A autorização binária funciona com imagens que você implanta no GKE a partir do Container Registry ou de outro registro de imagens de contêiner. Com a autorização binária, é possível garantir que os processos internos que protegem a qualidade e a integridade do software sejam concluídos com êxito antes que um aplicativo seja implantado no seu ambiente de produção.

Para ver instruções sobre como criar um cluster com a autorização binária ativada, acesse Como criar um cluster na documentação da autorização binária.

Audit logging

Com a geração de registros de auditoria, os administradores podem reter, consultar, processar e alertar sobre eventos que ocorrem nos seus ambientes do Google Kubernetes Engine. Os administradores podem usar as informações registradas para fazer análises forenses, emitir alertas em tempo real ou catalogar como e por quem uma frota de clusters do Google Kubernetes Engine está sendo usada.

Por padrão, o Google Kubernetes Engine grava os registros de atividade do administrador. Se quiser, você também pode registrar eventos de acesso a dados, dependendo dos tipos de operações que quer inspecionar.

Para mais informações:

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine