Recursos de segurança do Autopilot do GKE


Nesta página, descrevemos os recursos e as configurações de segurança no Autopilot do Google Kubernetes Engine (GKE), que é a maneira recomendada de executar o GKE.

Quem deve usar esta página?

Esta página é destinada a administradores de segurança que querem entender as restrições de segurança que o Google aplica especificamente aos clusters do Autopilot e os recursos de segurança disponíveis para uso no Autopilot.

Leia também a Visão geral de segurança do GKE, que descreve as opções de aumento de proteção, as medidas e as recomendações que se aplicam a todos os clusters do GKE, configurações de rede e cargas de trabalho.

Medidas de segurança no Autopilot

Por padrão, os clusters do Autopilot ativam e aplicam práticas recomendadas e configurações de segurança, incluindo muitas das recomendações na visão geral de segurança e em Como aumentar a segurança do cluster.

Se você quiser recursos recomendados com base no seu caso de uso, pule para Recursos de segurança por caso de uso. As seções a seguir descrevem as políticas de segurança que o Autopilot aplica a você.

Autopilot e os padrões de segurança de pods do Kubernetes

O projeto do Kubernetes tem um conjunto de diretrizes de segurança chamado Padrões de segurança de pods que definem as seguintes políticas:

  • Privilegiado: nenhuma restrição de acesso. Não usado no Autopilot.
  • Valor de referência: impede caminhos de escalonamento de privilégios conhecidos. Permite que a maioria das cargas de trabalho seja executada sem alterações significativas.
  • Restrito: tem o nível mais alto de segurança. Requer alterações significativas para a maioria das cargas de trabalho.

O Autopilot aplica a política de referência com algumas modificações para usabilidade. O Autopilot também aplica muitas restrições da política restrita, mas evita restrições que impedem a execução da maioria das suas cargas de trabalho. O Autopilot aplica essas restrições no nível do cluster usando um controlador de admissão controlado pelo Google. Se você precisar aplicar outras restrições para obedecer à política de restrição total, use o controlador de admissão do PodSecurity em namespaces específicos.

A tabela a seguir descreve como os clusters do Autopilot implementam as políticas de referência e restritas. Para descrições de cada controle nesta tabela, consulte a entrada correspondente em Padrões de segurança do pod.

Ao avaliar a conformidade, consideramos como as restrições se aplicam às suas próprias cargas de trabalho. Isso exclui cargas de trabalho verificadas do Google Cloud Partner e do sistema que exigem privilégios específicos para funcionar.

Controle Conformidade com a política de referência Conformidade com a política restrita Mais informações
HostProcess O Autopilot bloqueia o HostProcess.
Namespaces do host O Autopilot bloqueia os namespaces do host. Alguns contêineres de parceiros verificados podem usar namespaces de host.
Contêineres privilegiados O Autopilot bloqueia contêineres privilegiados por padrão. O Autopilot permite contêineres privilegiados de parceiros verificados para fins como executar ferramentas de segurança e monitoramento.
Recursos do Linux

As cargas de trabalho do Autopilot só podem acessar os recursos especificados no padrão de segurança de pods de base por padrão.

É possível ativar manualmente as seguintes capabilities:

  • NET_RAW para ping e SYS_PTRACE para depuração: adicionar ao SecurityContext do pod
  • NET_ADMIN para malhas de serviço como o Istio: especifique --workload-policies=allow-net-admin no comando de criação do cluster. Disponível em clusters existentes atualizados e novos que executam o GKE versão 1.27 e posterior.

O Autopilot também permite que algumas cargas de trabalho verificadas do parceiro definam capabilities descartadas.

Volumes do HostPath Conformidade parcial Conformidade parcial O Autopilot permite que os contêineres solicitem acesso somente leitura a /var/log para depuração, mas nega todos os outros acessos de leitura ou gravação.
Portas do host Definir portas de host específicas não é permitido, o que atenua alguns problemas de programação e impede a exposição acidental ou deliberada da rede de serviços. É possível configurar manualmente a atribuição aleatória de portas de host de um intervalo conhecido para dar suporte a aplicativos de rede de conexão direta, como servidores de jogos.
AppArmor O perfil de segurança docker-default do AppArmor é aplicado automaticamente ao Container-Optimized OS.
SELinux O SELinux não foi aplicado porque o AppArmor já foi. O SELinux também não é obrigatório nos Padrões de segurança de pods.
/proc tipo de montagem O GKE não define a sinalização de recurso do ProcMountType. Se o securityContext do pod definir procMount como "Unmasked", o GKE o modificará automaticamente para "Default".
perfil seccomp O Autopilot aplica o perfil seccomp RuntimeDefault a todas as cargas de trabalho. É possível modificar manualmente essa configuração para cargas de trabalho específicas definindo o perfil como Unconfined na especificação do pod.
sysctls O GKE não define a flag --allowed-unsafe-sysctls kubelet para que os pods com sysctls não seguros não programem. Para proteção adicional, a partir de 11 de julho de 2023, os novos clusters 1.27+ também têm uma regra de política para aplicar as configurações de securityContext e rejeitar pods que usam sysctls não seguros.
Tipos de volume O Autopilot permite apenas os tipos de volume na política Restrita com as seguintes adições: volumes HostPath com acesso somente leitura a /var/log para depuração, gcePersistentDisk para discos permanentes do Compute Engine e nfs para volumes do sistema de arquivos de rede.
Escalonamento de privilégios Essa configuração fornece proteção apenas para contêineres que não estão sendo executados como raiz. Pesquisas do setor mostram que 76% dos contêineres são executados como root, portanto, o Autopilot permite a execução como root para permitir a maioria das cargas de trabalho. Essa configuração também é atualmente útil para desprivilegiar cargas de trabalho para não raiz, permitindo o uso de recursos do sistema de arquivos para solucionar dificuldades com o processamento de recursos raiz do Kubernetes.
Executar como não raiz Pesquisas do setor mostram que 76% dos contêineres são executados como root, portanto, o Autopilot permite a execução como root para permitir a maioria das cargas de trabalho.
Executar como usuário não raiz Os contêineres podem definir runAsUser como 0. Pesquisas do setor mostram que 76% dos contêineres são executados como root, portanto, o Autopilot permite a execução como root para permitir a maioria das cargas de trabalho.

Configurações de segurança integradas

O Google aplica muitas configurações de segurança integradas aos clusters do Autopilot com base nas práticas recomendadas do setor e em nossa experiência. A tabela a seguir descreve algumas das configurações de segurança que o Autopilot aplica:

Configuração Descrição
Opções de host
Recursos do Linux

É possível usar os seguintes recursos do Linux:


"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE"

Também é possível ativar manualmente as seguintes capabilities:

  • NET_RAW para ping: adicionar ao SecurityContext do pod.
  • SYS_PTRACE para depuração: adicionar ao SecurityContext do pod.
  • NET_ADMIN para malhas de serviço como o Istio: use --workload-policies=allow-net-admin ao criar um cluster ou atualizar um cluster existente. Depois disso, adicione a capability ao SecurityContext do pod. Disponível no GKE versão 1.27 e posterior.

Nas versões do GKE anteriores à 1.21, não há suporte para o recurso "SYS_PTRACE".

Contêineres privilegiados Os contêineres não podem ser executados no modo Privilegiado, a menos que o contêiner seja implantado por um parceiro do Google Cloud. Os contêineres privilegiados podem fazer alterações no nó subjacente, como a alteração do kubelet. Esse acesso pode aumentar o impacto no comprometimento de um pod.
Namespaces gerenciados pelo GKE Como medida de segurança, o Autopilot não permite implantar cargas de trabalho em namespaces gerenciados pelo GKE, como kube-system.
Isolamento de contêineres

O Autopilot aplica as seguintes restrições aos contêineres para limitar o impacto das vulnerabilidades de escape de contêiner.

Segurança do kernel e capabilities do Linux

  • O Autopilot aplica o perfil seccomp RuntimeDefault a todos os pods no cluster, a menos que os pods usem o GKE Sandbox. O GKE Sandbox impõe o isolamento de host e ignora as regras seccomp especificadas no manifesto do pod. O sandbox é considerado o limite de segurança dos pods do GKE Sandbox.
  • O Autopilot descarta o recurso Linux CAP_NET_RAW para todos os contêineres. Essa permissão não é usada com frequência e está sujeita a várias vulnerabilidades de escape. O comando ping pode falhar nos seus contêineres porque esse recurso é descartado. É possível reativar essa capability manualmente ao defini-la no SecurityContext do pod.
  • O Autopilot descarta o recurso Linux CAP_NET_ADMIN para todos os contêineres. Para reativar essa capability, especifique a flag --workload-policies=allow-net-admin no comando de criação ou atualização do cluster. NET_ADMIN é necessário para algumas cargas de trabalho como Istio.
  • O Autopilot ativa a federação de identidade da carga de trabalho do GKE, o que impede o acesso do pod a metadados sensíveis no nó.
  • O Autopilot bloqueia os Serviços do Kubernetes que definem o campo spec.externalIPs para proteção contra CVE-2020-8554.
  • O Autopilot permite apenas os seguintes tipos de volumes:

    
    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk",
      "nfs", "persistentVolumeClaim", "projected", "secret"

    Outros tipos de volumes estão bloqueados porque exigem privilégios de nó. Os volumes do HostPath são bloqueados por padrão, mas os contêineres podem solicitar acesso somente leitura aos caminhos /var/log para depuração.

Aplicação da política de segurança no nível do pod O Autopilot é compatível com mecanismos de aplicação para políticas de segurança no nível do pod, como o controlador de admissão PodSecurity, Gatekeeper ou Policy Controller. No entanto, talvez não seja necessário usar nenhum deles se as configurações de segurança integradas descritas nesta página já atenderem aos seus requisitos.
SSH para nós

O Autopilot bloqueia o acesso SSH aos nós. O GKE manipula todos os aspectos operacionais dos nós, incluindo a integridade do nó e todos os componentes do Kubernetes em execução nos nós.

Ainda é possível se conectar remotamente aos seus contêineres em execução usando a funcionalidade exec do Kubernetes para executar comandos nos contêineres para depuração, incluindo a conexão a um shell interativo, por exemplo, com kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.

Personificação do usuário A versão 1.22.4-gke.1501 e mais recente do GKE oferece suporte à representação do usuário para todos os usuários e grupos definidos pelo usuário. Usuários e grupos do sistema, como o usuário kube-apiserver e o grupo system:masters, não podem ser representados.
Como mutar os webhooks de admissão dinâmica

O Autopilot modifica os webhooks de mutação para impedir que recursos em namespaces gerenciados, como kube-system, sejam interceptados.

O Autopilot também rejeita webhooks que especificam um ou mais dos seguintes recursos e quaisquer sub-recursos desses recursos.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Não é possível usar o caractere curinga * para recursos ou grupos para ignorar essa restrição.

Solicitações de assinatura de certificado É possível criar CertificateSigningRequests no Autopilot para criar certificados assinados pela autoridade de certificação do cluster. Para evitar a interferência com componentes do sistema, o Autopilot rejeita CertificateSigningRequests para identidades privilegiadas conhecidas, como grupos do sistema, agentes do sistema ou agentes de serviço de IAM gerenciados pelo Google.
Recursos de segurança do GKE Os clusters do Autopilot ativam os recursos de segurança recomendados do GKE para você. Para conferir uma lista de recursos de segurança ativados e opcionais, consulte recursos de segurança no Autopilot.
Sistema operacional do nó Os clusters do Autopilot usam o Container-Optimized OS com containerd como o sistema operacional de nó. O Container-Optimized OS é criado e gerenciado pelo Google.
Upgrades da versão do GKE Os clusters do Autopilot são registrados em um canal de lançamento do GKE após a criação, e os upgrades automáticos estão sempre ativados. O Google atualiza automaticamente o plano de controle e os nós para a versão qualificada mais recente no canal de lançamento ao longo do tempo.

Limites de segurança no Autopilot

O Autopilot oferece acesso à API do Kubernetes, mas remove permissões para usar alguns recursos do Kubernetes altamente privilegiados, como pods privilegiados. A meta é limitar a capacidade de acessar, modificar ou controlar diretamente a máquina virtual (VM) do nó. O Autopilot implementa essas restrições para limitar as cargas de trabalho de acesso de baixo nível à VM do nó, para que o Google Cloud ofereça gerenciamento completo dos nós e um SLA no nível do pod.

Nossa intenção é impedir o acesso não intencional à VM do nó. Aceitamos envios nesse sentido por meio do Programa de recompensa para descobertas de vulnerabilidades do Google (VRP, na sigla em inglês) e recompensaremos os relatórios de acordo com o painel de recompensas do Google VRP.

Por padrão, usuários privilegiados, como administradores de cluster, têm controle total de qualquer cluster do GKE. Como prática recomendada de segurança, evite conceder privilégios avançados do GKE/Kubernetes amplamente. Em vez disso, use a delegação de administrador do namespace sempre que possível, conforme descrito na nossa orientação de multilocação.

O Autopilot provisiona VMs de locatário único no projeto para uso exclusivo. Em cada VM individual, as cargas de trabalho do Autopilot podem ser executadas juntas, compartilhando um kernel protegido por segurança. Como o kernel compartilhado representa um único limite de segurança, é recomendado que, se você precisar de isolamento forte, como cargas de trabalho de alto risco ou não confiáveis, execute suas cargas de trabalho nos pods do GKE Sandbox. para fornecer proteção de segurança em várias camadas.

Recursos de segurança com base no caso de uso

As seções a seguir oferecem links e recomendações para planejar, implementar e gerenciar a segurança dos clusters do Autopilot, dependendo do caso de uso.

Planejar a segurança do cluster

Caso de uso Recursos
Entenda como usar GKE como uma plataforma que aborda a segurança
Entenda seu papel no aumento da proteção do ambiente Saiba mais sobre o modelo de responsabilidade compartilhada.
Confira as recomendações do Google para o aumento da proteção e a resposta a incidentes
Entenda como o GKE implementa a geração de registros de auditoria

Autenticar e autorizar

Depois de configurar os clusters do Autopilot, talvez seja necessário autenticar os usuários e os aplicativos para usar recursos como a API do Kubernetes ou as APIs do Google Cloud.

Caso de uso Recursos
Autenticar usuários ou aplicativos no servidor da API do cluster
  • Para autenticar usuários, leia Como autenticar usuários.
  • Para autenticar aplicativos, leia Como autenticar aplicativos, Ele apresenta as etapas para a autenticação de aplicativos no mesmo cluster, em outros ambientes do Google Cloud ou em ambientes externos.
Autenticar aplicativos para APIs e serviços do Google Cloud Os clusters do Autopilot permitem usar a federação da identidade da carga de trabalho do GKE para autenticar com segurança suas cargas de trabalho nas APIs do Google Cloud configurando contas de serviço do Kubernetes para atuar como contas de serviço do IAM. Para instruções, consulte Configurar aplicativos para usar a federação de identidade da carga de trabalho do GKE.
Autorizar ações no nível do projeto Para autorizar ações entre clusters no nível do projeto, use o IAM. É possível conceder ou negar acesso a recursos específicos da API do GKE e do Kubernetes usando os papéis e as permissões do IAM. Para instruções, consulte Criar políticas do IAM.
Autorizar ações no nível do cluster Para autorizar ações em recursos da API Kubernetes em clusters específicos, use o mecanismo integrado de controle de acesso com base em papéis (RBAC, na sigla em inglês) do Kubernetes. Para instruções, consulte Autorizar ações em clusters usando o RBAC.
Autorizar ações no nível da organização É possível usar o serviço de políticas da organização do Google Cloud para aplicar restrições em operações específicas nos recursos do GKE na sua organização do Google Cloud. Para instruções, consulte Restringir ações em recursos do GKE usando políticas personalizadas da organização.

Clusters e cargas de trabalho reforçados

Se você tiver requisitos de isolamento ou aumento da proteção especializados além das medidas pré-configuradas do Autopilot, considere os seguintes recursos:

Caso de uso Recursos
Restrinja o acesso público ao endpoint do cluster Crie os clusters do Autopilot como clusters particulares, que desativam o endereço IP público do plano de controle do cluster. Para instruções, consulte Clusters particulares.
Restringir o acesso do cluster a redes específicas Use redes autorizadas do plano de controle para especificar intervalos de endereços IP que podem acessar seu cluster.
Armazenar informações confidenciais fora do cluster Armazenar dados sensíveis em um provedor de armazenamento externo criptografado com controle de versões ativado é um requisito de conformidade comum e uma prática recomendada. Use o Secret Manager para armazenar seus dados e acessá-los nos clusters do Autopilot com a federação de identidade da carga de trabalho do GKE. Para instruções, consulte Acessar secrets armazenados fora dos clusters do GKE usando a federação de identidade da carga de trabalho do GKE.
Verifique as imagens do contêiner antes da implantação no cluster Use a autorização binária para verificar a integridade das imagens de contêiner referenciadas nos manifestos do pod no momento da implantação. Para instruções, consulte Verificar imagens de contêiner no momento da implantação usando a autorização binária.

Monitorar a postura de segurança

Depois de configurar os clusters e implantar as cargas de trabalho, configure o monitoramento e a geração de registros para ter observabilidade da postura de segurança do cluster. Recomendamos o seguinte:

  • Inscreva os clusters no painel de postura de segurança do GKE para auditar cargas de trabalho em busca de preocupações, como vulnerabilidades ou configurações de segurança problemáticas nos pacotes do sistema operacional do contêiner, e receba informações de mitigação acionáveis.
  • Receba notificações sobre novos boletins de segurança e upgrades de eventos usando notificações de clusters.
  • Observe seus clusters usando o painel do GKE no Cloud Monitoring ou a guia Observabilidade no GKE.
  • Saiba como visualizar e gerenciar os registros de auditoria do GKE no Cloud Logging.

A seguir