Vista geral da segurança do GKE

O Google Kubernetes Engine (GKE) oferece muitas formas de ajudar a proteger as suas cargas de trabalho. A proteção das cargas de trabalho no GKE envolve muitas camadas da pilha, incluindo o conteúdo da sua imagem de contentor, o tempo de execução do contentor, a rede do cluster e o acesso ao servidor da API do cluster.

É melhor adotar uma abordagem em camadas para proteger os seus clusters e cargas de trabalho. Pode aplicar o princípio do menor privilégio ao nível de acesso disponibilizado aos seus utilizadores e à sua aplicação. Em cada camada, a sua organização pode ter de fazer diferentes compromissos para permitir o nível certo de flexibilidade e segurança para implementar e manter as suas cargas de trabalho em segurança. Por exemplo, algumas definições de segurança podem ser demasiado restritivas para que determinados tipos de aplicações ou exemplos de utilização funcionem sem uma refatoração significativa.

Este documento fornece uma vista geral de cada camada da sua infraestrutura e mostra como pode configurar as respetivas funcionalidades de segurança para se adequarem melhor às suas necessidades.

Este documento destina-se a especialistas em segurança que definem, regem e implementam políticas e procedimentos para proteger os dados de uma organização contra o acesso não autorizado. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Autenticação e autorização

O Kubernetes suporta dois tipos de autenticação:

  1. As contas de utilizador são contas conhecidas pelo Kubernetes, mas não são geridas pelo Kubernetes. Por exemplo, não pode criá-las nem eliminá-las através do kubectl.
  2. As contas de serviço são contas criadas e geridas pelo Kubernetes, mas só podem ser usadas por entidades criadas pelo Kubernetes, como pods.

Num cluster do GKE, as contas de utilizador do Kubernetes são geridas pelo Google Cloude podem ser um dos dois tipos seguintes:

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

Após a autenticação, tem de autorizar estas identidades a criar, ler, atualizar ou eliminar recursos do Kubernetes.

Apesar dos nomes semelhantes, as contas de serviço do Kubernetes e as Google Cloud contas de serviço são entidades diferentes. As contas de serviço do Kubernetes fazem parte do cluster no qual são definidas e são normalmente usadas nesse cluster. Por outro lado, as Google Cloud contas de serviço fazem parte de um Google Cloud projeto e podem receber facilmente autorizações nos clusters e nos Google Cloud próprios clusters do projeto, bem como em qualquer Google Cloud recurso que use a gestão de identidade e de acesso (IAM). Isto torna as Google Cloud contas de serviço mais poderosas do que as contas de serviço do Kubernetes; para seguir o princípio de segurança do menor privilégio, deve considerar usar Google Cloud contas de serviço apenas quando as respetivas capacidades forem necessárias.

Para configurar um acesso mais detalhado aos recursos do Kubernetes ao nível do cluster ou nos espaços de nomes do Kubernetes, usa o controlo de acesso baseado em funções (CABF). O RBAC permite-lhe criar políticas detalhadas que definem as operações e os recursos aos quais permite que os utilizadores e as contas de serviço acedam. Com o RBAC, pode controlar o acesso para Contas Google, Google Cloud contas de serviço e contas de serviço do Kubernetes. Para simplificar e otimizar ainda mais a sua estratégia de autenticação e autorização para o GKE, deve garantir que o controlo de acesso baseado em atributos antigo está desativado para que o CABF do Kubernetes e a IAM sejam as fontes de verdade.

Para mais informações:

Segurança do plano de controlo

No GKE, os componentes do plano de controlo do Kubernetes são geridos e mantidos pela Google. Os componentes do plano de controlo alojam o software que executa o plano de controlo do Kubernetes, incluindo o servidor da API, o programador, o gestor de controladores e a API etcd. Se o cluster executar instâncias da base de dados etcd nas VMs do plano de controlo, estas instâncias também são geridas e mantidas pela Google.

Pode aceder ao plano de controlo através de um ponto final baseado em DNS (recomendado), pontos finais baseados em IP ou ambos. Se usar pontos finais baseados em IP, pode proteger o servidor da API Kubernetes através de redes autorizadas e não ativando o ponto final externo do plano de controlo. Isto permite-lhe atribuir um endereço IP interno ao painel de controlo e desativar o acesso no endereço IP externo. Se usar um ponto final baseado em DNS, pode usar o IAM e os VPC Service Controls para proteger o acesso ao plano de controlo com políticas conscientes da identidade e da rede.

Pode processar a autenticação de clusters no Google Kubernetes Engine usando o IAM como fornecedor de identidade. Para obter informações sobre a autenticação, consulte o artigo Autenticação no servidor da API Kubernetes.

Outra forma de ajudar a proteger o seu plano de controlo é garantir que faz a rotação de credenciais regularmente. Quando a rotação de credenciais é iniciada, os certificados SSL e a autoridade de certificação do cluster são rodados. Este processo é automatizado pelo GKE e também garante que o endereço IP do plano de controlo é alterado.

Para mais informações:

Segurança do nó

O GKE implementa as suas cargas de trabalho em instâncias do Compute Engine em execução no seu Google Cloud projeto. Estas instâncias estão anexadas ao seu cluster do GKE como nós. As secções seguintes mostram como tirar partido das funcionalidades de segurança ao nível do nó disponíveis no Google Cloud.

SO otimizado para contentores

Por predefinição, os nós do GKE usam o SO otimizado para contentores da Google como o sistema operativo no qual executar o Kubernetes e os respetivos componentes. O SO otimizado para contentores implementa várias funcionalidades avançadas para melhorar a segurança dos clusters do GKE, incluindo:

  • Firewall restrita
  • Sistema de ficheiros só de leitura sempre que possível
  • Contas de utilizador limitadas e início de sessão de raiz desativado

Os nós do GKE Autopilot usam sempre o SO otimizado para contentores como sistema operativo.

Atualizações de nós

Uma prática recomendada é aplicar patches ao seu SO regularmente. Periodicamente, os problemas de segurança no tempo de execução do contentor, no próprio Kubernetes ou no sistema operativo do nó podem exigir que atualize os nós com mais urgência. Quando atualiza o nó, o software do nó é atualizado para as versões mais recentes.

Os clusters do GKE suportam atualizações automáticas. Nos clusters do Autopilot, as atualizações automáticas estão sempre ativadas. Também pode atualizar manualmente os nós num cluster Standard.

Proteja os nós contra cargas de trabalho não fidedignas

Para clusters que executam cargas de trabalho desconhecidas ou não fidedignas, uma boa prática é proteger o sistema operativo no nó da carga de trabalho não fidedigna em execução num pod.

Por exemplo, os clusters multi-inquilinos, como os fornecedores de software como serviço (SaaS), executam frequentemente código desconhecido enviado pelos respetivos utilizadores. A investigação de segurança é outra aplicação em que as cargas de trabalho podem precisar de um isolamento mais forte do que o que os nós oferecem por predefinição.

Pode ativar o GKE Sandbox no cluster para isolar cargas de trabalho não fidedignas em sandboxes no nó. O GKE Sandbox é criado com o gVisor, um projeto de código aberto.

Proteja os metadados de instâncias

O GKE usa metadados de instâncias das instâncias do Compute Engine subjacentes para fornecer aos nós credenciais e configurações que são usadas para iniciar os nós e estabelecer ligação ao plano de controlo. Estes metadados contêm informações confidenciais às quais os pods no nó não precisam de aceder, como a chave da conta de serviço do nó.

Pode bloquear caminhos de metadados de instâncias confidenciais através da Federação de identidades de cargas de trabalho para o GKE. A Workload Identity Federation para o GKE ativa o servidor de metadados do GKE no seu cluster, que filtra pedidos para campos confidenciais, como kube-env.

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

Segurança de redes

A maioria das cargas de trabalho executadas no GKE tem de comunicar com outros serviços que podem estar a ser executados dentro ou fora do cluster. Pode usar vários métodos diferentes para controlar o tráfego que tem autorização para fluir através dos seus clusters e respetivos pods.

Limite a comunicação entre pods

Por predefinição, todos os pods num cluster podem ser alcançados através da rede através do respetivo endereço IP do pod. Da mesma forma, por predefinição, o tráfego de saída permite ligações de saída a qualquer endereço acessível na VPC na qual o cluster foi implementado.

Os administradores e os utilizadores do cluster podem restringir as ligações de entrada e saída criadas para e a partir dos pods num espaço de nomes através de políticas de rede. Por predefinição, quando não existem políticas de rede definidas, todo o tráfego de entrada e saída pode fluir para dentro e para fora de todos os pods. As políticas de rede permitem-lhe usar etiquetas para definir o tráfego que flui através dos seus pods.

Assim que uma política de rede é aplicada num espaço de nomes, todo o tráfego é eliminado para e a partir de Pods que não correspondem às etiquetas configuradas. Como parte da criação de clusters e/ou namespaces, pode aplicar o tráfego de negação predefinido à entrada e saída de cada Pod para garantir que todas as novas cargas de trabalho adicionadas ao cluster têm de autorizar explicitamente o tráfego de que precisam.

Para mais informações:

Filtre o tráfego com balanceamento de carga

Para equilibrar a carga dos seus pods do Kubernetes com um balanceador de carga de rede, tem de criar um serviço do tipo LoadBalancer que corresponda às etiquetas dos seus pods. Com o serviço criado, tem um IP virado para o exterior que é mapeado para portas nos seus pods do Kubernetes. A filtragem do tráfego autorizado é feita ao nível do nó pelo kube-proxy, que filtra com base no endereço IP.

Para configurar esta filtragem, pode usar a configuração loadBalancerSourceRanges do objeto Service. Com este parâmetro de configuração, pode fornecer uma lista de intervalos CIDR aos quais quer permitir o acesso ao Serviço. Se não configurar loadBalancerSourceRanges, todos os endereços têm autorização para aceder ao Serviço através do respetivo IP externo.

Para os casos em que não é necessário acesso externo ao serviço, considere usar um equilibrador de carga interno. O balanceador de carga interno também respeita o loadBalancerSourceRanges quando é necessário filtrar o tráfego do interior da VPC.

Para mais informações, siga o tutorial de balanceamento de carga interno.

Filtre o tráfego fora do cluster

Para controlar o fluxo de tráfego de rede entre entidades externas e o seu cluster, use a firewall de nova geração do Google Cloud. Pode usar configurações de firewall para, por exemplo, bloquear o tráfego de saída dos seus Pods para destinos não aprovados.

As configurações da firewall não são suficientes para controlar os registos de onde provêm as imagens dos contentores no seu cluster. Para limitar as obtenções de imagens de contentores a um conjunto de registos aprovados, consulte o artigo Bloqueie imagens de contentores de registos não aprovados.

Proteja as suas cargas de trabalho

O Kubernetes permite que os utilizadores aprovisionem, dimensionem e atualizem rapidamente cargas de trabalho baseadas em contentores. Esta secção descreve as táticas que os administradores e os utilizadores podem empregar para limitar o efeito que um contentor em execução pode ter noutros contentores no mesmo cluster, nos nós onde os contentores podem ser executados e nos Google Cloud serviços ativados nos projetos dos utilizadores.

Limite os privilégios para processos de pods contentorizados

Limitar os privilégios dos processos em contentores é importante para a segurança geral do seu cluster. Os clusters do GKE Autopilot restringem sempre privilégios específicos, conforme descrito nas capacidades de segurança do Autopilot.

O GKE também lhe permite definir opções relacionadas com a segurança através do contexto de segurança em pods e contentores. Estas definições permitem-lhe alterar as definições de segurança dos seus processos, como:

  • Utilizador e grupo a executar como
  • Capacidades do Linux disponíveis
  • Capacidade de escalar privilégios

Para aplicar estas restrições ao nível do cluster em vez de ao nível do pod ou do contentor, use o controlador PodSecurityAdmission. Os administradores de clusters podem usar o PodSecurityAdmission para garantir que todos os pods num cluster ou num espaço de nomes cumprem uma política predefinida nas normas de segurança de pods. Também pode definir políticas de segurança de pods personalizadas ao nível do cluster através do Gatekeeper.

Os sistemas operativos dos nós do GKE, tanto o SO otimizado para contentores como o Ubuntu, aplicam as políticas de segurança do AppArmor do Docker predefinidas a todos os contentores iniciados pelo Kubernetes. Pode ver o modelo do perfil no GitHub. Entre outras coisas, o perfil nega as seguintes capacidades aos contentores:

  • Escreva ficheiros diretamente no /proc/
  • Escrever em ficheiros que não estão num diretório de ID do processo (/proc/<number>)
  • Escrever em ficheiros em /proc/sys que não sejam /proc/sys/kernel/shm*
  • Montar sistemas de ficheiros

Para mais informações:

Conceda acesso dos pods a recursos do Google Cloud

Os seus contentores e pods podem precisar de acesso a outros recursos em Google Cloud. Existem três formas de o fazer.

A forma mais segura de autorizar os pods a acederem a Google Cloud recursos é com a federação de identidades da carga de trabalho para o GKE. A federação de identidades da carga de trabalho para o GKE permite que uma conta de serviço do Kubernetes seja executada como uma conta de serviço do IAM. Os pods que são executados como a conta de serviço do Kubernetes têm as autorizações da conta de serviço do IAM.

A Workload Identity Federation para o GKE pode ser usada com o GKE Sandbox.

Conta de serviço do nó

Nos clusters Standard, os seus pods também podem autenticar-se Google Cloud através das credenciais da conta de serviço usada pela máquina virtual (VM) do Compute Engine do nó.

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

Pode conceder credenciais para Google Cloud recursos a aplicações através da chave da conta de serviço. Esta abordagem é fortemente desaconselhada devido à dificuldade de gerir as chaves da conta em segurança.

Se escolher este método, use contas de serviço do IAM personalizadas para cada aplicação, de modo que as aplicações tenham as autorizações mínimas necessárias. Conceda a cada conta de serviço as funções do IAM mínimas necessárias para que a respetiva aplicação sincronizada funcione com êxito. Manter as contas de serviço específicas da aplicação facilita a revogação do acesso em caso de comprometimento sem afetar outras aplicações. Depois de atribuir à sua conta de serviço as funções de IAM corretas, pode criar uma chave de conta de serviço JSON e, em seguida, montar a chave no seu pod através de um segredo do Kubernetes.

Use a Autorização binária

A autorização binária é um serviço no Google Cloud que oferece segurança da cadeia de fornecimento de software para aplicações executadas na nuvem. A autorização binária funciona com imagens que implementa no GKE a partir do Artifact Registry ou de outro registo de imagens de contentores.

Com a aplicação da autorização binária, pode garantir que os processos internos que salvaguardam a qualidade e a integridade do seu software foram concluídos com êxito antes de uma aplicação ser implementada no seu ambiente de produção. Para obter instruções sobre como criar um cluster com a autorização binária ativada, visite o artigo Criar um cluster na documentação da autorização binária.

Com a validação contínua (CV) da autorização binária, pode garantir que as imagens de contentores associadas aos pods são monitorizadas regularmente para garantir que estão em conformidade com os seus processos internos em evolução.

Registo de auditoria

O registo de auditoria oferece aos administradores uma forma de reter, consultar, processar e enviar alertas sobre eventos que ocorrem nos seus ambientes do GKE. Os administradores podem usar as informações registadas para fazer análises forenses, alertas em tempo real ou para catalogar como uma frota de clusters do GKE está a ser usada e por quem.

Por predefinição, o GKE regista os registos de atividade do administrador. Opcionalmente, também pode registar eventos de acesso aos dados, consoante os tipos de operações que tem interesse em inspecionar.

Para mais informações:

Medidas de segurança integradas

O GKE aplica restrições específicas ao que pode fazer aos objetos do sistema nos seus clusters. Quando realiza uma operação como criar ou aplicar um patch a uma carga de trabalho, um webhook de admissão denominado warden-validating valida o seu pedido em relação a um conjunto de operações restritas e decide se permite o pedido.

Os erros de admissão causados por esta política são semelhantes aos seguintes:

GKE Warden rejected the request because it violates one or more constraints.

Medidas de segurança do cluster do Autopilot

Os clusters do Autopilot aplicam várias definições de segurança com base na nossa experiência e nas práticas recomendadas da indústria. Para mais detalhes, consulte o artigo Medidas de segurança no Autopilot.

Medidas de segurança padrão do cluster

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

  • Não pode atualizar a ServiceAccount usada por cargas de trabalho do sistema geridas pelo GKE, como cargas de trabalho no espaço de nomes kube-system.
  • Não pode associar o ClusterRole predefinido cluster-admin aos grupos system:anonymous, system:unauthenticated ou system:authenticated.