Esta página descreve as funcionalidades, as configurações e as definições de segurança no modo Autopilot do Google Kubernetes Engine (GKE). Estas informações destinam-se a especialistas em segurança que pretendam compreender as restrições de segurança que a Google aplica no modo de condução autónoma e as funcionalidades de segurança que estão disponíveis para utilização no modo de condução autónoma. Para saber mais sobre as funções comuns e exemplos de tarefas que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.
Antes de ler esta página, familiarize-se com o seguinte:
Terminologia
No GKE, pode usar o Autopilot criando um cluster do Autopilot ou executando uma carga de trabalho numa ComputeClass do Autopilot em qualquer cluster Standard. Esta página descreve as medidas de segurança do Autopilot nestas duas situações através da seguinte terminologia:
- Cluster do Autopilot
- Todo o cluster usa o modo Autopilot.
- Cargas de trabalho do Autopilot em clusters Standard
- O cluster usa o modo padrão e executa cargas de trabalho específicas no modo Autopilot usando ComputeClasses.
Medidas de segurança no Autopilot
O GKE aplica várias práticas recomendadas e definições de segurança por predefinição no modo Autopilot, incluindo muitas das recomendações na vista geral de segurança e em Reforce a segurança do cluster.
Nos clusters do Autopilot, o GKE aplica rigorosamente todas as medidas nesta página por predefinição. Esta configuração predefinida torna os clusters do Autopilot a forma recomendada de usar o GKE. Para cargas de trabalho do Autopilot em clusters Standard, o GKE aplica as medidas de segurança nas secções seguintes com base no melhor esforço.
Aplicação das normas de segurança de pods do Kubernetes
O projeto Kubernetes tem um conjunto de diretrizes de segurança denominado Normas de segurança de pods que definem as seguintes políticas:
- Privilegiado: sem restrições de acesso. Não é usado no Autopilot.
- Base: impede caminhos de escalada de privilégios conhecidos. Permite que a maioria das cargas de trabalho seja executada sem alterações significativas.
- Restrito: o nível de segurança mais elevado. Requer alterações significativas à maioria das cargas de trabalho.
No modo Autopilot, o GKE aplica restrições de segurança de pods através de controladores de admissão do Kubernetes. A política de admissão do Autopilot Pod inclui todas as recomendações no nível de base das normas de segurança do pod, com algumas modificações para facilitar a utilização. Além disso, a política de admissão predefinida inclui muitas restrições do nível restrito das normas de segurança de pods, mas evita restrições que impediriam a execução da maioria das suas cargas de trabalho.
Para aplicar restrições adicionais em conformidade com a Política Restrita completa, pode usar opcionalmente o controlador de admissão PodSecurity em espaços de nomes específicos.
A tabela seguinte descreve a comparação entre os controlos na política de admissão do Autopilot predefinida e os controlos nos níveis Baseline e Restricted das normas de segurança de pods. Para mais informações sobre cada controlo nesta tabela, consulte a entrada correspondente nas Normas de segurança de pods.
Ao avaliar a conformidade, considerámos como as restrições se aplicam às suas próprias cargas de trabalho. Isto exclui cargas de trabalho de parceiros Google Cloud validadas e cargas de trabalho do sistema que requerem privilégios específicos para funcionar.
| Controlo | Conformidade com a política de base | Conformidade com a política restrita | Informações adicionais |
|---|---|---|---|
| HostProcess | O Autopilot bloqueia o HostProcess. | ||
| Espaços de nomes do anfitrião | O Autopilot bloqueia os espaços de nomes dos anfitriões. Alguns contentores de parceiros validados podem usar espaços de nomes de anfitriões. | ||
| Contentores privilegiados | Por predefinição, o Autopilot bloqueia contentores privilegiados. O Autopilot permite contentores privilegiados de parceiros validados para fins como a execução de ferramentas de segurança e monitorização. | ||
| Capacidades do Linux | As cargas de trabalho do Autopilot só podem aceder às capacidades especificadas no padrão de segurança de pods base por predefinição. Pode ativar manualmente as seguintes capacidades:
O Autopilot também permite que algumas cargas de trabalho de parceiros validados definam capacidades eliminadas. |
||
| Volumes HostPath | Parcialmente em conformidade | Parcialmente em conformidade | O Autopilot permite que os contentores peçam acesso só de leitura a
/var/log para depuração, mas nega todos os outros acessos de leitura ou escrita. |
| HostPorts | A definição de portas de anfitrião específicas não é permitida, o que mitiga alguns problemas de agendamento e impede a exposição direta acidental ou deliberada de serviços na rede. Pode configurar manualmente a atribuição de portas de anfitrião aleatórias a partir de um intervalo conhecido para suportar aplicações de rede de ligação direta, como servidores de jogos. | ||
| AppArmor | O perfil de segurança predefinido do Docker do AppArmor é aplicado automaticamente ao SO otimizado para contentores. | ||
| SELinux | O SELinux não é aplicado porque o AppArmor já está aplicado. O SELinux também não é obrigatório nas normas de segurança de pods. | ||
/proc tipo de montagem |
O GKE não define a sinalização de funcionalidade ProcMountType.
Se o securityContext do pod definir procMount
como "Unmasked", o GKE substitui-o automaticamente por
"Default". |
||
| perfil seccomp | O Autopilot aplica o perfil RuntimeDefaultseccomp
a todas as cargas de trabalho. Pode substituir manualmente esta definição para cargas de trabalho específicas definindo o perfil como Unconfined na especificação do pod. |
||
| sysctls | O GKE não define o sinalizador --allowed-unsafe-sysctls do kubelet, pelo que os pods com sysctls inseguros não são agendados. 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 definições de securityContext e rejeitar Pods que usam sysctls não seguros. | ||
| Tipos de volumes | O Autopilot só permite os tipos de volumes na política restrita com as seguintes adições: volumes HostPath com acesso só de leitura a
/var/log para depuração, gcePersistentDisk para discos persistentes do Compute Engine
e nfs para volumes do sistema de ficheiros de rede. |
||
| Escalamento de privilégios | Esta definição só oferece proteção a contentores que não estejam a ser executados como raiz. Os inquéritos da indústria mostram que 76% dos contentores são executados como raiz. Por isso, o Autopilot permite a execução como raiz para ativar a maioria das cargas de trabalho. Atualmente, esta definição também é útil para remover privilégios de cargas de trabalho para não root, permitindo a utilização de capacidades do sistema de ficheiros para contornar deficiências no processamento de capacidades root do Kubernetes. | ||
| Executar como não root | Os inquéritos da indústria mostram que 76% dos contentores são executados como root, pelo que o Autopilot permite a execução como root para ativar a maioria das cargas de trabalho. | ||
| Executar como utilizador não root | Os contentores podem definir runAsUser como 0.
Os inquéritos da indústria
mostram que 76% dos contentores são executados como raiz, pelo que
o Autopilot permite a execução como raiz para ativar a maioria das cargas de trabalho |
Configurações de segurança integradas
Além das normas de segurança de pods, a Google aplica muitas definições de segurança no Autopilot com base nas práticas recomendadas do setor e na nossa experiência. Estas configurações de segurança incorporadas são aplicadas rigorosamente nos clusters do Autopilot. Para cargas de trabalho do Autopilot em clusters Standard, a Google aplica estas configurações, com algumas exceções descritas na tabela que se segue, com base no melhor esforço possível.
A tabela seguinte descreve algumas das configurações de segurança que o Autopilot aplica por si:
| Configuração | Descrição |
|---|---|
| Opções de anfitrião |
|
| Capacidades do Linux | Pode usar as seguintes capacidades do Linux: "SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE" Também pode ativar manualmente as seguintes capacidades:
|
| Contentores privilegiados | Os contentores não podem ser executados no modo privilegiado, a menos que sejam implementados por um Google Cloud parceiro. Os contentores privilegiados podem fazer alterações ao nó subjacente, como alterar o kubelet. Este acesso pode aumentar o impacto de um comprometimento do Pod. |
| Namespaces geridos pelo GKE | Como medida de segurança, o Autopilot não permite a implementação de cargas de trabalho em espaços de nomes geridos pelo GKE, como kube-system. |
| Isolamento de contentores | O Autopilot aplica as seguintes restrições aos contentores para limitar o impacto das vulnerabilidades de fuga de contentores. Capacidades do Linux e segurança do kernel
|
| Aplicação da política de segurança ao nível do pod | O Autopilot suporta mecanismos de aplicação de políticas de segurança ao nível do pod, como o controlador de admissão PodSecurity, o Gatekeeper ou o Policy Controller.
No entanto, pode não precisar de usar nenhuma destas configurações se as configurações de segurança
integradas descritas nesta página já cumprirem os seus requisitos. |
| SSH para nós | O Autopilot bloqueia o acesso SSH aos nós. O GKE processa todos os aspetos operacionais dos nós, incluindo o estado de funcionamento dos nós e todos os componentes do Kubernetes em execução nos nós. Pode continuar a ligar-se remotamente aos seus contentores em execução através da funcionalidade do Kubernetes
|
| Assumir a identidade do utilizador | O Autopilot suporta a representação de utilizadores para todos os utilizadores e grupos definidos pelo utilizador. Apenas nos clusters do Autopilot, não é possível roubar a identidade de utilizadores e grupos do sistema (como o utilizador |
| Alterar webhooks de admissão dinâmicos | Apenas em clusters do Autopilot, o GKE modifica os
webhooks de mutação para excluir recursos em espaços de nomes geridos, como
O Autopilot também rejeita webhooks que especifiquem 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 pode usar o caráter universal |
| ValidatingAdmissionPolicies | Apenas em clusters do Autopilot, o GKE modifica os 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 pode usar o caráter universal |
| Pedidos de assinatura de certificados | Pode criar CertificateSigningRequests no Autopilot para criar certificados assinados pela autoridade de certificação do cluster. Para evitar interferências com os componentes do sistema, os clusters do Autopilot rejeitam CertificateSigningRequests para identidades privilegiadas conhecidas, como grupos do sistema, agentes do sistema ou agentes do serviço IAM geridos pela Google. Esta restrição não se aplica em clusters padrão, que lhe permitem criar CertificateSigningRequests para identidades privilegiadas conhecidas. |
| Funcionalidades de segurança do GKE | Os clusters do Autopilot ativam as funcionalidades de segurança do GKE recomendadas para si. Para ver uma lista das funcionalidades de segurança ativadas e opcionais, consulte as funcionalidades de segurança no Autopilot. |
| Sistema operativo do nó | O Autopilot usa o SO otimizado para contentores com
containerd como sistema operativo do nó.
O SO otimizado para contentores é criado e gerido pela Google. |
| Atualizações de versão do GKE | Os clusters do Autopilot estão inscritos num canal de lançamento do GKE aquando da criação, e as atualizações automáticas estão sempre ativadas. A Google atualiza automaticamente o painel de controlo 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 fornece acesso à API Kubernetes, mas remove as autorizações para usar algumas funcionalidades do Kubernetes altamente privilegiadas, como os pods privilegiados. O objetivo é limitar a capacidade de aceder, modificar ou controlar diretamente a máquina virtual (VM) do nó. O Autopilot implementa estas restrições para limitar as cargas de trabalho de terem acesso de baixo nível à VM do nó, para que oGoogle Cloud possa oferecer a gestão total dos nós e um SLA ao nível do pod.
A nossa intenção é impedir o acesso não intencional à VM do nó. Aceitamos envios nesse sentido através do Programa de Recompensa para Deteção de Vulnerabilidades (VRP) da Google e recompensamos os relatórios à discrição do painel de recompensas do VRP da Google.
Por predefinição, os utilizadores privilegiados, como os administradores de clusters, têm controlo total de qualquer cluster do GKE. Como prática recomendada de segurança, recomendamos que evite conceder privilégios poderosos do GKE ou do Kubernetes de forma generalizada e, em alternativa, use a delegação de administrador do espaço de nomes sempre que possível, conforme descrito nas nossas orientações de multi-tenancy.
O Autopilot aprovisiona VMs de inquilino único no seu projeto para sua utilização exclusiva. Em cada VM individual, as suas cargas de trabalho do Autopilot podem ser executadas em conjunto, partilhando um kernel reforçado em termos de segurança. Uma vez que o kernel partilhado representa um único limite de segurança, recomendamos que, se precisar de um isolamento forte, como cargas de trabalho de alto risco ou não fidedignas, execute as suas cargas de trabalho em pods do GKE Sandbox para oferecer proteção de segurança de várias camadas.
Recomendações de segurança com base no exemplo de utilização
As secções seguintes fornecem links e recomendações para planear, implementar e gerir a segurança dos seus clusters do Autopilot consoante o seu exemplo de utilização.
Planeie a segurança do cluster
| Exemplo de utilização | Recursos |
|---|---|
| Compreenda como o GKE aborda a segurança como plataforma |
|
| Compreenda o seu papel no reforço do seu ambiente | Saiba mais sobre o modelo de responsabilidade partilhada. |
| Veja as recomendações da Google para medidas de reforço e resposta a incidentes |
|
| Compreenda como o GKE implementa o registo de auditoria |
|
Autentique e autorize
Depois de configurar os clusters do Autopilot, pode ter de autenticar os seus utilizadores e aplicações para usar recursos como a API Kubernetes ou as APIs Google Cloud .
| Exemplo de utilização | Recursos |
|---|---|
| Autentique utilizadores ou aplicações no servidor da API do cluster |
|
| Autentique aplicações em Google Cloud APIs e serviços | Os clusters do Autopilot permitem-lhe usar a Workload Identity Federation para o GKE para autenticar as suas cargas de trabalho em segurança nas Google Cloud APIs configurando contas de serviço do Kubernetes para atuarem como contas de serviço do IAM. Para ver instruções, consulte o artigo Configure aplicações para usar a Workload Identity Federation para o GKE. |
| Autorize ações ao nível do projeto | Para autorizar ações em clusters ao nível do projeto, use o IAM. Pode conceder ou recusar o acesso a recursos específicos da API GKE e Kubernetes através de funções e autorizações do IAM. Para ver instruções, consulte o artigo Crie políticas de IAM. |
| Autorize ações ao nível do cluster | Para autorizar ações em recursos da API Kubernetes em clusters específicos, use o mecanismo de controlo de acesso baseado em funções (CABF) do Kubernetes incorporado. Para obter instruções, consulte o artigo Autorize ações em clusters através do RBAC. |
| Autorize ações ao nível da organização | Pode usar o Google Cloud serviço de políticas da organização para aplicar restrições em operações específicas nos recursos do GKE na sua Google Cloud organização. Para obter instruções, consulte o artigo Restrinja ações em recursos do GKE através de políticas de organização personalizadas. |
Proteja clusters e cargas de trabalho
Se tiver requisitos de isolamento ou reforço especializados além das medidas do Autopilot pré-configuradas, considere os seguintes recursos:
| Exemplo de utilização | Recursos |
|---|---|
| Restrinja o acesso público ao ponto final do cluster | Configure o isolamento de rede dos seus clusters do Autopilot e desative o ponto final externo do painel de controlo do cluster. Para ver instruções, consulte o artigo Configure o acesso ao plano de controlo. |
| Restrinja o acesso ao cluster a redes específicas | Use redes autorizadas do plano de controlo para especificar intervalos de endereços IP que podem aceder ao seu cluster. |
| Armazene informações confidenciais fora do cluster | O armazenamento de dados confidenciais num fornecedor de armazenamento externo encriptado com a ativação do controlo de versões é um requisito de conformidade comum e uma prática recomendada. Use o Secret Manager para armazenar os seus dados e aceder aos mesmos a partir dos seus clusters do Autopilot através da Workload Identity Federation para o GKE. Para instruções, consulte o artigo Aceda a segredos armazenados fora dos clusters do GKE através da Workload Identity Federation para o GKE. |
| Valide as imagens de contentores antes da implementação no cluster | Use a autorização binária para verificar a integridade das imagens de contentores referenciadas nos manifestos de pods no momento da implementação. Para obter instruções, consulte o artigo Valide imagens de contentores no momento da implementação através da autorização binária. |
Monitorize a sua postura de segurança
Depois de configurar os clusters e implementar as cargas de trabalho, deve configurar e configurar a monitorização e o registo para ter visibilidade sobre a postura de segurança do cluster. Recomendamos que faça o seguinte:
- Inscreva os seus clusters no painel de controlo da postura de segurança do GKE para auditar as cargas de trabalho relativamente a preocupações, como configurações de segurança problemáticas ou vulnerabilidades nos pacotes do sistema operativo do contentor, e receber informações de mitigação acionáveis.
- Receba notificações sobre novos boletins de segurança e eventos de atualização através das notificações de cluster.
- Observe os seus clusters através do painel de controlo do GKE no Cloud Monitoring ou do separador Observabilidade no GKE.
- Saiba como ver e gerir os seus registos de auditoria do GKE no Cloud Logging.
O que se segue?
- Leia a vista geral de segurança do GKE.
- Leia o guia de reforço do GKE.
- Subscreva os boletins de segurança e as notas de lançamento.