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:

  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 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:

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.

Os nós do GKE Autopilot sempre usam o Container-Optimized OS como sistema operacional.

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.

Os clusters do GKE são compatíveis com upgrades automáticos. Nos clusters do Autopilot, os upgrades automáticos estão sempre ativados. Também é possível fazer upgrade manual dos nós em um cluster padrão.

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

O GKE usa metadados de instância das instâncias subjacentes do Compute Engine para fornecer aos nós credenciais e configurações usadas para inicializar nós e para se conectar aos nós plano de controle. Esses metadados contêm informações sensíveis que os pods no nó não precisam acessar, como a chave da conta de serviço do nó.

É possível bloquear caminhos de metadados sensíveis da instância usando a federação de identidade da carga de trabalho do GKE. A federação de identidade da carga de trabalho do GKE ativa o servidor de metadados do GKE no cluster, que filtra solicitações para campos confidenciais, como kube-env.

A federação de identidade da carga de trabalho do GKE está sempre ativada nos clusters do Autopilot. Em clusters padrão, os pods têm acesso aos metadados da instância, a menos que você ative manualmente a federação de identidade da carga de trabalho do GKE.

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 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 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. Os clusters do GKE Autopilot sempre restringem privilégios específicos, conforme descrito em Recursos de segurança do Autopilot.

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 aplicar essas restrições no nível do cluster, e não no nível do pod ou do contêiner, use o controlador PodSecurityAdmission Os administradores de clusters podem usar o PodSecurityAdmission para garantir que todos os pods em um cluster ou namespace sigam uma política predefinida nos Padrões de segurança de pods. Também é possível definir políticas de segurança de pods personalizadas no nível do cluster usando o Gatekeeper.

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:

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 segura de autorizar o acesso dos pods aos recursos do Google Cloud é utilizar a federação de identidade da carga de trabalho do GKE. A federação de identidade da carga de trabalho do GKE permite que uma conta de serviço do Kubernetes seja executada como uma conta de serviço do IAM. Os pods executados como conta de serviço do Kubernetes têm as permissões da conta de serviço do IAM.

A federação de identidade da carga de trabalho do GKE pode ser usada com o GKE Sandbox.

Conta de serviço de nó

Nos clusters padrão, os pods também podem se autenticar no Google Cloud usando as credenciais da conta de serviço usada pela máquina virtual (VM) do Compute Engine do nó.

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

É possível conceder credenciais de recursos do Google Cloud a aplicativos usando a chave da conta de serviço. Essa abordagem definitivamente não é recomendada devido à dificuldade de gerenciar chaves de conta com segurança.

Se você escolher esse método, use contas de serviço personalizadas do IAM para cada aplicativo para que eles tenham as permissões mínimas necessárias. Conceda a cada conta de serviço os papéis mínimos do IAM necessários para que o aplicativo pareado funcione. Manter as contas de serviço específicas do aplicativo 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 Artifact 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.

Com a validação contínua (CV) de autorização binária, é possível garantir que as imagens de contêiner associadas aos pods sejam monitoradas regularmente para garantir a conformidade com os processos internos em evolução.

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:

Medidas de segurança integradas

O GKE impõe restrições específicas sobre o que é possível fazer com os objetos do sistema nos clusters. Quando você executa uma operação como corrigir uma carga de trabalho, um webhook de admissão chamado GKE Warden valida sua solicitação em um conjunto de operações restritas e decide se a solicitação será permitida.

Medidas de segurança de clusters do Autopilot

Os clusters do Autopilot aplicam várias configurações de segurança com base na nossa experiência e nas práticas recomendadas do setor. Para mais detalhes, consulte Medidas de segurança no Autopilot.

Medidas de segurança de cluster padrão

Por padrão, os clusters padrão são mais permissivos do que os do Autopilot. Os clusters do GKE Standard têm as configurações de segurança a seguir:

  • Não é possível atualizar a conta de serviço usada pelas cargas de trabalho do sistema gerenciadas pelo GKE, como cargas de trabalho no namespace kube-system.
  • Não é possível vincular o ClusterRole padrão cluster-admin aos grupos system:anonymous, system:unauthenticated ou system:authenticated.