Aumentar a segurança do cluster

Neste documento, você vai conhecer as 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 essas práticas recomendadas para proteger os dados da organização.

Você já precisa conhecer:

Por padrão, os novos clusters do GKE implementam muitas das práticas recomendadas neste documento. Os clusters do modo Autopilot têm uma postura de segurança padrão mais rígida do que os do modo Standard.

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

  • Security Command Center: verifique automaticamente se os clusters implementam muitas dessas práticas recomendadas e verifique outros erros de configuração comuns.
  • Serviço de políticas da organização: aplique práticas recomendadas específicas a recursos do GKE em uma organização, pasta ou projeto. Algumas seções deste documento têm links para o console Google Cloud . Assim, você pode aplicar restrições gerenciadas a essas recomendações.

Google Cloud design de ambiente

As seções a seguir descrevem as medidas de segurança que você precisa considerar ao planejar e projetar seus recursos no Google Cloud. Os arquitetos de nuvem devem usar essas recomendações ao planejar e definir a arquitetura Google Cloud .

Práticas recomendadas

Planejar a estrutura de recursos do Google Cloud

Recomendado: implemente o blueprint de bases empresariais, que é uma base completa para seu ambiente empresarial com base nas nossas práticas recomendadas.

A arquitetura das suas Google Cloud organizações, pastas e projetos afeta sua postura de segurança. Projete esses recursos básicos de forma a permitir controles de governança e segurança em grande escala em todos os seus serviços.

Planejar ambientes multilocatários

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

Muitos clientes do GKE gerenciam equipes distribuídas, com fluxos de trabalho e responsabilidades de engenharia separados. Esses ambientes multilocatários precisam ter uma infraestrutura compartilhada que todos os desenvolvedores possam usar, restringindo o acesso aos componentes com base em funções e responsabilidades. O blueprint de aplicativos empresariais se baseia no blueprint de fundação empresarial para ajudar você a implantar plataformas de desenvolvedores internos em ambientes multilocatários.

Para mais informações, consulte estes documentos:

Usar tags para agrupar recursos Google Cloud

Recomendado: use tags para organizar recursos do GKE para aplicação condicional de políticas e melhor responsabilização em todas as equipes.

As tags são metadados que podem ser anexados a recursos nas suas organizações, pastas e projetos para identificar dimensões de negócios naGoogle Cloud hierarquia de recursos. É possível anexar tags a clusters e pools de nós do GKE e usar essas tags para aplicar condicionalmente políticas da organização, do IAM ou de firewall.

Para mais informações, consulte estes documentos:

Planejar suas redes VPC

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

O design da rede VPC e os recursos usados afetam a segurança da rede. Planeje suas redes com base na hierarquia de recursos e nos objetivos de segurança do Google Cloud. Para mais informações, consulte os documentos a seguir:

Criar um plano de resposta a incidentes

Recomendado: crie e mantenha um plano de resposta a incidentes que atenda às suas metas de segurança e confiabilidade.

Incidentes de segurança podem ocorrer mesmo quando você implementa todos os controles de segurança possíveis. Um plano de resposta a incidentes ajuda a identificar possíveis lacunas nos controles de segurança, responder de forma rápida e eficaz a vários tipos de incidentes e reduzir o tempo de inatividade durante uma interrupção. Confira mais informações nestes documentos:

Google Cloud segurança de rede

As seções a seguir oferecem recomendações de segurança para suas redes VPC. Arquitetos e administradores de rede precisam aplicar essas recomendações para reduzir a superfície de ataque no nível da rede e limitar o impacto do acesso não intencional.

Práticas recomendadas

Usar regras de firewall de privilégio mínimo

Recomendado: ao criar regras de firewall, use o princípio do menor privilégio para fornecer acesso apenas à finalidade necessária. Verifique, quando possível, se as regras de firewall não entram em conflito com as regras padrão do GKE nem as substituem.

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

Usar a VPC compartilhada para tráfego entre projetos

Recomendado: use a VPC compartilhada para permitir que recursos em vários projetos se comuniquem usando endereços IP internos.

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

Para mais informações, consulte estes documentos:

Use redes separadas para isolar ambientes

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

Isole seus ambientes de desenvolvimento para reduzir o impacto e o risco de acesso não autorizado ou bugs disruptivos. Para mais informações, consulte Vários projetos host.

Configurações de segurança imutáveis

As seções a seguir fornecem recomendações de segurança que podem ser configuradas somente ao criar clusters ou pools de nós. Não é possível atualizar clusters ou pools de nós atuais para mudar essas configurações. Os administradores da plataforma precisam aplicar essas recomendações a novos clusters e pools de nós.

Usar contas de serviço do nó do IAM com privilégios mínimos

Recomendado: use uma conta de serviço personalizada do IAM para seus clusters do GKE e pools de nós em vez da conta de serviço padrão do Compute Engine.

O GKE usa contas de serviço do IAM anexadas aos nós para executar tarefas do sistema, como geração de registros e monitoramento. No mínimo, essas contas de serviço de nó precisam ter o papel Conta de serviço de nó padrão do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por padrão, o GKE usa a conta de serviço padrão do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.

Se você usar a conta de serviço padrão do Compute Engine para outras funções no projeto ou na organização, ela poderá ter mais permissões do que o GKE precisa, o que pode expor você a riscos de segurança.

A conta de serviço anexada aos nós só deve ser usada por cargas de trabalho do sistema que realizam tarefas como geração de registros e monitoramento. Para suas próprias cargas de trabalho, provisione identidades usando a federação de identidade da carga de trabalho para GKE.

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.disallowDefaultComputeServiceAccount restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Usar uma imagem de nó do Container-Optimized OS

Recomendado: a menos que você tenha um requisito específico para usar o Ubuntu ou o Windows, use a imagem do nó do Container-Optimized OS para seus nós.

O Container-Optimized OS é criado, otimizado e reforçado especificamente para executar contêineres. O Container-Optimized OS é a única imagem de nó compatível com o modo Autopilot e é a imagem de nó padrão para o modo Standard.

Para mais informações, consulte estes documentos:

Configuração de segurança do nó

As seções a seguir fornecem recomendações de segurança para a configuração de nós do GKE. Os administradores da plataforma e os engenheiros de segurança precisam aplicar essas recomendações para melhorar a integridade dos nós do GKE.

Práticas recomendadas

Usar nós do GKE protegidos

Recomendado: ative os nós protegidos do GKE, a inicialização segura e o monitoramento de integridade em todos os clusters e pools de nós.

Os nós protegidos do GKE oferecem verificações de integridade e identidade verificáveis que melhoram a segurança dos seus nós. Os nós protegidos do GKE e recursos como monitoramento de integridade do nó e inicialização segura estão sempre ativados nos clusters do Autopilot. Em clusters padrão, faça o seguinte:

  • Não desative os nós protegidos do GKE nos clusters.
  • Ative a inicialização segura em todos os seus pools de nós.
  • Não desative o monitoramento de integridade nos seus pools de nós.

Para mais informações sobre como ativar esses recursos, consulte Como usar nós protegidos do GKE.

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.enableShieldedNodes restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Desativar a porta somente leitura do kubelet não segura

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

O processo kubelet em execução nos nós disponibiliza uma API somente leitura usando a porta não segura 10255. O Kubernetes não realiza nenhuma verificação de autenticação ou autorização nessa porta. O kubelet serve aos mesmos endpoints na porta 10250 mais segura e autenticada.

Para mais informações, consulte Desativar a porta somente leitura do kubelet em clusters do GKE.

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.disableInsecureKubeletReadOnlyPort restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Controle de acesso

As seções a seguir fornecem recomendações para restringir o acesso não autorizado no cluster. Os engenheiros de segurança e os administradores de identidade e conta precisam aplicar essas recomendações para reduzir a superfície de ataque e limitar o impacto do acesso não autorizado.

Práticas recomendadas

Restringir o acesso à descoberta de APIs do cluster

Recomendado: restrinja o acesso ao plano de controle e aos nós da Internet para evitar o acesso não intencional aos endpoints de descoberta de APIs do cluster.

Por padrão, o Kubernetes cria clusters com um conjunto permissivo de papéis padrão de descoberta de API. Essas funções padrão dão amplo acesso a informações sobre as APIs de um cluster para vários grupos padrão, como system:authenticated. Essas funções padrão não representam um nível significativo de segurança para clusters do GKE. Por exemplo, o grupo system:authenticated, que pode ler informações sobre APIs como CustomResources, é atribuído a qualquer usuário autenticado, incluindo quem tem uma Conta do Google.

Para restringir o acesso às APIs de descoberta de cluster, faça o seguinte:

  • Restrinja o acesso ao plano de controle: use apenas o endpoint baseado em DNS para acessar o plano de controle. Se você usar endpoints baseados em IP, restrinja o acesso a um conjunto de intervalos de endereços conhecidos configurando redes autorizadas.
  • Configure nós particulares: desative os endereços IP externo dos seus nós para que clientes fora da sua rede não possam acessá-los.

Para mais informações, consulte Sobre o isolamento de rede.

Se você não ativar esses recursos de isolamento de rede, trate todas as informações de descoberta de API (especialmente o esquema de CustomResources, definições de APIService e informações de descoberta hospedadas pelos servidores da API de extensão) como divulgadas publicamente.

Coloque equipes e ambientes em namespaces ou clusters separados

Conceda às equipes acesso de privilégio mínimo ao Kubernetes criando namespaces ou clusters separados para cada equipe e ambiente. Para cada namespace ou cluster, atribua centros de custo e rótulos para responsabilidade e estorno.

É possível usar as permissões do IAM e do RBAC juntas com namespaces para restringir interações de usuários com recursos de cluster no console Google Cloud . Saiba mais em Ativar acesso e visualização de recursos do cluster por namespace.

Usar o princípio de privilégio mínimo em políticas de acesso

Recomendado: conceda aos desenvolvedores apenas o acesso necessário para implantar e gerenciar aplicativos no namespace deles, especialmente em ambientes de produção. Ao criar políticas de controle de acesso, mapeie as tarefas que os usuários precisam realizar no cluster e conceda apenas as permissões necessárias para isso.

No GKE, é possível usar o IAM e o controle de acesso baseado em papéis (RBAC) do Kubernetes para conceder permissões aos recursos. Esses mecanismos de controle de acesso funcionam juntos. Para reduzir a complexidade do gerenciamento de acesso, faça o seguinte:

  • Para dar acesso ao seu projeto ou aos recursos do Google Cloud , use papéis do IAM.

  • Para dar acesso a recursos do Kubernetes no seu cluster, como namespaces, use o RBAC.

Para mais informações sobre o planejamento e a criação de políticas do IAM e do RBAC, consulte os documentos a seguir:

Usar a federação de identidade da carga de trabalho para GKE para acessar as APIs Google Cloud

Recomendado: para acessar recursos do Google Cloud nas cargas de trabalho do GKE, use a Federação de Identidade da Carga de Trabalho para GKE.

A federação de identidade da carga de trabalho do GKE é a maneira recomendada de autenticação nas APIsGoogle Cloud . É possível conceder papéis do IAM em vários recursos a principais no cluster, como ServiceAccounts ou pods específicos do Kubernetes. A federação de identidade da carga de trabalho do GKE também protege metadados sensíveis nos seus nós e oferece um fluxo de trabalho de autenticação mais seguro do que alternativas como arquivos de token estáticos.

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

  • Se você usa bibliotecas de cliente Google Cloud no código do aplicativo, não distribua credenciais Google Cloud para suas cargas de trabalho. O código que usa bibliotecas de cliente recupera automaticamente as credenciais da federação de identidade da carga de trabalho para o GKE.
  • Use um namespace e uma ServiceAccount separados para cada carga de trabalho que precise de uma identidade distinta. Conceda permissões do IAM a contas de serviço específicas.

Para mais informações, consulte Autenticar nas APIs do Google Cloud com cargas de trabalho do GKE.

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.enableWorkloadIdentityFederation restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Usar grupos para gerenciar o acesso

Recomendado: nas políticas de acesso, conceda permissões a grupos de usuários em vez de indivíduos.

Ao gerenciar usuários em grupos, seu sistema de gerenciamento de identidades e os administradores de identidade podem controlar as identidades de maneira centralizada modificando a associação de usuários em vários grupos. Esse tipo de gerenciamento dispensa a necessidade de atualizar as políticas de RBAC ou do IAM sempre que um usuário específico precisar de permissões atualizadas.

É possível especificar os Grupos do Google nas políticas do IAM ou de RBAC. Para mais informações, consulte estes documentos:

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.enableGoogleGroupsRBAC restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Restringir o acesso anônimo aos endpoints do cluster

Recomendado: impeça solicitações anônimas para todos os endpoints do cluster, exceto os de verificação de integridade, em todos os clusters do Autopilot e do Standard.

Por padrão, o Kubernetes atribui o usuário system:anonymous e o grupo system:unauthenticated a solicitações anônimas para endpoints de cluster. Se as políticas de RBAC concederem permissões adicionais a esse usuário ou grupo, um usuário anônimo poderá comprometer a segurança de um serviço ou do próprio cluster.

No GKE versão 1.32.2-gke.1234000 e mais recente, é possível limitar o conjunto de endpoints que as solicitações anônimas podem alcançar apenas aos endpoints de verificação de integridade do servidor da API Kubernetes /healthz, /livez e /readyz. O acesso anônimo a esses endpoints de verificação de integridade é necessário para verificar se um cluster está funcionando corretamente.

Para limitar o acesso anônimo aos endpoints do cluster, especifique LIMITED para a flag --anonymous-authentication-config ao usar a CLI gcloud ou a API GKE para criar ou atualizar clusters Standard e Autopilot. O GKE rejeita solicitações anônimas para endpoints de cluster que não são os endpoints de verificação de integridade durante a autenticação. As solicitações anônimas não chegam aos endpoints, mesmo que as políticas de RBAC concedam acesso a usuários e grupos anônimos. As solicitações rejeitadas retornam um status HTTP de 401.

Para aplicar essa recomendação na sua organização, pasta ou projeto usando 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 Restringir ações em recursos do GKE usando políticas personalizadas da organização.

Não confie apenas nesse recurso para proteger seu cluster. Implemente outras medidas de segurança, como:

Segurança de rede do GKE

As seções a seguir fornecem recomendações para melhorar a segurança de rede nos seus clusters. Os administradores de rede e engenheiros de segurança precisam aplicar essas recomendações para proteger cargas de trabalho e infraestrutura contra acesso externo ou interno não intencional.

Práticas recomendadas

Restringir o acesso ao plano de controle

Recomendado: ative o endpoint baseado em DNS para acesso ao plano de controle e desative todos os endpoints baseados em IP.

Por padrão, entidades externas, como clientes na Internet, podem acessar seu plano de controle. É possível restringir quem pode acessar seu plano de controle configurando o isolamento de rede.

Para isolar o plano de controle, faça o seguinte:

  • Use apenas o endpoint baseado em DNS (recomendado): ative o endpoint baseado em DNS para o plano de controle e desative os endpoints internos e externos baseados em IP. Todo o acesso ao plano de controle precisa usar o endpoint baseado em DNS. É possível usar o VPC Service Controls para controlar quem pode acessar o endpoint baseado em DNS.

    Para aplicar essa recomendação na sua organização, use a constraints/container.managed.enableControlPlaneDNSOnlyAccess restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

    Acessar "Detalhes da política"

  • Desative o endpoint externo baseado em IP: remova o endereço IP externo do plano de controle. Clientes fora da sua rede VPC não podem usar o endereço IP externo para acessar o plano de controle.

    Essa opção funciona bem se você usa tecnologias como o Cloud Interconnect e o Cloud VPN para conectar a rede da empresa à rede VPC.

  • Use redes autorizadas com o endpoint baseado em IP externo: restrinja o acesso ao endpoint baseado em IP externo a um intervalo confiável de endereços IP de origem.

    Essa opção funciona bem se você não tem uma infraestrutura de VPN ou se tem usuários remotos ou filiais que acessam seus clusters pela Internet pública.

Na maioria dos cenários, use apenas o endpoint baseado em DNS para acesso ao plano de controle. Se você precisar ativar o endpoint baseado em IP, use redes autorizadas para limitar o acesso do plano de controle às seguintes entidades:

  • Os intervalos de endereços IP especificados por você.
  • Nós do GKE na mesma rede VPC que o cluster.
  • Endereços IP reservados pelo Google para fins de gerenciamento de cluster.

Isolar os nós da Internet

Por padrão, todos os nós do GKE têm um endereço IP externo que pode ser acessado por clientes na Internet. Para remover esse endereço IP externo, ative os nós particulares.

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.enablePrivateNodes restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Restringir o tráfego de rede entre pods

Recomendado: controle o tráfego de rede entre pods usando NetworkPolicies, uma malha de serviço ou ambos.

Por padrão, todos os pods no cluster podem se comunicar entre si. Restringir o acesso à rede entre os serviços dificulta muito a movimentação lateral dos invasores no cluster. Seus serviços também ganham alguma proteção contra incidentes de negação de serviço acidentais ou deliberados. Dependendo dos seus requisitos, use um ou ambos os métodos a seguir para restringir o tráfego de pod para pod:

Proteção de dados sensíveis

As seções a seguir oferecem recomendações para criptografar dados e proteger informações sensíveis, como credenciais. Os engenheiros de segurança e administradores de plataforma precisam aplicar essas recomendações para reduzir o risco de acesso não intencional a dados críticos.

Práticas recomendadas

Criptografar dados da carga de trabalho em uso

Use a criptografia de memória baseada em hardware para proteger os dados em uso pelas cargas de trabalho com os nós confidenciais do GKE. Você pode escolher uma tecnologia de computação confidencial com base nos seus requisitos. Para mais informações, consulte Criptografar dados da carga de trabalho em uso com Confidential GKE Nodes.

Armazenar secrets fora do cluster

Recomendado: use um gerenciador de secrets externo, como o Secret Manager, para armazenar dados sensíveis, como chaves de API, fora do cluster.

No Kubernetes, é possível armazenar dados sensíveis em secrets no cluster. É possível usar Secrets para fornecer dados confidenciais a aplicativos sem incluir esses dados no código do aplicativo. No entanto, armazenar esses dados no cluster tem riscos como os seguintes:

  • Qualquer pessoa que possa criar pods em um namespace pode ler os dados de qualquer secret nesse namespace.
  • Qualquer pessoa com acesso de leitura a todos os objetos da API do Kubernetes usando RBAC ou IAM pode ler secrets.

Devido a esses riscos, crie secrets no cluster somente quando não for possível fornecer esses dados às cargas de trabalho de outra forma. Recomendamos os seguintes métodos, em ordem de preferência, para armazenar e acessar seus dados sensíveis:

  • Bibliotecas de cliente do Secret Manager: acesse secrets de maneira programática no código do aplicativo usando a API Secret Manager com a federação de identidade da carga de trabalho do GKE. Para mais informações, consulte Acessar secrets armazenados fora dos clusters do GKE usando bibliotecas de cliente.
  • Dados do Secret Manager como volumes ativados: forneça dados sensíveis aos seus pods como volumes ativados usando o complemento do Secret Manager para GKE. Esse método é útil se você não puder modificar o código do aplicativo para usar as bibliotecas de cliente do Secret Manager. Para mais informações, consulte Usar o complemento do Secret Manager com o Google Kubernetes Engine.

  • Ferramentas de gerenciamento de secrets de terceiros: ferramentas de terceiros, como o HashiCorp Vault, oferecem recursos de gerenciamento de secrets para cargas de trabalho do Kubernetes. Essas ferramentas exigem mais configuração inicial 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 gerenciamento de secrets, consulte a documentação do provedor. Além disso, considere as seguintes recomendações:

    • Se a ferramenta de terceiros for executada em um cluster, use um cluster diferente daquele que executa suas cargas de trabalho.
    • Use o Cloud Storage ou o Spanner para armazenar os dados da ferramenta.
    • Use um balanceador de carga de rede de passagem interno para expor a ferramenta de gerenciamento de secrets de terceiros a pods que são executados na sua rede VPC.

  • Usar secrets do Kubernetes (não recomendado): se nenhuma das opções anteriores for adequada para seu caso de uso, armazene os dados como secrets do Kubernetes. OGoogle Cloud criptografa dados na camada de armazenamento por padrão. Essa criptografia padrão da camada de armazenamento inclui o banco de dados que armazena o estado do cluster, que é baseado em etcd ou Spanner. Além disso, é possível criptografar esses secrets na camada de aplicativo com uma chave gerenciada. Para mais informações, consulte Criptografar secrets na camada do aplicativo.

Segurança de cargas de trabalho

As seções a seguir fornecem recomendações para melhorar a segurança do cluster contra problemas de carga de trabalho. Engenheiros de segurança e administradores de plataforma precisam aplicar essas recomendações para melhorar a proteção da infraestrutura do GKE contra cargas de trabalho.

Práticas recomendadas

Isolar cargas de trabalho usando o GKE Sandbox

Recomendado: use o GKE Sandbox para evitar que códigos maliciosos afetem o kernel do host nos nós do cluster.

É possível executar contêineres em um ambiente sandbox para reduzir a maioria dos ataques de escape, também chamados de ataques de escalonamento de privilégios locais. Conforme descrito nos boletins de segurança do GKE, esse tipo de ataque permite que um invasor tenha acesso à VM host do contêiner. O invasor pode usar esse acesso para acessar outros contêineres na mesma VM. O GKE Sandbox pode ajudar a limitar o impacto desses ataques.

Use o GKE Sandbox em cenários como estes:

  • Você tem cargas de trabalho que executam código não confiável.
  • Você quer limitar o impacto se um invasor comprometer um contêiner na carga de trabalho.

Para mais informações, consulte Aumentar a proteção do isolamento da carga de trabalho com o GKE Sandbox.

Restringir a capacidade de automodificação das cargas de trabalho

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

Certas cargas de trabalho do Kubernetes, principalmente as cargas de trabalho do sistema, têm permissão para se automodificar. Por exemplo, algumas cargas de trabalho escalonam automaticamente na vertical. Embora seja conveniente, a automodificação pode permitir que um invasor que já tenha comprometido um nó escalone ainda mais no cluster. Por exemplo, um invasor pode fazer com que uma carga de trabalho em um namespace se automodifique para ser executada como uma ServiceAccount com mais privilégios no mesmo namespace.

A menos que seja necessário, não conceda aos pods permissão para se modificarem. Se alguns pods precisarem se automodificar, use o Policy Controller para limitar o que as cargas de trabalho podem mudar. Por exemplo, é possível usar o modelo de restrição NoUpdateServiceAccount para impedir que os pods mudem a conta de serviço. Ao criar uma política, exclua todos os componentes de gerenciamento de cluster das suas restrições, como no exemplo a seguir:

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

Aplicação com base em políticas

As seções a seguir fornecem recomendações para usar políticas e aplicar restrições de segurança em vários recursos. Os administradores de identidade e conta e os engenheiros de segurança precisam aplicar essas recomendações para manter a conformidade de clusters e cargas de trabalho com os requisitos de segurança da organização.

Práticas recomendadas

Aplicar políticas em toda a 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, é possível definir restrições de maneira centralizada e aplicá-las em vários níveis da hierarquia de recursos. Vários produtos do Google Cloud publicam restrições gerenciadas que permitem aplicar recomendações de práticas recomendadas para esse produto. Por exemplo, o GKE publica restrições gerenciadas para muitas das práticas recomendadas neste documento.

Para mais informações sobre como ativar a política da organização, consulte Como criar e gerenciar políticas da organização.

Aplicar políticas durante a admissão de carga de trabalho

Recomendado: use um controlador de admissão, como o Controlador de Políticas ou o controlador de admissão do PodSecurity, para analisar as solicitações de API recebidas e aplicar políticas a essas solicitações.

Os controladores de admissão interceptam solicitações autenticadas e autorizadas à API Kubernetes para realizar tarefas de validação ou mutação antes de permitir que um recurso persista na API.

É possível usar os seguintes métodos para controle de admissão em clusters do GKE:

Gerenciamento de clusters

As seções a seguir fornecem recomendações para gerenciar seus clusters ao longo do tempo, como upgrade, monitoramento e configuração de registros. Engenheiros de segurança, administradores de plataforma e SREs precisam usar essas recomendações para manter a postura de segurança da plataforma GKE.

Práticas recomendadas

Faça upgrade da sua infraestrutura do GKE regularmente

Recomendado: mantenha sua versão do GKE atualizada para acessar novos recursos de segurança e aplicar patches de segurança. Use canais de lançamento, upgrades automáticos de patch acelerados e upgrades automáticos de nós.

O Kubernetes e o GKE lançam com frequência novas versões de patch que incluem melhorias de segurança e correções de vulnerabilidades. Para todos os clusters, o GKE faz upgrade automático do plano de controle para versões secundárias e de patch mais estáveis.

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

  • Registre seus clusters em um canal de lançamento. Os clusters do Autopilot estão sempre registrados em um canal de lançamento.
  • Para clusters em um canal de lançamento, ative os upgrades automáticos acelerados de patch para receber versões de patch de segurança assim que elas estiverem disponíveis no seu canal de lançamento.
  • Para clusters Standard que não estão em um canal de lançamento, ative os upgrades automáticos de nós. O upgrade automático de nós é ativado por padrão para clusters criados com o consoleGoogle Cloud desde junho de 2019 e para clusters criados com a API GKE a partir de 11 de novembro de 2019.
  • Se você usa políticas de manutenção, use uma janela de manutenção para permitir que o GKE faça upgrade automático dos nós pelo menos uma vez por mês.
  • Para pools de nós que não usam upgrades automáticos, faça o upgrade pelo menos uma vez por mês de acordo com sua programação.
  • Acompanhe os boletins de segurança do GKE e as notas da versão do GKE para informações sobre patches de segurança.

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

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

Quando os boletins de segurança estão disponíveis e são relevantes para o cluster, o GKE publica notificações sobre esses eventos como mensagens para tópicos do Pub/Sub que você configura. Você pode receber essas notificações em uma assinatura do Pub/Sub, fazer a integração com serviços de terceiros e receber notificações no Cloud Logging.

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.enableSecurityBulletinNotifications restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Configurar a coleta de registros

Recomendado: para reduzir a sobrecarga operacional e manter uma visualização consolidada dos registros, implemente uma estratégia de registro consistente em todos os clusters. Não desative a coleta de registros nos clusters Standard.

Os clusters do GKE enviam registros específicos ao Google Cloud Observability. Você também pode configurar a coleta de outros tipos de registros. Além dos registros do sistema e de cargas de trabalho, todos os clusters do GKE enviam os seguintes registros de auditoria para o Logging:

  • Registros de auditoria do Kubernetes: um registro cronológico das chamadas feitas ao servidor da API Kubernetes. As entradas de registro de auditoria do Kubernetes são úteis para investigar solicitações de API suspeitas, coletar estatísticas ou criar alertas de monitoramento para chamadas de API indesejadas.
  • Registros de auditoria do GKE: um registro de atividades administrativas e de acesso para a API GKE.

Para mais informações, consulte estes documentos:

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.enableCloudLogging restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Monitore seus recursos para detectar problemas de segurança

Use o painel de postura de segurança do GKE e o Security Command Center para monitorar seus clusters e cargas de trabalho em busca de possíveis problemas. É possível usar esses serviços para verificar vulnerabilidades, ameaças e boletins de segurança ativos que afetam sua infraestrutura do GKE.

Configurações de segurança padrão

As seções a seguir descrevem opções que são configuradas por padrão em novos clusters para reduzir problemas de segurança específicos, como vulnerabilidades ou riscos. Os engenheiros de segurança e administradores de plataforma precisam validar se os clusters atuais usam essas configurações.

Práticas recomendadas

Deixar os métodos de autenticação do cliente legado desativados

Recomendado: desative métodos legados de autenticação do servidor de API, como certificados estáticos e senhas.

Há vários métodos de autenticação no servidor da API Kubernetes. No GKE, os métodos compatíveis são tokens do portador da conta de serviço, tokens OAuth e certificados do cliente X.509. A CLI gcloud usa tokens OAuth para autenticar usuários no GKE.

Os métodos de autenticação legados, como senhas estáticas, são desativados porque aumentam a superfície de ataque para comprometimento do cluster. Em clusters do Autopilot, não é possível ativar ou usar esses métodos de autenticação.

Use um dos seguintes métodos para fazer a autenticação no servidor da API Kubernetes:

  • Usuários: use a CLI gcloud para permitir que o GKE autentique usuários, gere tokens de acesso OAuth para o cluster e mantenha os tokens atualizados.
  • Aplicativos: use a federação de identidade da carga de trabalho para permitir que aplicativos em Google Cloud ou em outros ambientes se autentiquem no cluster.

Para mais informações sobre como autenticar e desativar métodos de autenticação legados, consulte Autenticar no servidor da API Kubernetes.

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.disableLegacyClientCertificateIssuance restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Sair do ABAC desativado

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

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

Para aplicar essa recomendação na sua organização, use a constraints/container.managed.disableABAC restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

Deixar o controlador de admissão DenyServiceExternalIPs ativado

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

Esse controlador de admissão impede que os serviços usem ExternalIPs e mitiga GCP-2020-015. Esse controlador de admissão é ativado por padrão em clusters criados no GKE versão 1.21 e mais recente. Para clusters criados originalmente em uma 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 essa recomendação na sua organização, use a constraints/container.managed.denyServiceExternalIPs restrição gerenciada da política da organização. Para analisar essa restrição gerenciada no console do Google Cloud , acesse a página Detalhes da política.

Acessar "Detalhes da política"

A seguir