Visão geral da segurança

O Google Kubernetes Engine fornece várias maneiras para ajudar a 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 do contêiner, o ambiente de execução do contêiner, a rede do cluster e o acesso ao servidor da API do 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:

  1. Contas de usuário são contas conhecidas pelo Kubernetes, mas que não são gerenciadas por ele. 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 pods.

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.

Apesar de terem 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 contas do Kubernetes. Para seguir o princípio de segurança de menor privilégio, use as contas de serviço do GCP somente quando os recursos delas 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 Kubernetes RBAC e o Cloud IAM sejam a "fonte da verdade".

Para mais informações:

Segurança do plano de controle

No Google Kubernetes Engine, os componentes principais do Kubernetes são gerenciados e mantidos pelo Google. Os componentes principais 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 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 redes principais autorizadas e clusters particulares, que permitem atribuir um endereço IP particular aos componentes principais e desativar o acesso no endereço IP público.

Você pode gerenciar a autenticação de cluster no Google Kubernetes Engine usando o Cloud IAM como o provedor de identidade. No entanto, a autenticação legada baseada em nome de usuário e senha é ativada por padrão no Google Kubernetes Engine. Para melhorar a segurança da autenticação, desative a autenticação básica definindo nome de usuário e senha vazios para a configuração do MasterAuth. Na mesma configuração, você também pode desativar o certificado de cliente. Assim, você terá uma chave a menos para pensar ao bloquear o acesso ao cluster.

Outra maneira de proteger os componentes principais 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 dos 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 do nó é 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 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ó. Você pode bloquear caminhos de metadados de instância confidenciais desativando as APIs legadas e usando a ocultação de metadados. Esse processo garante que os pods em execução no cluster não consigam acessar dados confidenciais ao filtrar solicitações para campos como kube-env.

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 usando políticas de rede. 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 de entrada e saída é descartado nos pods que não correspondam 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 dos pods do Kubernetes com um balanceador de carga de rede, você precisa criar um serviço do tipo LoadBalancer que seja correspondente com os rótulos do seu pod. Com o serviço criado, você terá um IP externo que mapeia para portas nos pods do Kubernetes. A filtragem do tráfego autorizado é realizada no nível do nó por meio do kube-proxy, que filtra com base no endereço IP.

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

Quando o acesso ao serviço não é obrigatório, pense em usar um balanceador de carga interno. Esse balanceador 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 dos processos em contêiner do pod

A limitação dos privilégios dos 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 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. Você pode ver o modelo do perfil no GitHub. Entre outras coisas, o perfil nega os seguintes recursos aos contêineres:

  • gravação de arquivos diretamente em /proc/
  • gravação em arquivos que não estão em um diretório de código de processo (/proc/)
  • gravação em arquivos em/proc/sys em vez de /proc/sys/kernel/shm*
  • ativação de 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. Uma maneira de os aplicativos terem acesso a credenciais de recursos do GCP é usar as credenciais da conta de serviço dos clusters do Kubernetes a partir de metadados. No entanto, essas credenciais podem ser acessadas por qualquer pod em execução no cluster. Crie e configure uma conta de serviço personalizada para seus clusters com os papéis mínimos do IAM que serão aplicados a todos os pods em execução no cluster.

Outra maneira de fornecer credenciais de aplicativos é usando uma chave JSON de conta de serviço. 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, você poderá criar uma chave de conta de serviço JSON e ativá-la no seu pod usando um segredo do Kubernetes.

Para mais informações:

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 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, visite 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