Reforce a segurança do seu cluster

Este documento fornece práticas recomendadas para melhorar a segurança dos seus ambientes do Google Kubernetes Engine (GKE). Os especialistas em segurança que definem, regem e implementam políticas e procedimentos podem usar estas práticas recomendadas para proteger os dados da respetiva organização.

Já deve estar familiarizado com o seguinte:

Os novos clusters do GKE implementam muitas das práticas recomendadas neste documento por predefinição. Os clusters do modo Autopilot têm uma postura de segurança predefinida mais rigorosa do que os clusters do modo Standard.

Para implementar e aplicar as práticas recomendadas neste documento em toda a sua organização, considere os seguintes serviços:

  • Security Command Center: verifica automaticamente se os seus clusters implementam muitas destas práticas recomendadas e procura outras configurações incorretas comuns.
  • Serviço de políticas da organização: aplique práticas recomendadas específicas a recursos do GKE numa organização, pasta ou projeto. Secções específicas neste documento têm links para a Google Cloud consola para aplicar restrições geridas para essas recomendações.

Google Cloud environment design

As secções seguintes descrevem as medidas de segurança que deve considerar quando planeia e cria os seus recursos no Google Cloud. Os arquitetos de nuvem devem usar estas recomendações ao planear e definir a arquitetura. Google Cloud

Práticas recomendadas

Planeie a sua Google Cloud estrutura de recursos

Recomendado: implemente o projeto de base empresarial, que é uma base completa para o seu ambiente empresarial com base nas nossas melhores práticas.

A arquitetura das suas Google Cloud organizações, pastas e projetos afeta a sua postura de segurança. Conceba estes recursos fundamentais de forma a permitir controlos de governação e segurança em grande escala nos seus serviços.

Planeie ambientes multi-inquilino

Recomendado: implemente as práticas recomendadas do GKE para plataformas empresariais multiinquilinas. Google Cloud

Muitos clientes do GKE gerem equipas distribuídas com fluxos de trabalho e responsabilidades de engenharia separados. Estes ambientes multi-inquilinos têm de ter uma infraestrutura partilhada que todos os seus programadores possam usar, ao mesmo tempo que restringem o acesso a componentes com base em funções e responsabilidades. O esquema da aplicação empresarial baseia-se no esquema das bases empresariais para ajudar a implementar plataformas de programadores internas em ambientes multi-inquilinos.

Para mais informações, consulte os seguintes documentos:

Use etiquetas para agrupar Google Cloud recursos

Recomendado: use etiquetas para organizar os recursos do GKE para aplicação de políticas condicionais e melhor responsabilização nas suas equipas.

As etiquetas são metadados que pode anexar a recursos nas suas organizações, pastas e projetos para identificar dimensões empresariais na suaGoogle Cloud hierarquia de recursos. Pode anexar etiquetas a clusters e pools de nós do GKE e, em seguida, usar essas etiquetas para aplicar condicionalmente políticas de organização, políticas de IAM ou políticas de firewall.

Para mais informações, consulte os seguintes documentos:

Planeie as suas redes VPC

Recomendado: implemente as práticas recomendadas do GKE e do Google Cloud design da rede VPC.

O design da sua rede VPC e as funcionalidades que usa afetam a segurança da rede. Planeie as suas redes com base na Google Cloud hierarquia de recursos e nos seus objetivos de segurança. Para mais informações, consulte os seguintes documentos:

Conceba um plano de resposta a incidentes

Recomendado: crie e mantenha um plano de resposta a incidentes que cumpra os seus objetivos de segurança e fiabilidade.

Os incidentes de segurança podem ocorrer mesmo quando implementa todos os controlos de segurança possíveis. Um plano de resposta a incidentes ajuda a identificar potenciais lacunas nos seus controlos de segurança, a responder de forma rápida e eficaz a vários tipos de incidentes e a reduzir o tempo de inatividade durante uma indisponibilidade. Para mais informações, consulte os seguintes documentos:

Google Cloud segurança de redes

As secções seguintes fornecem recomendações de segurança para as suas redes VPC. Os arquitetos de rede e os administradores de rede devem aplicar estas recomendações para reduzir a superfície de ataque ao nível da rede e limitar o impacto do acesso não intencional à rede.

Práticas recomendadas

Use regras de firewall de privilégio mínimo

Recomendado: quando criar regras de firewall, use o princípio do menor privilégio para conceder acesso apenas para a finalidade necessária. Certifique-se de que as regras da firewall não entram em conflito nem substituem as regras da firewall predefinidas do GKE, sempre que possível.

O GKE cria regras de firewall da VPC predefinidas para ativar a funcionalidade do sistema e aplicar boas práticas de segurança. Se criar regras de firewall permissivas com uma prioridade superior à de uma regra de firewall predefinida (por exemplo, uma regra de firewall que permita todo o tráfego de entrada para depuração), o cluster corre o risco de acesso não intencional.

Use a VPC partilhada para tráfego entre projetos

Recomendado: use a VPC partilhada para permitir que os recursos em vários projetos comuniquem entre si através de endereços IP internos.

Os recursos em diferentes projetos na sua organização podem ter de comunicar entre si. Por exemplo, os serviços de front-end num cluster do GKE num projeto podem ter de comunicar com instâncias do Compute Engine de back-end num projeto diferente.

Para mais informações, consulte os seguintes documentos:

Use redes separadas para isolar ambientes

Recomendado: use redes VPC partilhadas separadas para ambientes de teste, de produção e de preparação.

Isole os seus ambientes de desenvolvimento uns dos outros para reduzir o impacto e o risco de acesso não autorizado ou erros disruptivos. Para mais informações, consulte Vários projetos anfitriões.

Definições de segurança imutáveis

As secções seguintes fornecem recomendações de segurança que só pode configurar quando cria clusters ou conjuntos de nós. Não pode atualizar clusters existentes nem conjuntos de nós para alterar estas definições. Os administradores da plataforma devem aplicar estas recomendações a novos clusters e conjuntos de nós.

Use contas de serviço de nós de IAM com o menor número possível de privilégios

Recomendado: use uma conta de serviço da IAM personalizada para os seus clusters do GKE e conjuntos de nós em vez de usar a conta de serviço do Compute Engine predefinida.

O GKE usa contas de serviço da IAM anexadas aos seus nós para executar tarefas do sistema, como registo e monitorização. No mínimo, estas contas de serviço de nós têm de ter a função Conta de serviço de nós predefinida do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por predefinição, o GKE usa a conta de serviço predefinida do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.

Se usar a conta de serviço predefinida do Compute Engine para outras funções no seu projeto ou organização, a conta de serviço pode ter mais autorizações do que o GKE precisa, o que pode expô-lo a riscos de segurança.

A conta de serviço associada aos seus nós deve ser usada apenas por cargas de trabalho do sistema que realizam tarefas como registo e monitorização. Para as suas próprias cargas de trabalho, aprovisione identidades através da federação de identidade da carga de trabalho para o GKE.

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.disallowDefaultComputeServiceAccount restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Use uma imagem de nó do SO otimizado para contentores

Recomendado: a menos que tenha um requisito específico para usar o Ubuntu ou o Windows, use a imagem do nó do SO otimizado para contentores para os seus nós.

O SO otimizado para contentores é criado, otimizado e reforçado especificamente para executar contentores. O SO otimizado para contentores é a única imagem de nó suportada para o modo Autopilot e é a imagem de nó predefinida para o modo Standard.

Para mais informações, consulte os seguintes documentos:

Configuração de segurança do nó

As secções seguintes fornecem recomendações de segurança para a configuração dos nós do GKE. Os administradores da plataforma e os engenheiros de segurança devem aplicar estas recomendações para melhorar a integridade dos seus nós do GKE.

Práticas recomendadas

Use nós do GKE protegidos

Recomendado: ative os nós do GKE protegidos, o arranque seguro e a monitorização da integridade em todos os clusters e conjuntos de nós.

Os nós do GKE protegidos oferecem verificações de identidade e integridade validáveis que melhoram a segurança dos seus nós. Os nós do GKE protegidos e as funcionalidades como a monitorização da integridade dos nós e o arranque seguro estão sempre ativados nos clusters do Autopilot. Nos clusters padrão, faça o seguinte:

  • Não desative os nós do GKE protegidos nos seus clusters.
  • Ative o arranque seguro em todos os seus conjuntos de nós.
  • Não desative a monitorização da integridade nos seus conjuntos de nós.

Para mais informações sobre como ativar estas funcionalidades, consulte o artigo Usar nós do GKE protegidos.

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.enableShieldedNodes restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Desative a porta só de leitura do kubelet não segura

Recomendado: desative a porta de leitura exclusiva kubelet e mude todas as cargas de trabalho que usam a porta 10255 para usar a porta mais segura 10250.

O processo kubelet em execução nos nós publica uma API só de leitura através da porta não segura 10255. O Kubernetes não realiza verificações de autenticação nem de autorização nesta porta. O kubelet serve os mesmos pontos finais na porta autenticada mais segura 10250.

Para mais informações, consulte o artigo Desative a porta de leitura apenas kubelet nos clusters do GKE.

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.disableInsecureKubeletReadOnlyPort restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Controlo de acesso

As secções seguintes fornecem recomendações para restringir o acesso não autorizado no seu cluster. Os engenheiros de segurança e os administradores de identidade e contas devem aplicar estas recomendações para reduzir a sua superfície de ataque e limitar o impacto do acesso não autorizado.

Práticas recomendadas

Restrinja o acesso à deteção da API de clusters

Recomendado: restrinja o acesso ao seu painel de controlo e nós a partir da Internet para evitar o acesso não intencional aos pontos finais de deteção da API do cluster.

Por predefinição, o Kubernetes cria clusters com um conjunto permissivo de funções de descoberta de API predefinidas. Estas funções predefinidas concedem um acesso amplo a informações sobre as APIs de um cluster a vários grupos predefinidos, como system:authenticated. Estas funções predefinidas não representam um nível de segurança significativo para os clusters do GKE. Por exemplo, o grupo system:authenticated, que pode ler informações sobre APIs, como CustomResources, é atribuído a qualquer utilizador autenticado (incluindo qualquer pessoa com uma Conta Google).

Para restringir o acesso às APIs de deteção de clusters, faça o seguinte:

  • Restrinja o acesso ao plano de controlo: use apenas o ponto final baseado em DNS para aceder ao plano de controlo. Se usar pontos finais baseados em IP, restrinja o acesso a um conjunto de intervalos de endereços conhecidos configurando redes autorizadas.
  • Configure nós privados: desative os endereços IP externos dos seus nós para que os clientes fora da sua rede não possam aceder aos nós.

Para mais informações, consulte o artigo Acerca do isolamento de rede.

Se não ativar estas funcionalidades de isolamento de rede, trate todas as informações de deteção de API (especialmente o esquema de CustomResources, as definições de APIService e as informações de deteção alojadas por servidores de API de extensão) como divulgadas publicamente.

Coloque equipas e ambientes em espaços de nomes ou clusters separados

Conceda às equipas acesso com privilégios mínimos ao Kubernetes criando namespaces ou clusters separados para cada equipa e ambiente. Para cada namespace ou cluster, atribua centros de custos e etiquetas para responsabilidade e reembolso.

Pode usar as autorizações de IAM e CABF juntamente com os espaços de nomes para restringir as interações dos utilizadores com os recursos do cluster na Google Cloud consola. Para mais informações, consulte o artigo Ative o acesso e veja os recursos do cluster por espaço de nomes.

Use o princípio do menor privilégio nas políticas de acesso

Recomendado: conceda aos programadores apenas o acesso de que precisam para implementar e gerir aplicações no respetivo espaço de nomes, especialmente em ambientes de produção. Quando conceber as suas políticas de controlo de acesso, mapeie as tarefas que os seus utilizadores têm de realizar no cluster e conceda-lhes apenas as autorizações que lhes permitem realizar essas tarefas.

No GKE, pode usar o IAM e o controlo de acesso baseado em funções (CABF) do Kubernetes para conceder autorizações em recursos. Estes mecanismos de controlo de acesso funcionam em conjunto. Para reduzir a complexidade da gestão do acesso, faça o seguinte:

  • Para dar acesso ao seu projeto ou a Google Cloud recursos, use funções do IAM.

  • Para conceder acesso a recursos do Kubernetes no seu cluster, como espaços de nomes, use o CABF.

Para mais informações sobre o planeamento e a conceção de políticas de IAM e RBAC, consulte os seguintes documentos:

Use a federação de identidade da carga de trabalho para o GKE para aceder às Google Cloud APIs

Recomendado: para aceder aos recursos Google Cloud das suas cargas de trabalho do GKE, use a federação de identidades da carga de trabalho para o GKE.

A Workload Identity Federation para o GKE é a forma recomendada de autenticação nas Google Cloud APIs. Pode conceder funções do IAM em vários recursos a principais no seu cluster, como ServiceAccounts ou pods específicos do Kubernetes. A Workload Identity Federation para o GKE também protege metadados confidenciais nos seus nós e oferece um fluxo de trabalho de autenticação mais seguro do que alternativas como ficheiros de tokens estáticos.

A federação de identidade da carga de trabalho para o GKE está sempre ativada em clusters do Autopilot. Nos clusters padrão, ative a Workload Identity Federation para o GKE para todos os clusters e conjuntos de nós. Além disso, siga estas recomendações:

  • Se usar Google Cloud bibliotecas de cliente no código da sua aplicação, não distribua Google Cloud credenciais aos seus fluxos de trabalho. O código que usa bibliotecas cliente obtém automaticamente as credenciais para a Workload Identity Federation para o GKE.
  • Use um namespace e uma ServiceAccount separados para cada carga de trabalho que precise de uma identidade distinta. Conceder autorizações de IAM a contas de serviço específicas.

Para mais informações, consulte o artigo Autentique-se nas Google Cloud APIs a partir de cargas de trabalho do GKE.

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.enableWorkloadIdentityFederation restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Use grupos para gerir o acesso

Recomendado: nas suas políticas de acesso, conceda autorizações a grupos de utilizadores em vez de a indivíduos.

Quando gere utilizadores em grupos, o seu sistema de gestão de identidades e os administradores de identidades podem controlar as identidades de forma centralizada modificando a associação de utilizadores em vários grupos. Este tipo de gestão elimina a necessidade de atualizar as políticas de RBAC ou IAM sempre que um utilizador específico precisar de permissões atualizadas.

Pode especificar grupos Google nas suas políticas de IAM ou CABF. Para mais informações, consulte os seguintes documentos:

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.enableGoogleGroupsRBAC restrição da política organizacional gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Restrinja o acesso anónimo a pontos finais do cluster

Recomendado: impeça pedidos anónimos a todos os pontos finais do cluster, exceto aos pontos finais de verificação do estado de funcionamento, em todos os clusters do Autopilot e Standard.

Por predefinição, o Kubernetes atribui o utilizador system:anonymous e o grupo system:unauthenticated a pedidos anónimos a pontos finais do cluster. Se as suas políticas de RBAC concederem permissões adicionais a este utilizador ou grupo, um utilizador anónimo pode comprometer a segurança de um serviço ou do próprio cluster.

Na versão 1.32.2-gke.1234000 e posteriores do GKE, pode limitar o conjunto de pontos finais que os pedidos anónimos podem alcançar apenas aos pontos finais de verificação do estado do servidor da API Kubernetes /healthz, /livez e /readyz. O acesso anónimo a estes pontos finais de verificação de estado é necessário para verificar se um cluster está a funcionar corretamente.

Para limitar o acesso anónimo aos pontos finais do cluster, especifique LIMITED para a flag --anonymous-authentication-config quando usar a CLI gcloud ou a API GKE para criar ou atualizar clusters Standard e Autopilot. O GKE rejeita pedidos anónimos para pontos finais do cluster que não sejam os pontos finais de verificação de funcionamento durante a autenticação. Os pedidos anónimos não chegam aos pontos finais, mesmo que as suas políticas de RBAC concedam acesso a utilizadores e grupos anónimos. Os pedidos rejeitados devolvem um estado HTTP de 401.

Para aplicar esta recomendação na sua organização, pasta ou projeto através de uma política da organização, crie uma restrição personalizada com a condição resource.anonymousAuthenticationConfig.mode. Para mais informações e um exemplo de restrição, consulte o artigo Restrinja ações em recursos do GKE com políticas de organização personalizadas.

Não confie apenas nesta capacidade para proteger o seu cluster. Implemente medidas de segurança adicionais, como as seguintes:

Segurança de rede do GKE

As secções seguintes fornecem recomendações para melhorar a segurança da rede nos seus clusters. Os administradores de rede e os engenheiros de segurança devem aplicar estas recomendações para proteger as cargas de trabalho e a infraestrutura de acesso externo ou interno não intencional.

Práticas recomendadas

Restrinja o acesso ao plano de controlo

Recomendado: ative o ponto final baseado em DNS para acesso ao painel de controlo e desative todos os pontos finais do painel de controlo baseados em IP.

Por predefinição, as entidades externas, como os clientes na Internet, podem alcançar o seu plano de controlo. Pode restringir quem pode aceder ao seu plano de controlo configurando o isolamento de rede.

Para isolar o plano de controlo, faça uma das seguintes ações:

  • Use apenas o ponto final baseado em DNS (recomendado): ative o ponto final baseado em DNS para o plano de controlo e desative os pontos finais baseados em IP internos e externos. Todo o acesso ao plano de controlo tem de usar o ponto final baseado em DNS. Pode usar os VPC Service Controls para controlar quem pode aceder ao ponto final baseado em DNS.

    Para aplicar esta recomendação na sua organização, use a constraints/container.managed.enableControlPlaneDNSOnlyAccess restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

    Aceder aos detalhes da política

  • Desative o ponto final baseado em IP externo: remova o endereço IP externo do plano de controlo. Os clientes que estão fora da sua rede VPC não podem usar o endereço IP externo para aceder ao plano de controlo.

    Esta opção funciona bem se usar tecnologias como o Cloud Interconnect e o Cloud VPN para ligar a rede da sua empresa à rede VPC.

  • Use redes autorizadas com o ponto final baseado em IP externo: restrinja o acesso ao ponto final baseado em IP externo apenas a um intervalo fidedigno de endereços IP de origem.

    Esta opção funciona bem se não tiver uma infraestrutura de VPN existente ou se tiver utilizadores remotos ou filiais que acedem aos seus clusters através da Internet pública.

Na maioria dos cenários, use apenas o ponto final baseado em DNS para o acesso ao plano de controlo. Se tiver de ativar o ponto final baseado em IP, use redes autorizadas para limitar o acesso ao plano de controlo às seguintes entidades:

  • Os intervalos de endereços IP que especificar.
  • Nós do GKE na mesma rede VPC que o cluster.
  • Endereços IP reservados pela Google para fins de gestão de clusters.

Isole os seus nós da Internet

Por predefinição, todos os nós do GKE têm um endereço IP externo que os clientes na Internet podem alcançar. Para remover este endereço IP externo, ative os nós privados.

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.enablePrivateNodes restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Restrinja o tráfego de rede entre pods

Recomendado: controle o tráfego de rede de pod para pod através de NetworkPolicies, uma malha de serviços ou ambos.

Por predefinição, todos os pods no cluster podem comunicar com todos os outros pods. A restrição do acesso à rede entre serviços torna muito mais difícil para os atacantes moverem-se lateralmente no seu cluster. Os seus serviços também ganham alguma proteção contra incidentes de negação de serviço acidentais ou deliberados. Consoante os seus requisitos, use um ou ambos os seguintes métodos para restringir o tráfego de pod a pod:

Proteção de dados confidenciais

As secções seguintes fornecem recomendações para encriptar dados e proteger informações confidenciais, como credenciais. Os engenheiros de segurança e os administradores da plataforma devem aplicar estas recomendações para reduzir o risco de acesso não intencional a dados críticos.

Práticas recomendadas

Encripte os dados de carga de trabalho em utilização

Use a encriptação de memória baseada em hardware para proteger os dados que estão a ser usados pelas suas cargas de trabalho através de nós GKE confidenciais. Pode escolher uma tecnologia de computação confidencial com base nos seus requisitos. Para mais informações, consulte o artigo Encriptar dados de carga de trabalho em utilização com nós do GKE confidenciais.

Armazene segredos fora do cluster

Recomendado: use um gestor de segredos externo, como o Secret Manager, para armazenar dados confidenciais, como chaves de API, fora do cluster.

No Kubernetes, pode armazenar dados confidenciais em segredos no seu cluster. Pode usar segredos para fornecer dados confidenciais a aplicações sem incluir esses dados no código da aplicação. No entanto, o armazenamento destes dados no seu cluster tem riscos, como os seguintes:

  • Qualquer pessoa que possa criar Pods num namespace pode ler os dados de qualquer Secret nesse namespace.
  • Qualquer pessoa com acesso RBAC ou IAM para ler todos os objetos da API Kubernetes pode ler segredos.

Devido a estes riscos, crie segredos no seu cluster apenas quando não puder fornecer esses dados às suas cargas de trabalho de outra forma. Recomendamos os seguintes métodos, por ordem de preferência, para armazenar e aceder aos seus dados confidenciais:

  • Bibliotecas cliente do Secret Manager: aceda programaticamente a segredos a partir do código da sua aplicação através da API Secret Manager com a federação de identidade da força de trabalho para o GKE. Para mais informações, consulte o artigo Aceda a segredos armazenados fora dos clusters do GKE através de bibliotecas de cliente.
  • Dados do Secret Manager como volumes montados: forneça dados confidenciais aos seus pods como volumes montados através do suplemento Secret Manager para o GKE. Este método é útil se não conseguir modificar o código da sua aplicação para usar as bibliotecas de cliente do Secret Manager. Para mais informações, consulte o artigo Use o suplemento Secret Manager com o Google Kubernetes Engine.

  • Ferramentas de gestão de segredos de terceiros: as ferramentas de terceiros, como o HashiCorp Vault, oferecem capacidades de gestão de segredos para cargas de trabalho do Kubernetes. Estas ferramentas requerem uma configuração inicial mais complexa do que o Secret Manager, mas são uma opção mais segura do que criar Secrets no cluster. Para configurar uma ferramenta de terceiros para a gestão de segredos, consulte a documentação do fornecedor. Além disso, considere as seguintes recomendações:

    • Se a ferramenta de terceiros for executada num cluster, use um cluster diferente do cluster que executa as suas cargas de trabalho.
    • Use o Cloud Storage ou o Spanner para armazenar os dados da ferramenta.
    • Use um Network Load Balancer de encaminhamento interno para expor a ferramenta de gestão de segredos de terceiros aos pods que são executados na sua rede VPC.

  • Usar segredos do Kubernetes (não recomendado): se nenhuma das opções anteriores for adequada para o seu exemplo de utilização, pode armazenar os dados como segredos do Kubernetes. Google Cloud Encripta os dados na camada de armazenamento por predefinição. Esta encriptação da camada de armazenamento predefinida inclui a base de dados que armazena o estado do seu cluster, que se baseia no etcd ou no Spanner. Além disso, pode encriptar estes segredos na camada de aplicação com uma chave que gere. Para mais informações, consulte o artigo Encriptar segredos na camada de aplicação.

Segurança da carga de trabalho

As secções seguintes fornecem recomendações para melhorar a segurança do cluster contra problemas de carga de trabalho. Os engenheiros de segurança e os administradores da plataforma devem aplicar estas recomendações para melhorar a proteção da infraestrutura do GKE contra cargas de trabalho.

Práticas recomendadas

Isole cargas de trabalho com o GKE Sandbox

Recomendado: use o GKE Sandbox para impedir que código malicioso afete o kernel anfitrião nos nós do cluster.

Pode executar contentores num ambiente em sandbox para mitigar a maioria dos ataques de fuga de contentores, também denominados ataques de escalada de privilégios locais. Conforme descrito nos boletins de segurança do GKE, este tipo de ataque permite que um atacante obtenha acesso à VM do anfitrião do contentor. O atacante pode usar este acesso ao anfitrião para aceder a outros contentores na mesma MV. O GKE Sandbox pode ajudar a limitar o impacto destes ataques.

Use o GKE Sandbox em cenários como os seguintes:

  • Tem cargas de trabalho que executam código não fidedigno.
  • Quer limitar o impacto se um atacante comprometer um contentor na carga de trabalho.

Para mais informações, consulte o artigo Reforce o isolamento da carga de trabalho com o GKE Sandbox.

Restrinja a capacidade de as cargas de trabalho se automodificarem

Recomendado: use controladores de admissão para impedir que as cargas de trabalho se modifiquem automaticamente ou para impedir a modificação de atributos de cargas de trabalho arriscados, como ServiceAccounts.

Determinadas cargas de trabalho do Kubernetes, especialmente cargas de trabalho do sistema, têm autorização para se automodificarem. Por exemplo, algumas cargas de trabalho são dimensionadas automaticamente na vertical. Embora seja conveniente, a automodificação pode permitir que um atacante que já tenha comprometido um nó avance ainda mais no cluster. Por exemplo, um atacante pode ter uma carga de trabalho num espaço de nomes que se altera para ser executada como uma ServiceAccount mais privilegiada no mesmo espaço de nomes.

A menos que seja necessário, não conceda autorização aos pods para se modificarem automaticamente. Se alguns pods tiverem de se modificar automaticamente, use o Policy Controller para limitar o que as cargas de trabalho podem alterar. Por exemplo, pode usar o modelo de restrição NoUpdateServiceAccount para impedir que os pods alterem a respetiva ServiceAccount. Quando cria uma política, exclua todos os componentes de gestão de clusters das suas restrições, como no exemplo seguinte:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Aplicação baseada em políticas

As secções seguintes fornecem recomendações para usar políticas para aplicar restrições de segurança em vários recursos. Os administradores de identidade e conta e os engenheiros de segurança devem aplicar estas recomendações para manter a conformidade dos clusters e das cargas de trabalho com os requisitos de segurança organizacionais.

Práticas recomendadas

Aplique políticas na Google Cloud hierarquia de recursos

Recomendado: para aplicar práticas de segurança na sua organização, pasta ou projeto, use o serviço de políticas da organização.

Com a política da organização, pode definir restrições de forma centralizada e aplicá-las a vários níveis da hierarquia de recursos. Vários Google Cloud produtos publicam restrições geridas que lhe permitem aplicar recomendações de práticas recomendadas para esse produto. Por exemplo, o GKE publica restrições geridas para muitas das práticas recomendadas neste documento.

Para mais informações sobre como ativar a política de organização, consulte o artigo Criar e gerir políticas de organização.

Aplique políticas durante a admissão de cargas de trabalho

Recomendado: use um controlador de admissão, como o controlador de políticas ou o controlador de admissão PodSecurity, para rever os pedidos de API recebidos e aplicar políticas a esses pedidos.

Os controladores de admissão interceptam pedidos autenticados e autorizados à API Kubernetes para realizar tarefas de validação ou mutação antes de permitir que um recurso persista na API.

Pode usar os seguintes métodos para o controlo de admissão em clusters do GKE:

Gestão de clusters

As secções seguintes fornecem recomendações para gerir os seus clusters ao longo do tempo, como atualizar, monitorizar e configurar registos. Os engenheiros de segurança, os administradores da plataforma e os SREs devem usar estas recomendações para manter a postura de segurança da plataforma GKE.

Práticas recomendadas

Atualize a sua infraestrutura do GKE regularmente

Recomendado: mantenha a versão do GKE atualizada para aceder a novas funcionalidades de segurança e aplicar patches de segurança. Use canais de lançamento, atualizações automáticas de patches aceleradas e atualizações automáticas de nós.

O Kubernetes e o GKE lançam frequentemente novas versões de patches que incluem melhorias de segurança e correções de vulnerabilidades. Para todos os clusters, o GKE atualiza automaticamente o plano de controlo para versões secundárias e versões de patch mais estáveis.

Para garantir que o cluster do GKE executa uma versão atualizada, faça o seguinte:

  • Inscreva os seus clusters num canal de lançamento. Os clusters do Autopilot estão sempre inscritos num canal de lançamento.
  • Para clusters que estão num canal de lançamento, ative as atualizações automáticas de patches aceleradas para receber versões de patches de segurança assim que estiverem disponíveis no seu canal de lançamento.
  • Para clusters padrão que não estão num canal de lançamento, ative as atualizações automáticas de nós. A atualização automática de nós está ativada por predefinição para clusters criados com a Google Cloud consola desde junho de 2019 e para clusters criados com a API GKE a partir de 11 de novembro de 2019.
  • Se usar políticas de manutenção, use uma janela de manutenção para permitir que o GKE atualize automaticamente os seus nós, pelo menos, uma vez por mês.
  • Para pools de nós que não usam atualizações automáticas de nós, atualize os pools de nós, pelo menos, uma vez por mês de acordo com a sua própria programação.
  • Acompanhe os boletins de segurança do GKE e as notas de lançamento do GKE para obter informações sobre patches de segurança.

Ative as notificações de boletins de segurança

Recomendado: configure as notificações para novos boletins de segurança que afetam o seu cluster.

Quando estão disponíveis boletins de segurança relevantes para o seu cluster, o GKE publica notificações sobre esses eventos como mensagens em tópicos do Pub/Sub que configurar. Pode receber estas notificações numa subscrição do Pub/Sub, integrar com serviços de terceiros e receber notificações no Cloud Logging.

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.enableSecurityBulletinNotifications restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Configure a recolha de registos

Recomendado: para reduzir os custos operacionais e manter uma vista consolidada dos seus registos, implemente uma estratégia de registo consistente nos seus clusters. Não desative a recolha de registos nos seus clusters padrão.

Os clusters do GKE enviam registos específicos para o Google Cloud Observability. Opcionalmente, pode configurar a recolha de tipos adicionais de registos. Além dos registos do sistema e da carga de trabalho, todos os clusters do GKE enviam os seguintes registos de auditoria para o Logging:

  • Registos de auditoria do Kubernetes: um registo cronológico das chamadas feitas ao servidor da API Kubernetes. As entradas do registo de auditoria do Kubernetes são úteis para investigar pedidos de API suspeitos, recolher estatísticas ou criar alertas de monitorização para chamadas de API indesejadas.
  • Registos de auditoria do GKE: um registo das atividades administrativas e de acesso para a API GKE.

Para mais informações, consulte os seguintes documentos:

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.enableCloudLogging restrição da política organizacional gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Monitorize os seus recursos relativamente a problemas de segurança

Use o painel de controlo da postura de segurança do GKE e o Security Command Center para monitorizar os seus clusters e cargas de trabalho quanto a potenciais problemas. Pode usar estes serviços para verificar vulnerabilidades, ameaças e boletins de segurança ativos que afetam a sua infraestrutura do GKE.

Configurações de segurança predefinidas

As secções seguintes descrevem as opções configuradas por predefinição em novos clusters para mitigar preocupações de segurança específicas, como vulnerabilidades ou riscos. Os engenheiros de segurança e os administradores da plataforma devem validar se os clusters existentes usam estas definições.

Práticas recomendadas

Deixe os métodos de autenticação de cliente antigos desativados

Recomendado: desative os métodos de autenticação do servidor da API antigos, como certificados estáticos e palavras-passe.

Existem vários métodos de autenticação no servidor da API Kubernetes. No GKE, os métodos suportados são tokens de portador de contas de serviço, tokens OAuth e certificados de cliente X.509. A CLI gcloud usa tokens OAuth para autenticar utilizadores para o GKE.

Os métodos de autenticação antigos, como as palavras-passe estáticas, estão desativados, porque estes métodos aumentam a superfície de ataque para compromissos de clusters. Nos clusters do Autopilot, não pode ativar nem usar estes métodos de autenticação.

Use um dos seguintes métodos para se autenticar no servidor da API Kubernetes:

  • Utilizadores: use a CLI gcloud para permitir que o GKE autentique os utilizadores, gere tokens de acesso OAuth para o cluster e mantenha os tokens atualizados.
  • Aplicações: use a Workload Identity Federation para permitir que as aplicações no Google Cloud ou noutros ambientes se autentiquem no seu cluster.

Para mais informações sobre como autenticar e desativar métodos de autenticação antigos, consulte o artigo Autentique-se no servidor da API Kubernetes.

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.disableLegacyClientCertificateIssuance restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Deixe o ABAC desativado

Recomendado: use o IAM e o RBAC para controlar o acesso no GKE. Não ative o controlo de acesso baseado em atributos (ABAC).

O ABAC é um método de autorização antigo que está desativado por predefinição em todos os clusters do GKE e não pode ser ativado em clusters do Autopilot.

Para aplicar esta recomendação na sua organização, use a constraints/container.managed.disableABAC restrição da política da organização gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

Mantenha o controlador de admissão DenyServiceExternalIPs ativado

Recomendado: não desative o controlador de admissão DenyServiceExternalIPs.

Este controlador de admissão impede que os serviços usem ExternalIPs e mitiga o problema GCP-2020-015. Este controlador de admissão está ativado por predefinição em clusters criados na versão 1.21 e posteriores do GKE. Para clusters que foram originalmente criados numa versão anterior do GKE, ative o controlador de admissão:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
Para aplicar esta recomendação na sua organização, use a constraints/container.managed.denyServiceExternalIPs restrição da política organizacional gerida. Para rever esta restrição gerida na Google Cloud consola, aceda à página Detalhes da política.

Aceder aos detalhes da política

O que se segue?