Visão geral da segurança

O Google Kubernetes Engine (GKE) oferece várias maneiras de proteger suas cargas de trabalho. A proteção de cargas de trabalho no GKE envolve muitas camadas da pilha, incluindo o conteúdo da imagem de contêiner, o ambiente de execução do 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 GKE, 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 ser facilmente concedidas permissões nos clusters e nos próprios clusters de projetos do Google Cloud, como em qualquer recurso do Google Cloud, usando o gerenciamento de identidade e acesso (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 GKE, confirme se o controle de acesso baseado em atributos (legado) está desativado para que o RBAC do Kubernetes e o IAM sejam as fontes confiáveis.

Para mais informações, veja o conteúdo a seguir:

Segurança do plano de controle

No GKE, os componentes do plano de controle do Kubernetes (em inglês) são gerenciados e mantidos pelo Google. Os componentes do plano de controle hospedam o software que executa o plano de controle do Kubernetes, incluindo o servidor de 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 do plano de controle usam um endereço IP público. É possível proteger o servidor da API Kubernetes usando redes autorizadas e clusters particulares, que permitem atribuir um IP privado ao plano de controle e desativar o acesso no endereço IP público.

Para processar a autenticação de cluster no Google Kubernetes Engine, use o IAM como o provedor de identidade. Para informações sobre autenticação, consulte Como autenticar no servidor da API Kubernetes.

Outra maneira de proteger o plano de controle é 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 alternados. Esse processo é automatizado pelo GKE e também garante que o endereço IP do plano de controle seja alternado.

Para mais informações:

Segurança de nós

O GKE implanta as cargas de trabalho nas instâncias do Compute Engine em execução no projeto do Google Cloud. Essas instâncias estão anexadas ao seu cluster do GKE como nó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 GKE 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 melhorar a segurança dos clusters do GKE, 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 upgrade manual dos nós no cluster, mas o GKE 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 GKE são executados como instâncias do Compute Engine e, portanto, têm acesso aos metadados de instâncias por padrão. Os metadados de instância são usados para fornecer aos nós credenciais e configurações usadas na inicialização e na conexão com os nós do plano de controle. 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 GKE 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 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, veja o conteúdo a seguir:

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 de Serviço. Com esse parâmetro de configuração, é possível fornecer uma lista de intervalos CIDR que terão acesso ao Serviço. Se você não configurar loadBalancerSourceRanges, todos os endereços terão permissão para acessar o Serviço 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, siga o tutorial de balanceamento de carga interno.

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 cluster. O GKE permite que você defina opções relacionadas à segurança por meio do contexto de segurança em pods e contêineres. Essas configurações permitem 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 GKE, tanto o Container-Optimized OS como o Ubuntu, aplicam as políticas de segurança padrão do AppArmor do Docker (em inglês) 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, veja o conteúdo a seguir:

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. No entanto, 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 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 Google Cloud específicas do aplicativo a fim de fornecer credenciais para que os aplicativos tenham as permissões mínimas necessárias. A cada conta de serviço são atribuídos apenas os papéis do 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 IAM, crie uma chave de conta de serviço JSON e ative-a no 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 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.

Registro de auditoria

Com a geração de registros de auditoria, os administradores podem reter, consultar, processar e alertar sobre eventos que ocorrem nos seus ambientes do GKE. 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 GKE está sendo usada.

Por padrão, o GKE registra os Registros de atividade do administrador. Se quiser, você também tem a opção de registrar eventos de acesso a dados, dependendo dos tipos de operações que quer inspecionar.

Para mais informações, veja o conteúdo a seguir: