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 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 os pods (em inglês).

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

  1. Conta do Google
  2. Conta de serviço do Google Cloud

Uma vez autenticado, é preciso 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 Google Cloud são entidades diferentes. As contas de serviço do Kubernetes fazem parte do cluster em que elas são definidas e normalmente usadas dentro desse cluster. Por outro lado, as contas de serviço do Google Cloud fazem parte de um projeto do Google Cloud e podem receber permissões dentro de clusters e para os próprios clusters do projeto do Google Cloud, bem como para qualquer recurso do Google Cloud usando o Cloud Identity and Access Management (Cloud IAM). Isso torna as contas de serviço do Google Cloud mais eficientes do que as do Kubernetes. Para seguir o princípio de segurança de menor privilégio, use contas de serviço do Google Cloud somente quando os 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). Com o RBAC, é possível criar políticas detalhadas que definem quais operações e recursos você permite que usuários e contas de serviço acessem. Também é possível controlar o acesso de Contas do Google e de contas de serviço do Google Cloud 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. Para reforçar a segurança da autenticação, a autenticação básica e a emissão de certificados do cliente estão desativadas por padrão nos clusters criados com o GKE 1.12 e posterior.

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 Google Cloud. Essas instâncias estão anexadas ao cluster do Google Kubernetes Engine como nós (em inglês). As seções a seguir mostram como aproveitar os recursos de segurança no nível do nó disponíveis no Google Cloud.

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 atributos 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, escalonem e atualizem rapidamente as cargas de trabalho baseadas em contêiner. Nesta seção, você verá as táticas que administradores e usuários podem usar para limitar o efeito de um contêiner em execução sobre outros contêineres no mesmo cluster, os nós em que os contêineres podem ser executados e os serviços do Google Cloud 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 de 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 Google Cloud

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

A maneira mais simples e segura de autorizar os pods a acessar recursos do Google Cloud é 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 Google Cloud. Os pods executados como conta de serviço do Kubernetes têm as permissões da conta de serviço do Google Cloud.

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 Google Cloud usando as credenciais de conta de serviço dos clusters do Kubernetes a partir de metadados. Porém, essas credenciais podem ser conseguidas por qualquer pod em execução no cluster, se a identidade da carga de trabalho não estiver ativada. Crie e configure uma conta de serviço personalizada que tenha os papéis mínimos do Cloud 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 Google Cloud 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 Google Cloud que fornece segurança de cadeia de fornecimento de software para aplicativos executados na nuvem. 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 em 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: