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.
No modo Autopilot, o GKE aplica restrições de segurança de pods usando um controlador de admissão personalizado chamado GKE Warden. Aplicamos uma política de segurança padrão que inclui todas as recomendações no nível de referência dos padrões de segurança de pods, com algumas modificações para usabilidade. Além disso, a política de admissão padrão do GKE Warden para o Autopilot aplica muitas restrições do nível restrito dos padrões de segurança de pods, mas evita restrições que impediriam a execução da maioria das cargas de trabalho.
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 controles na política padrão do Autopilot GKE Warden se comparam aos controles nos níveis de referência e restritos dos padrões de segurança do pod. 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 | Informações adicionais |
|---|---|---|---|
| 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:
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. |
| HostPorts | 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:
Nas versões do GKE anteriores à 1.21, não há suporte para o recurso |
| 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
|
| 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
|
| Falsificação de identidade 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 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 |
| ValidatingAdmissionPolicies | O Autopilot modifica O Autopilot também rejeita objetos - 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 |
| 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 |
|
| 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
- Leia a Visão geral de segurança do GKE.
- Leia o guia de aumento da proteção do GKE.
- Inscreva-se nos boletins de segurança e nas notas da versão.