Nesta página, descrevemos os recursos, as configurações e as definições de segurança no modo Autopilot do Google Kubernetes Engine (GKE). Essas informações são destinadas a especialistas em segurança que querem entender as restrições de segurança que o Google aplica no modo Autopilot e os recursos de segurança disponíveis para uso no Autopilot. Para saber mais sobre papéis comuns e tarefas de exemplo mencionados no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.
Antes de ler esta página, familiarize-se com os seguintes conceitos:
Terminologia
No GKE, é possível usar o Autopilot criando um cluster do Autopilot ou executando uma carga de trabalho em uma ComputeClass do Autopilot em qualquer cluster Standard. Nesta página, descrevemos as medidas de segurança do Autopilot nessas duas situações usando a seguinte terminologia:
- Cluster do Autopilot
- Todo o cluster usa o modo Autopilot.
- Cargas de trabalho do Autopilot em clusters padrão
- O cluster usa o modo Standard, e você executa cargas de trabalho específicas no Autopilot usando ComputeClasses.
Medidas de segurança no Autopilot
Por padrão, o GKE aplica várias práticas recomendadas e configurações de segurança no modo Autopilot, incluindo muitas das recomendações na visão geral de segurança e em Como aumentar a segurança do cluster.
Nos clusters do Autopilot, o GKE aplica estritamente todas as medidas desta página por padrão. Essa configuração padrão faz dos clusters do Autopilot a maneira recomendada de usar o GKE. Para cargas de trabalho do Autopilot em clusters Standard, o GKE implementa as medidas de segurança nas seções a seguir da melhor maneira possível.
Aplicação dos 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 controladores de admissão do Kubernetes. A política de admissão de pods padrão do Autopilot 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 inclui 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.
Para aplicar outras restrições e 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 de admissão padrão do Autopilot se comparam aos controles nos níveis de referência e restritos dos padrões de segurança do pod. Para mais informações sobre 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 de parceiros Google Cloud 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. |
| 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
Além dos padrões de segurança de pods, o Google aplica muitas configurações de segurança no Autopilot com base nas práticas recomendadas do setor e em nossa experiência. Essas configurações de segurança integradas são aplicadas estritamente em clusters do Autopilot. Para cargas de trabalho do Autopilot em clusters padrão, o Google aplica essas configurações, com algumas exceções descritas na tabela a seguir, com base no melhor esforço.
A tabela a seguir descreve algumas das configurações de segurança que o Autopilot aplica para você:
| 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:
|
| Contêineres privilegiados | Os contêineres não podem ser executados no modo privilegiado, a menos que sejam implantados por um parceiro doGoogle 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 | O Autopilot oferece suporte à representação do usuário para todos os usuários e grupos definidos pelo usuário. Somente em clusters do Autopilot, não é possível representar usuários e grupos do sistema, como o usuário
|
| Como mutar os webhooks de admissão dinâmica | Somente em clusters do Autopilot, o GKE modifica
webhooks de mutação para excluir 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 | Somente em clusters do Autopilot, o GKE modifica
objetos 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 interferências com componentes do sistema, os clusters do Autopilot rejeitam CertificateSigningRequests para identidades privilegiadas conhecidas, como grupos do sistema, agentes do sistema ou agentes de serviço do IAM gerenciados pelo Google. Essa restrição não se aplica a clusters Standard, que permitem criar CertificateSigningRequests para identidades privilegiadas conhecidas. |
| 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ó | O Autopilot usa 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 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.
Recomendações 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 | Configure o isolamento de rede dos clusters do Autopilot e desative o endpoint externo do plano de controle do cluster. Para instruções, consulte Configurar o acesso ao plano de controle. |
| 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.