Neste documento, você verá o que são os comparativos de mercado CIS do Kubernetes e do Google Kubernetes Engine (GKE), como auditar a conformidade com os comparativos de mercado e o que o GKE configura quando não é possível fazer auditoria ou implementar diretamente uma recomendação.
Como usar o CIS Benchmarks
O Center for Internet Security (CIS) lança comparativos de mercado para práticas recomendadas de segurança. O CIS Benchmark do Kubernetes é um conjunto de recomendações para configurar o Kubernetes a fim de oferecer suporte a uma postura de segurança reforçada. O comparativo de mercado está vinculado a uma versão específica do Kubernetes. O CIS Benchmark do Kubernetes foi escrito para a distribuição de código aberto do Kubernetes e para ser aplicado universalmente a todas as distribuições possíveis.
Com um serviço gerenciado como o GKE, nem todos os itens no comparativo de mercado são de sua responsabilidade, e há recomendações que não é possível auditar ou corrigir diretamente por conta própria. Se a execução for no GKE, use o CIS Benchmark do GKE, que é um comparativo de mercado filho do CIS Benchmark do Kubernetes, destinado especificamente à distribuição do GKE. Ele se baseia no CIS Benchmark atual, mas remove itens que não são configuráveis ou gerenciados pelo usuário e adiciona controles extras específicos do Google Cloud.
Vários conjuntos de comparativos de mercado
Com o GKE, é possível usar os CIS Benchmarks para GKE, Kubernetes, Docker, Container-Optimized OS e Linux. Para fazer o download de comparativos de mercado atualizados para esses produtos, acesse o site do CIS Benchmark.
O ambiente de execução padrão do contêiner, containerd, não tem um comparativo de mercado CIS.
Os nós do Windows Server usados com o GKE não são pontuados em um comparativo de mercado CIS apropriado porque eles não permitem especificamente o uso do Kubernetes e os comparativos de mercado CIS do Kubernetes não acomodam os nós do Windows atualmente.
Algumas ferramentas tentam analisar os nós do Kubernetes em relação a vários CIS Benchmarks (por exemplo, Linux, Docker e Kubernetes) e combinar os resultados. Isso costuma resultar em conselhos confusos e possivelmente contraditórios, já que esses comparativos de mercado não foram criados para ser combinados e aplicados a um ambiente do Kubernetes.
Modelo de responsabilidade compartilhada
No GKE, no modelo de responsabilidade compartilhada, o Google gerencia os seguintes componentes do Kubernetes:
- o plano de controle, incluindo as VMs dele, o servidor de API, outros componentes nas VMs e no etcd;
- a distribuição do Kubernetes;
- o sistema operacional dos nós.
As configurações relacionadas a esses itens geralmente não estão disponíveis para auditoria ou modificação no GKE.
Você ainda é responsável pelo upgrade dos nós, que executam as cargas de trabalho, e das próprias cargas de trabalho. Geralmente, é possível fazer auditoria e corrigir as recomendações para esses componentes.
Capacidade de auditoria e correção
O CIS Benchmark do GKE usa o CIS Benchmark atual do Kubernetes, mas remove itens que não são configuráveis ou gerenciados pelo usuário e adiciona outros controles específicos do Google Cloud.
As seções do CIS Benchmark do GKE são:
- Os componentes do plano de controle, o etcd e a configuração do plano de controle (seções 1, 2 e 3) são os do CIS Benchmark do Kubernetes. Geralmente, não é possível auditá-los ou corrigi-los no GKE.
- Os nós de trabalho (seção 4) são os do CIS Benchmark do Kubernetes. É possível auditar e corrigir alguns itens no GKE, mas talvez as instruções sejam diferentes.
- As políticas (seção 5) também fazem parte do CIS Benchmark do Kubernetes. Em geral, é possível aplicá-las diretamente ao GKE, sem qualquer alteração nas instruções.
- Os serviços gerenciados (seção 6) no comparativo de mercado CIS do GKE são novos conteúdos para o GKE especificamente. Nesta seção, você verá todas as recomendações específicas para os controles do Google Cloud. Eles podem ser auditados e corrigidos no GKE.
No caso dos itens que não podem ser auditados ou corrigidos no GKE, consulte a seção Valores padrão para entender como um cluster padrão criado no GKE é comparado ao CIS Benchmark do Kubernetes.
Versões
Os números de versão para diferentes comparativos de mercado podem não ser os mesmos.
Este documento se refere a estas versões:
Versão do Kubernetes | Versão do comparativo de mercado CIS do Kubernetes | Versão do comparativo de mercado CIS do GKE |
---|---|---|
1.15 | 1.5.0 | 1.0.0 |
Comparativo de mercado CIS do Kubernetes
Como acessar o comparativo de mercado
O comparativo de mercado CIS do Kubernetes está disponível no site do CIS.
Níveis de recomendação
No comparativo de mercado CIS do Kubernetes:
Nível | Descrição |
---|---|
Nível 1 | A ideia é que as recomendações: |
Nível 2 | Amplia o perfil de nível 1. As recomendações exibem uma ou mais das seguintes características: |
Pontuação da recomendação
No comparativo de mercado CIS do Kubernetes:
Pontuação | Descrição |
---|---|
Pontuou | O não cumprimento dessas recomendações diminuirá a pontuação final do comparativo de mercado. |
Não pontuou | O não cumprimento dessas recomendações não diminuirá a pontuação final do comparativo de mercado. |
Avaliação no GKE
Usamos os seguintes valores para especificar o status das recomendações do Kubernetes no GKE:
Status | Descrição |
---|---|
Aprovado | Está em conformidade com uma recomendação do comparativo de mercado. |
Reprovado | Não está em conformidade com uma recomendação do comparativo de mercado. |
Controle equivalente | Não está em conformidade com os termos exatos da recomendação do comparativo de mercado, mas há outros mecanismos no GKE que fornecem controles de segurança equivalentes. |
Depende do ambiente | O GKE não configura itens relacionados a esta recomendação. A configuração do usuário determina se o ambiente está em conformidade com uma recomendação do comparativo de mercado. |
Status no GKE
Ao criar um novo cluster do GKE com a versão especificada, veja o desempenho dele em relação ao CIS Benchmark do Kubernetes.
Status do cluster padrão do GKE:
Nº | Recomendação | Pontuou/Não pontuou | Nível | Status padrão |
---|---|---|---|---|
1 | Componentes do plano de controle | |||
1.1 | Arquivos de configuração do nó do plano de controle | |||
1.1.1 | Verificar se as permissões do arquivo de especificação do pod do servidor de API estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Pass |
1.1.2 | Verificar se a propriedade do arquivo de especificação do pod do servidor de API está definida como root:root |
Pontuou | N1 | Aprovado |
1.1.3 | Verificar se as permissões do arquivo de especificação do pod do gerenciador de controladores estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Pass |
1.1.4 | Verificar se a propriedade do arquivo de especificação do pod do gerenciador de controladores está definida como root:root |
Pontuou | N1 | Aprovado |
1.1.5 | Verificar se as permissões do arquivo de especificação do pod do programador estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Pass |
1.1.6 | Verificar se a propriedade do arquivo de especificação do pod do programador está definida como root:root |
Pontuou | N1 | Aprovado |
1.1.7 | Verificar se as permissões do arquivo de especificação do pod do etcd estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Pass |
1.1.8 | Verificar se a propriedade do arquivo de especificação do pod etcd está definida como root:root |
Pontuou | N1 | Aprovado |
1.1.9 | Verificar se as permissões do arquivo da interface de rede do contêiner estão definidas como 644 ou são mais restritivas |
Não pontuou | N1 | Aprovado |
1.1.10 | Verificar se a propriedade do arquivo da interface de rede do contêiner está definida como root:root |
Não pontuou | N1 | Aprovado |
1.1.11 | Verificar se as permissões do diretório de dados do etcd estão definidas como 700 ou são mais restritivas |
Pontuou | N1 | Aprovado |
1.1.12 | Verificar se a propriedade do diretório de dados do etcd está definida como etcd:etcd |
Pontuou | N1 | Aprovado |
1.1.13 | Verificar se as permissões do arquivo admin.conf estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Aprovado |
1.1.14 | Verificar se a propriedade do arquivo admin.conf está definida como root:root |
Pontuou | N1 | Aprovado |
1.1.15 | Verificar se as permissões do arquivo scheduler.conf estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Aprovado |
1.1.16 | Verificar se a propriedade do arquivo scheduler.conf está definida como root:root |
Pontuou | N1 | Pass |
1.1.17 | Verificar se as permissões do arquivo controller-manager.conf estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Aprovado |
1.1.18 | Verificar se a propriedade do arquivo controller-manager.conf está definida como root:root |
Pontuou | N1 | Pass |
1.1.19 | Verificar se o diretório PKI do Kubernetes e a propriedade do arquivo estão definidos como root:root |
Pontuou | N1 | Aprovado |
1.1.20 | Verificar se as permissões do arquivo de certificado PKI do Kubernetes estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Aprovado |
1.1.21 | Verificar se as permissões do arquivo de chave PKI do Kubernetes estão definidas como 600 |
Pontuou | N1 | Aprovado |
1.2 | Servidor de API | |||
1.2.1 | Verificar se o argumento --anonymous-auth está definido como falso | Não pontuou | N1 | Reprovado |
1.2.2 | Verificar se o argumento --basic-auth-file não está definido | Pontuou | N1 | Aprovado |
1.2.3 | Verificar se o parâmetro --token-auth-file não está definido | Pontuou | N1 | Reprovado |
1.2.4 | Verificar se o argumento --kubelet-https está definido como verdadeiro | Pontuou | N1 | Aprovado |
1.2.5 | Verificar se os argumentos --kubelet-client-certificate e --kubelet-client-key estão definidos conforme apropriado | Pontuou | N1 | Aprovado |
1.2.6 | Verificar se o argumento --kubelet-certificate-authority está definido conforme apropriado | Pontuou | N1 | Aprovado |
1.2.7 | Verificar se o argumento --authorization-mode não está definido como AlwaysAllow | Pontuou | N1 | Aprovado |
1.2.8 | Verificar se o argumento --authorization-mode inclui o nó | Pontuou | N1 | Aprovado |
1.2.9 | Verificar se o argumento --authorization-mode inclui o RBAC | Pontuou | N1 | Pass |
1.2.10 | Verificar se o plug-in de controle de admissão EventRateLimit está definido | Não pontuou | N1 | Reprovado |
1.2.11 | Verificar se o plug-in de controle de admissão AlwaysAdmit não está definido | Pontuou | N1 | Pass |
1.2.12 | Verificar se o plug-in de controle de admissão AlwaysPullImages está definido | Não pontuou | N1 | Reprovado |
1.2.13 | Verificar se o plug-in de controle de admissão SecurityContextDeny está definido, se PodSecurityPolicy não for usado | Não pontuou | N1 | Reprovado |
1.2.14 | Verificar se o plug-in de controle de admissão ServiceAccount está definido | Pontuou | N1 | Aprovado |
1.2.15 | Verificar se o plug-in de controle de admissão NamespaceLifecycle está definido | Pontuou | N1 | Aprovado |
1.2.16 | Verificar se o plug-in de controle de admissão PodSecurityPolicy está definido | Pontuou | N1 | Reprovado |
1.2.17 | Verificar se o plug-in de controle de admissão NodeRestriction está definido | Pontuou | N1 | Aprovado |
1.2.18 | Verificar se o argumento --insecure-bind-address não está definido | Pontuou | N1 | Aprovado |
1.2.19 | Verificar se o argumento --insecure-port está definido como 0 | Pontuou | N1 | Aprovado |
1.2.20 | Verificar se o argumento --secure-port não está definido como 0 | Pontuou | N1 | Aprovado |
1.2.21 | Verificar se o argumento --profiling está definido como falso | Pontuou | N1 | Reprovado |
1.2.22 | Verificar se o argumento --audit-log-path está definido | Pontuou | N1 | Controle equivalente |
1.2.23 | Verificar se o argumento --audit-log-maxage está definido como 30 ou conforme apropriado | Pontuou | N1 | Controle equivalente |
1.2.24 | Verificar se o argumento --audit-log-maxbackup está definido como 10 ou conforme apropriado | Pontuou | N1 | Controle equivalente |
1.2.25 | Verificar se o argumento --audit-log-maxsize está definido como 100 ou conforme apropriado | Pontuou | N1 | Controle equivalente |
1.2.26 | Verificar se o argumento --request-timeout está definido conforme apropriado | Pontuou | N1 | Aprovado |
1.2.27 | Verificar se o argumento --service-account-lookup está definido como verdadeiro | Pontuou | N1 | Aprovado |
1.2.28 | Verificar se o argumento --service-account-key-file está definido conforme apropriado | Pontuou | N1 | Aprovado |
1.2.29 | Verificar se os argumentos --etcd-certfile e --etcd-keyfile estão definidos conforme apropriado | Pontuou | N1 | Reprovado |
1.2.30 | Verificar se os argumentos --tls-cert-file e --tls-private-key-file estão definidos conforme apropriado | Pontuou | N1 | Aprovado |
1.2.31 | Verificar se o argumento --client-ca-file está definido conforme apropriado | Pontuou | N1 | Pass |
1.2.32 | Verificar se o argumento --etcd-cafile está definido conforme apropriado | Pontuou | N1 | Reprovado |
1.2.33 | Verificar se o argumento --encryption-provider-config está definido conforme apropriado | Pontuou | N1 | Aprovado |
1.2.34 | Verificar se os provedores de criptografia estão configurados corretamente | Pontuou | N1 | Reprovado |
1.2.35 | Verificar se o servidor de API usa apenas códigos criptográficos fortes | Não pontuou | N1 | Aprovado |
1.3 | Controller Manager | |||
1.3.1 | Verificar se o argumento --terminated-pod-gc-threshold está definido conforme apropriado | Pontuou | N1 | Aprovado |
1.3.2 | Verificar se o argumento --profiling está definido como falso | Pontuou | N1 | Reprovado |
1.3.3 | Verificar se o argumento --use-service-account-credentials está definido como verdadeiro | Pontuou | N1 | Reprovado |
1.3.4 | Verificar se o argumento --service-account-private-key-file está definido conforme apropriado | Pontuou | N1 | Aprovado |
1.3.5 | Verificar se o argumento --root-ca-file está definido conforme apropriado | Pontuou | N1 | Aprovado |
1.3.6 | Verificar se o argumento RotateKubeletServerCertificate está definido como verdadeiro | Pontuou | N2 | Controle equivalente |
1.3.7 | Verificar se o argumento --bind-address está definido como 127.0.0.1 | Pontuou | N1 | Aprovado |
1.4 | Programador | |||
1.4.1 | Verificar se o argumento --profiling está definido como falso | Pontuou | N1 | Reprovado |
1.4.2 | Verificar se o argumento --bind-address está definido como 127.0.0.1 | Pontuou | N1 | Aprovado |
2 | etcd | |||
2.1 | Verificar se os argumentos --cert-file e --key-file estão definidos conforme apropriado | Pontuou | N1 | Reprovado |
2.2 | Verificar se o argumento --client-cert-auth está definido como verdadeiro | Pontuou | N1 | Reprovado |
2.3 | Verificar se o argumento --auto-tls não está definido como verdadeiro | Pontuou | N1 | Aprovado |
2.4 | Verificar se os argumentos --peer-cert-file e --peer-key-file estão definidos conforme apropriado | Pontuou | N1 | Controle equivalente |
2.5 | Verificar se o argumento --peer-client-cert-auth está definido como verdadeiro | Pontuou | N1 | Controle equivalente |
2.6 | Verificar se o argumento --peer-auto-tls não está definido como verdadeiro | Pontuou | N1 | Controle equivalente |
2.7 | Verificar se uma autoridade de certificação exclusiva é usada para o etcd | Não pontuou | N2 | Aprovado |
3 | Configuração do plano de controle | |||
3.1 | Autenticação e autorização | |||
3.1.1 | Não é possível usar a autenticação de certificado do cliente para usuários | Não pontuou | N2 | Aprovado |
3.2 | Logging | |||
3.2.1 | Verificar se uma política de auditoria mínima foi criada | Pontuou | N1 | Aprovado |
3.2.2 | Verificar se a política de auditoria abrange as principais preocupações de segurança | Não pontuou | N2 | Aprovado |
4 | Nós de trabalho | |||
4.1 | Arquivos de configuração do nó de trabalho | |||
4.1.1 | Verificar se as permissões do arquivo de serviço do Kubelet estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Pass |
4.1.2 | Verificar se a propriedade do arquivo de serviço do Kubelet está definida como root:root |
Pontuou | N1 | Aprovado |
4.1.3 | Verificar se as permissões do arquivo kubeconfig do proxy estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Aprovado |
4.1.4 | Verificar se a propriedade do arquivo kubeconfig do proxy está definida como root:root |
Pontuou | N1 | Aprovado |
4.1.5 | Verificar se as permissões do arquivo kubelet.conf estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Aprovado |
4.1.6 | Verificar se a propriedade do arquivo kubelet.conf está definida como root:root |
Pontuou | N1 | Aprovado |
4.1.7 | Verificar se as permissões do arquivo de autoridades de certificação estão definidas como 644 ou são mais restritivas |
Pontuou | N1 | Aprovado |
4.1.8 | Verificar se a propriedade do arquivo de autoridades de certificação do cliente está definida como root:root |
Pontuou | N1 | Aprovado |
4.1.9 | Verificar se o arquivo de configuração do kubelet tem permissões definidas como 644 ou são mais restritivas |
Pontuou | N1 | Pass |
4.1.10 | Verificar se a propriedade do arquivo de configuração do kubelet está definida como root:root |
Pontuou | N1 | Aprovado |
4.2 | Kubelet | |||
4.2.1 | Verificar se o argumento --anonymous-auth está definido como falso | Pontuou | N1 | Aprovado |
4.2.2 | Verificar se o argumento --authorization-mode não está definido como AlwaysAllow | Pontuou | N1 | Aprovado |
4.2.3 | Verificar se o argumento --client-ca-file está definido conforme apropriado | Pontuou | N1 | Aprovado |
4.2.4 | Verificar se o argumento --read-only-port está definido como 0 | Pontuou | N1 | Reprovado |
4.2.5 | Verificar se o argumento --streaming-connection-idle-timeout não está definido como 0 | Pontuou | N1 | Aprovado |
4.2.6 | Verificar se o argumento --protect-kernel-defaults está definido como verdadeiro | Pontuou | N1 | Fail |
4.2.7 | Verificar se o argumento --make-iptables-util-chains está definido como verdadeiro | Pontuou | N1 | Aprovado |
4.2.8 | Verificar se o argumento --hostname-override não está definido | Não pontuou | N1 | Aprovado |
4.2.9 | Verificar se o argumento --event-qps está definido como 0 ou um nível que garanta a captura apropriada do evento | Não pontuou | N2 | Reprovado |
4.2.10 | Verificar se os argumentos --tls-cert-file e --tls-private-key-file estão definidos conforme apropriado | Pontuou | N1 | Controle equivalente |
4.2.11 | Verificar se o argumento --rotate-certificates não está definido como falso | Pontuou | N1 | Controle equivalente |
4.2.12 | Verificar se o argumento RotateKubeletServerCertificate está definido como verdadeiro | Pontuou | N1 | Controle equivalente |
4.2.13 | Verificar se o Kubelet usa somente códigos criptográficos fortes | Não pontuou | N1 | Falha |
5 | Políticas | |||
5.1 | RBAC e contas de serviço | |||
5.1.1 | Verificar se o papel cluster-admin é usado somente quando necessário | Não pontuou | N1 | Depende do ambiente |
5.1.2 | Minimizar o acesso a secrets | Não pontuou | N1 | Depende do ambiente |
5.1.3 | Minimizar o uso de caracteres curinga em Papéis e ClusterRoles | Não pontuou | N1 | Depende do ambiente |
5.1.4 | Minimizar o acesso para criar pods | Não pontuou | N1 | Depende do ambiente |
5.1.5 | Verificar se as contas de serviço padrão não são usadas ativamente | Pontuou | N1 | Depende do ambiente |
5.1.6 | Verificar se os tokens da conta de serviço são ativados apenas quando necessário | Não pontuou | N1 | Depende do ambiente |
5.2 | Políticas de segurança de pods | |||
5.2.1 | Minimizar a admissão de contêineres privilegiados | Não pontuou | N1 | Depende do ambiente |
5.2.2 | Minimizar a admissão de contêineres para compartilhamento do namespace do ID do processo do host | Pontuou | N1 | Depende do ambiente |
5.2.3 | Minimizar a admissão de contêineres para compartilhamento do namespace de IPC do host | Pontuou | N1 | Depende do ambiente |
5.2.4 | Minimizar a admissão de contêineres para compartilhamento do namespace da rede do host | Pontuou | N1 | Depende do ambiente |
5.2.5 | Minimizar a admissão de contêineres com allowPrivilegeEscalation | Pontuou | N1 | Depende do ambiente |
5.2.6 | Minimizar a admissão de contêineres raiz | Não pontuou | N2 | Depende do ambiente |
5.2.7 | Minimizar a admissão de contêineres com o recurso NET_RAW | Não pontuou | N1 | Depende do ambiente |
5.2.8 | Minimizar a admissão de contêineres com recursos adicionados | Não pontuou | N1 | Depende do ambiente |
5.2.9 | Minimizar a admissão de contêineres com recursos atribuídos | Não pontuou | N2 | Depende do ambiente |
5.3 | Políticas de rede e CNI | |||
5.3.1 | Verifique se a CNI em uso é compatível com políticas de rede | Não pontuou | N1 | Aprovado |
5.3.2 | Verificar se todos os namespaces têm políticas de rede definidas | Pontuou | N2 | Depende do ambiente |
5.4 | Gerenciamento de secrets | |||
5.4.1 | Usar secrets como arquivos em vez de secrets como variáveis de ambiente | Não pontuou | N1 | Depende do ambiente |
5.4.2 | Considerar o armazenamento de secret externo | Não pontuou | N2 | Depende do ambiente |
5.5 | Controle de admissão extensível | |||
5.5.1 | Configurar a proveniência de imagem usando o controlador de admissão ImagePolicyWebhook | Não pontuou | N2 | Depende do ambiente |
5.6 | Políticas gerais | |||
5.6.1 | Criar limites administrativos entre recursos usando namespaces | Não pontuou | N1 | Depende do ambiente |
5.6.2 | Verificar se o perfil seccomp está definido como docker/default nas definições do pod | Não pontuou | N2 | Depende do ambiente |
5.6.3 | Aplicar o contexto de segurança aos pods e contêineres | Não pontuou | N2 | Depende do ambiente |
5.6.4 | O namespace padrão não pode ser usado | Pontuou | N2 | Depende do ambiente |
Valores padrão no GKE
Quando o padrão de um novo cluster do GKE não aprovar uma recomendação do comparativo de mercado CIS do Kubernetes, veja os valores padrão usados no GKE e uma explicação. É possível solucionar algumas recomendações seguindo os procedimentos de correção definidos no comparativo de mercado CIS do GKE. Os itens que podem ser auditados automaticamente são marcados como "Pontuou" no comparativo de mercado CIS do GKE.
Valores padrão de recomendações que apresentarem "Reprovado" ou "Depende do ambiente" em um cluster padrão do GKE:
Nº | Recomendação | Pontuou/não pontuou no comparativo de mercado CIS do Kubernetes |
Nível | Status padrão | Valor padrão | Justificativa | Pontuou/não pontuou no comparativo de mercado CIS do GKE |
---|---|---|---|---|---|---|---|
1 | Componentes do plano de controle | ||||||
1.2 | Servidor de API | ||||||
1.2.1 | Verificar se o argumento --anonymous-auth está definido como falso | Não pontuou | N1 | Reprovado | true |
Alguns componentes de monitoramento do GKE usam autenticação anônima para conseguir as métricas. Ainda que o GKE permita a autenticação anônima para o kubelet, a exposição é idêntica à porta somente leitura, já que o GKE desativa os outros gerenciadores de depuração. | Não pontuou |
1.2.3 | Verificar se o parâmetro --token-auth-file não está definido | Pontuou | N1 | Reprovado | Set | Alguns componentes do plano de controle são inicializados usando tokens estáticos, que são usados para autenticação no servidor de API. | Não pontuou |
1.2.10 | Verificar se o plug-in de controle de admissão EventRateLimit está definido | Não pontuou | N1 | Reprovado | Não definido | O GKE não é compatível com o controlador de admissão da limitação de taxa de eventos, já que ele é um recurso Alfa do Kubernetes. | Não pontuou |
1.2.12 | Verificar se o plug-in de controle de admissão AlwaysPullImages está definido | Não pontuou | N1 | Reprovado | Não definido | O controlador de admissão AlwaysPullImages oferece certa proteção para imagens de registros particulares em clusters multilocatários não cooperativos. Porém, isso transforma os registros do contêiner em um ponto único de falha para a criação de novos pods em todo o cluster. O GKE não ativa o controlador de admissão AlwaysPullImages, o que permite aos administradores do cluster implementar a política de admissão para fazer essa operação por conta própria. | Não pontuou |
1.2.13 | Verificar se o plug-in de controle de admissão SecurityContextDeny está definido, se PodSecurityPolicy não for usado | Não pontuou | N1 | Reprovado | Não definido | Por padrão, o GKE não ativa o controlador de admissão do contexto de segurança. Usar uma política de segurança de pod permite mais controle e é preferível. | Não pontuou |
1.2.16 | Verificar se o plug-in de controle de admissão PodSecurityPolicy está definido | Pontuou | N1 | Reprovado | Não definido | Por padrão, o GKE não ativa o controlador de admissão da Política de segurança do pod, já que isso exige que uma política seja definida. Os clientes do GKE podem ativar o PodSecurityPolicy. | Não pontuou. Consulte também 6.10.3 |
1.2.21 | Verificar se o argumento --profiling está definido como falso | Pontuou | N1 | Reprovado | Não definido | O GKE usa a criação de perfil para depuração. | Não pontuou |
1.2.22 | Verificar se o argumento --audit-log-path está definido | Pontuou | N1 | Controle equivalente | Não definido | O GKE captura registros de auditoria, mas não usa essas sinalizações para auditoria. Consulte a política de auditoria do GKE, para mais detalhes. | Não pontuou |
1.2.23 | Verificar se o argumento --audit-log-maxage está definido como 30 ou conforme apropriado | Pontuou | N1 | Controle equivalente | Não definido | O GKE captura registros de auditoria, mas não usa essas sinalizações para auditoria. Consulte a política de auditoria do GKE, para mais detalhes. | Não pontuou |
1.2.24 | Verificar se o argumento --audit-log-maxbackup está definido como 10 ou conforme apropriado | Pontuou | N1 | Controle equivalente | Não definido | O GKE captura registros de auditoria, mas não usa essas sinalizações para auditoria. Consulte a política de auditoria do GKE, para mais detalhes. | Não pontuou |
1.2.25 | Verificar se o argumento --audit-log-maxsize está definido como 100 ou conforme apropriado | Pontuou | N1 | Controle equivalente | Não definido | O GKE captura registros de auditoria, mas não usa essas sinalizações para auditoria. Consulte a política de auditoria do GKE, para mais detalhes. | Não pontuou |
1.2.29 | Verificar se os argumentos --etcd-certfile e --etcd-keyfile estão definidos conforme apropriado | Pontuou | N1 | Reprovado | Não definido | No momento, o GKE não usa mTLS para proteger conexões entre o servidor de API e o etcd. O etcd escuta no localhost. Consulte Confiança de cluster, para mais detalhes. | Não pontuou |
1.2.32 | Verificar se o argumento --etcd-cafile está definido conforme apropriado | Pontuou | N1 | Reprovado | Não definido | No momento, o GKE não usa mTLS para proteger conexões entre o servidor de API e o etcd. O etcd escuta no localhost. Consulte Confiança de cluster, para mais detalhes. | Não pontuou |
1.2.34 | Verificar se os provedores de criptografia estão configurados corretamente | Pontuou | N1 | Fail | identity |
O GKE criptografa o conteúdo do cliente em repouso por padrão. Para criptografar ainda mais secrets, use a criptografia de secrets da camada de aplicativos. | Não pontuou. Consulte também 6.3.1 |
1.3 | Controller Manager | ||||||
1.3.2 | Verificar se o argumento --profiling está definido como falso | Pontuou | N1 | Reprovado | true |
O GKE usa a criação de perfil para depuração. | Não pontuou |
1.3.6 | Verificar se o argumento RotateKubeletServerCertificate está definido como verdadeiro | Pontuou | N2 | Controle equivalente | false |
O GKE gira os certificados do Kubelet, mas não usa essa sinalização. | Não pontuou |
1.4 | Programador | ||||||
1.4.1 | Verificar se o argumento --profiling está definido como falso | Pontuou | N1 | Reprovado | true |
O GKE usa a criação de perfil para depuração. | Não pontuou |
2 | etcd | ||||||
2.1 | Verificar se os argumentos --cert-file e --key-file estão definidos conforme apropriado | Pontuou | N1 | Reprovado | Não definido | No momento, o GKE não usa mTLS para proteger conexões entre o servidor de API e o etcd. O etcd escuta no localhost. Consulte Confiança de cluster, para mais detalhes. | Não pontuou |
2.2 | Verificar se o argumento --client-cert-auth está definido como verdadeiro | Pontuou | N1 | Reprovado | Não definido | No momento, o GKE não usa mTLS para proteger conexões entre o servidor de API e o etcd. O etcd escuta no localhost. Consulte Confiança de cluster, para mais detalhes. | Não pontuou |
2.4 | Verificar se os argumentos --peer-cert-file e --peer-key-file estão definidos conforme apropriado | Pontuou | N1 | Controle equivalente | Não definido | O GKE usa mTLS para tráfego de mesmo nível entre instâncias de etcd. Essas sinalizações são usadas para clusters regionais, mas não para clusters zonais, já que há apenas uma instância de etcd em um cluster zonal. Consulte Confiança de cluster, para mais detalhes. | Não pontuou |
2.5 | Verificar se o argumento --peer-client-cert-auth está definido como verdadeiro | Pontuou | N1 | Controle equivalente | Não definido | O GKE usa mTLS para tráfego de mesmo nível entre instâncias de etcd. Essas sinalizações são usadas para clusters regionais, mas não para clusters zonais, já que há apenas uma instância de etcd em um cluster zonal. Consulte Confiança de cluster, para mais detalhes. | Não pontuou |
2.6 | Verificar se o argumento --peer-auto-tls não está definido como verdadeiro | Pontuou | N1 | Controle equivalente | Não definido | O GKE usa mTLS para tráfego de mesmo nível entre instâncias de etcd. Essas sinalizações são usadas para clusters regionais, mas não para clusters zonais, já que há apenas uma instância de etcd em um cluster zonal. Consulte Confiança de cluster, para mais detalhes. | Não pontuou |
4 | Nós de trabalho | ||||||
4.2 | Kubelet | ||||||
4.2.4 | Verificar se o argumento --read-only-port está definido como 0 | Pontuou | N1 | Reprovado | 10255 |
Alguns componentes de monitoramento do GKE usam a porta somente leitura do Kubelet para conseguir as métricas. | Pontuou |
4.2.6 | Verificar se o argumento --protect-kernel-defaults está definido como verdadeiro | Pontuou | N1 | Reprovado | false |
O GKE não protege os padrões do kernel do Kubernetes, já que talvez as cargas de trabalho do cliente os modifique. | Pontuou |
4.2.9 | Verificar se o argumento --event-qps está definido como 0 ou um nível que garanta a captura apropriada do evento | Não pontuou | N2 | Reprovado | 5 |
Os eventos são objetos do Kubernetes armazenados no etcd. Para evitar sobrecarregar o etcd, eles são mantidos por apenas uma hora e não são um mecanismo de auditoria de segurança adequado. Permitir eventos ilimitados, conforme sugerido neste controle, expõe o cluster a riscos desnecessários de negação de serviço (DoS, na sigla em inglês) e contradiz a recomendação de usar EventRateLimits de admissão. Os eventos relevantes de segurança que precisam de armazenamento permanente podem ser enviados aos registros. | Pontuou |
4.2.10 | Verificar se os argumentos --tls-cert-file e --tls-private-key-file estão definidos conforme apropriado | Pontuou | N1 | Controle equivalente | Não definido | O GKE usa o mTLS para o tráfego do Kubelet para o servidor de API. O GKE usa o TLS do servidor de API para o tráfego do Kubelet, que é autenticado para clusters do GKE v1.12 +. O GKE não usa essas sinalizações, mas isso é especificado no arquivo de configuração do kubelet. Consulte Confiança de cluster, para mais detalhes. | Pontuou |
4.2.11 | Verificar se o argumento --rotate-certificates não está definido como falso | Pontuou | N1 | Controle equivalente | Não definido | O GKE alterna os certificados do servidor para clusters do GKE v1.12 +. O GKE não usa essas sinalizações, mas isso é especificado no arquivo de configuração do Kubelet. O GKE não alterna certificados de cliente, a menos que os nós protegidos do GKE estejam ativados. Nesse caso, o GKE não usa essas sinalizações, mas executa um processo separado para a rotação de certificados. Consulte Confiança de cluster, para mais detalhes. | Pontuou |
4.2.12 | Verificar se o argumento RotateKubeletServerCertificate está definido como verdadeiro | Pontuou | N1 | Controle equivalente | Não definido | O GKE alterna os certificados do servidor para clusters do GKE v1.12 +. O GKE não usa essas sinalizações, mas isso é especificado no arquivo de configuração do Kubelet. Consulte Confiança de cluster, para mais detalhes. | Pontuou |
4.2.13 | Verificar se o Kubelet usa somente códigos criptográficos fortes | Não pontuou | Falha | Não definido | O GKE usa o conjunto de criptografia padrão permitido pelo golang, que é considerado seguro para uso pelos especialistas em criptografia do Golang e é o padrão do Kubernetes. | Não pontuou | |
5 | Políticas | ||||||
5.1 | RBAC e contas de serviço | ||||||
5.1.1 | Verificar se o papel cluster-admin é usado somente quando necessário | Não pontuou | N1 | Depende do ambiente | n/a | Não pontuou | |
5.1.2 | Minimizar o acesso a secrets | Não pontuou | N1 | Depende do ambiente | n/a | Não pontuou | |
5.1.3 | Minimizar o uso de caracteres curinga em Papéis e ClusterRoles | Não pontuou | N1 | Depende do ambiente | n/a | Não pontuou | |
5.1.4 | Minimizar o acesso para criar pods | Não pontuou | N1 | Depende do ambiente | n/a | Não pontuou | |
5.1.5 | Verificar se as contas de serviço padrão não são usadas ativamente | Pontuou | N1 | Depende do ambiente | n/a | Pontuou | |
5.1.6 | Verificar se os tokens da conta de serviço são ativados apenas quando necessário | Não pontuou | N1 | Depende do ambiente | n/a | Não pontuou | |
5.2 | Políticas de segurança de pods | ||||||
5.2.1 | Minimizar a admissão de contêineres privilegiados | Não pontuou | N1 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.2.2 | Minimizar a admissão de contêineres para compartilhamento do namespace do ID do processo do host | Pontuou | N1 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.2.3 | Minimizar a admissão de contêineres para compartilhamento do namespace de IPC do host | Pontuou | N1 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.2.4 | Minimizar a admissão de contêineres para compartilhamento do namespace da rede do host | Pontuou | N1 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.2.5 | Minimizar a admissão de contêineres com allowPrivilegeEscalation | Pontuou | N1 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.2.6 | Minimizar a admissão de contêineres raiz | Não pontuou | N2 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.2.7 | Minimizar a admissão de contêineres com o recurso NET_RAW | Não pontuou | N1 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.2.8 | Minimizar a admissão de contêineres com recursos adicionados | Não pontuou | N1 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.2.9 | Minimizar a admissão de contêineres com recursos atribuídos | Não pontuou | N2 | Depende do ambiente | n/a | Por padrão, nenhuma política de segurança de pods é definida. | Pontuou |
5.3 | Políticas de rede e CNI | ||||||
5.3.2 | Verificar se todos os namespaces têm políticas de rede definidas | Pontuou | N2 | Depende do ambiente | n/a | Pontuou | |
5.4 | Gerenciamento de secrets | ||||||
5.4.1 | Usar secrets como arquivos em vez de secrets como variáveis de ambiente | Não pontuou | N1 | Depende do ambiente | n/a | Não pontuou | |
5.4.2 | Considerar o armazenamento de secret externo | Não pontuou | N2 | Depende do ambiente | n/a | Não pontuou | |
5.5 | Controle de admissão extensível | ||||||
5.5.1 | Configurar a proveniência de imagem usando o controlador de admissão ImagePolicyWebhook | Não pontuou | N2 | Depende do ambiente | Não ativado | Por padrão, o GKE não ativa o controlador de admissão do webhook de política de imagens por padrão. Por padrão, a proveniência de imagem que usa autorização binária não é definida, já que isso exige que uma política seja definida. | Não pontuou. Consulte também 6.10.5 |
5.6 | Políticas gerais | ||||||
5.6.1 | Criar limites administrativos entre recursos usando namespaces | Não pontuou | N1 | Depende do ambiente | n/a | Não pontuou | |
5.6.2 | Verificar se o perfil seccomp está definido como docker/default nas definições do pod | Não pontuou | N2 | Depende do ambiente | n/a | Por padrão, nenhum perfil seccomp é definido. | Não pontuou |
5.6.3 | Aplicar o contexto de segurança aos pods e contêineres | Não pontuou | N2 | Depende do ambiente | n/a | Por padrão, nenhum contexto de segurança é definido. | Não pontuou |
5.6.4 | O namespace padrão não pode ser usado | Pontuou | N2 | Depende do ambiente | n/a | Pontuou |
Comparativo de mercado CIS do GKE
Como acessar o comparativo de mercado
O comparativo de mercado CIS do GKE está disponível no site do CIS:
- Acesse a lista completa de comparativos de mercado CIS.
- No título do Kubernetes, clique em "Expandir" para ver o conteúdo relacionado.
- O comparativo de mercado CIS do GKE aparece listado para fazer o download.
Níveis de recomendação
No comparativo de mercado CIS do GKE
Nível | Descrição |
---|---|
Nível 1 | As recomendações precisam ser amplamente aplicáveis. Elas podem ser aplicadas a quase todos os ambientes. |
Nível 2 | As recomendações resultam em um ambiente de segurança mais rigoroso, mas não são necessariamente aplicáveis a todos os casos. Elas podem influenciar o desempenho ou podem não ser aplicadas em conjunto com outras recomendações. Além disso, precisam ser avaliadas para o ambiente antes de ser aplicadas. Em alguns casos (por exemplo, cargas de trabalho de multilocação), essas recomendações podem ser mais relevantes. |
Pontuação da recomendação
No comparativo de mercado CIS do GKE
Pontuação | Descrição |
---|---|
Pontuou |
As recomendações têm um valor que pode ser avaliado de forma definitiva e são facilmente testadas usando um método automatizado. Essas recomendações incluem apenas produtos ou recursos com disponibilidade geral. |
Não pontuou |
As recomendações não podem ser facilmente avaliadas usando a automação ou exigem avaliação para determinar a implementação exata apropriada para a carga de trabalho. Pode ser que essas recomendações usem produtos ou recursos Beta. Por exemplo, a política de segurança de pods requer o uso de uma política específica para a carga de trabalho e é um recurso Beta, portanto, não é pontuado. |
Avaliação no GKE
Para recomendações específicas do GKE (seção 6), já que todas são configuráveis de modo que possam ser configuradas para "Aprovado" no seu ambiente, usamos os seguintes valores para especificar os valores padrão:
Status | Descrição |
---|---|
Padrão | Por padrão, um novo cluster está em conformidade com uma recomendação do comparativo de mercado. |
Não é o padrão | Por padrão, um novo cluster não está em conformidade com uma recomendação do comparativo de mercado. |
Depende do ambiente | O GKE não configura itens relacionados a esta recomendação. A configuração do usuário determina se o ambiente está em conformidade com uma recomendação do comparativo de mercado. |
Valores padrão no GKE
Ao criar um novo cluster do GKE com a versão especificada, veja o desempenho dele em relação ao CIS Benchmark do Kubernetes.
Status do cluster padrão do GKE:
Nº | Recomendação | Pontuou/Não pontuou | Nível | Status padrão |
---|---|---|---|---|
6 | Serviços gerenciados | |||
6.1 | Registro e verificação de imagens | |||
6.1.1 | Garantir a verificação da vulnerabilidades de imagens usando o Container Analysis do GCR ou um fornecedor de terceiros | Pontuou | N1 | Não é o padrão |
6.1.2 | Minimizar o acesso do usuário ao GCR | Pontuou | N1 | Depende do ambiente |
6.1.3 | Minimizar o acesso ao cluster como somente leitura para o GCR | Pontuou | N1 | Não é o padrão |
6.1.4 | Minimizar os registros de contêiner para apenas aqueles aprovados | Não pontuou | N2 | Não é o padrão |
6.2 | Gerenciamento de identidade e acesso (IAM) | |||
6.2.1 | Não executar clusters do GKE usando a conta de serviço padrão do Compute Engine | Pontuou | N2 | Não é o padrão |
6.2.2 | Prefira usar as contas de serviço e o recurso Identidade da carga de trabalho do Google Cloud dedicadas | Não pontuou | N1 | Não é o padrão |
6.3 | Cloud Key Management Service (Cloud KMS) | |||
6.3.1 | Criptografar secrets do Kubernetes usando chaves gerenciadas no Cloud KMS | Pontuou | N1 | Não é o padrão |
6.4 | Metadados do nó | |||
6.4.1 | Verificar se as APIs de metadados da instância legada do Compute Engine estão desativadas | Pontuou | N1 | Padrão |
6.4.2 | Verificar se o servidor de metadados do GKE está ativado | Não pontuou | N2 | Não é o padrão |
6.5 | Configuração e manutenção de nós | |||
6.5.1 | Verificar se o Container-Optimized OS (COS) é usado para imagens de nó do GKE | Pontuou | N2 | Padrão |
6.5.2 | Verificar se o reparo automático de nós está ativado para os nós do GKE | Pontuou | N1 | Padrão |
6.5.3 | Verificar se o upgrade automático está ativado para os nós do GKE | Pontuou | N1 | Padrão |
6.5.4 | Considerar automatizar o gerenciamento de versões do GKE usando canais de lançamento | Não pontuou | N1 | Não é o padrão |
6.5.5 | Verificar se os nós do GKE protegidos estão ativados | Não pontuou | N1 | Não é o padrão |
6.5.6 | Verificar se o monitoramento de integridade para os nós protegidos do GKE está ativado | Não pontuou | N1 | Não é o padrão |
6.5.7 | Verificar se a inicialização segura para os nós protegidos do GKE está ativada | Não pontuou | N2 | Não é o padrão |
6.6 | Rede de cluster | |||
6.6.1 | Considerar ativar os registros de fluxo de VPC e a visibilidade intranós | Não pontuou | N2 | Não é o padrão |
6.6.2 | Preferir clusters nativos de VPC | Pontuou | N1 | Não é o padrão |
6.6.3 | Verificar se a rede autorizada principal está ativada | Pontuou | N1 | Não é o padrão |
6.6.4 | Verificar se os clusters foram criados com o endpoint particular ativado e o acesso público desativado | Pontuou | N2 | Não é o padrão |
6.6.5 | Verificar se os clusters foram criados com os nós particulares | Pontuou | N1 | Não é o padrão |
6.6.6 | Usar firewall nos nós de trabalho do GKE | Não pontuou | N1 | Não é o padrão |
6.6.7 | Verificar se a política de rede está ativada e fazer as configurações adequadas | Não pontuou | N1 | Não é o padrão |
6.6.8 | Usar certificados SSL gerenciados pelo Google | Não pontuou | N2 | Depende do ambiente |
6.7 | Logging | |||
6.7.1 | Verificar se o Stackdriver Kubernetes Logging e Monitoring estão ativados | Pontuou | N1 | Padrão |
6.7.2 | Ativar a geração de registros de auditoria do Linux | Não pontuou | N2 | Não é o padrão |
6.8 | Autenticação e autorização | |||
6.8.1 | Verificar se a autenticação básica com senhas estáticas está desativada | Pontuou | N1 | Padrão |
6.8.2 | Verificar se a autenticação com certificados do cliente está desativada | Pontuou | N1 | Padrão |
6.8.3 | Gerenciar usuários RBAC do Kubernetes com os Grupos do Google para RBAC | Não pontuou | N2 | Não é o padrão |
6.8.4 | Verificar se a autorização legada (ABAC) está desativada | Pontuou | N1 | Padrão |
6.9 | Armazenamento | |||
6.9.1 | Considere ativar as chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) para discos permanentes (PDs, na sigla em inglês) do GKE | Não pontuou | N1 | Não é o padrão |
6.10 | Outras configurações de cluster | |||
6.10.1 | Verificar se a IU da Web do Kubernetes está desativada | Pontuou | N1 | Padrão |
6.10.2 | Verificar se os clusters Alfa não são usados para cargas de trabalho de produção | Pontuou | N1 | Padrão |
6.10.3 | Verificar se a política de segurança de pods está ativada e fazer as configurações adequadas | Não pontuou | N1 | Não é o padrão |
6.10.4 | Considerar o GKE Sandbox para executar cargas de trabalho não confiáveis | Não pontuou | N2 | Não é o padrão |
6.10.5 | Ativar a autorização binária e configurar a política conforme apropriado | Não pontuou | N2 | Não é o padrão |
6.10.6 | Ativar o Cloud Security Command Center (Cloud SCC) | Não pontuou | N1 | Não é o padrão |
Como auditar os comparativos de mercado
Instruções específicas para a auditoria de cada recomendação estão disponíveis como parte do comparativo de mercado CIS correspondente. No entanto, convém automatizar algumas dessas verificações para simplificar a verificação desses controles no seu ambiente. As ferramentas listadas abaixo podem ajudar com isso.
Isso não permite fazer auditoria das recomendações do comparativo de mercado CIS do Kubernetes que não são auditáveis no GKE. Para componentes que não podem ser auditados diretamente, consulte Valores padrão para entender como o ambiente já está configurado pelo GKE.
Auditoria automatizada do CIS Benchmark do Kubernetes
É possível usar uma ferramenta de código aberto kube-bench
para testar a configuração do cluster em relação ao comparativo de mercado CIS do Kubernetes. Não
será possível executar os testes kube-bench master
nas
cargas de trabalho do GKE, já que você não tem acesso direto ao nó do
plano de controle e só poderá executar os testes kube-bench node
.
Especifique a versão apropriada. Por exemplo:
kube-bench node --benchmark cis-1.5
Auditoria automatizada do comparativo de mercado CIS do GKE
O Security Health Analytics identifica configurações incorretas comuns no ambiente, como firewalls abertos ou buckets públicos. Isso inclui as recomendações de segurança do GKE. Ao ativar o Security Health Analytics, você será notificado sobre configurações incorretas do cluster que podem ocorrer no Cloud Security Command Center.
Muitas recomendações com pontuação de nível 1 são amparadas pelas descobertas correspondentes no Security Health Analytics.
Nº | Recomendação | Pontuou/Não pontuou | Nível | Descobertas do Security Health Analytics |
---|---|---|---|---|
6.1 | Registro e verificação de imagens | |||
6.1.1 | Garantir a verificação da vulnerabilidades de imagens usando o Container Analysis do GCR ou um fornecedor de terceiros | Pontuou | N1 | n/a |
6.1.2 | Minimizar o acesso do usuário ao GCR | Pontuou | N1 | n/a |
6.1.3 | Minimizar o acesso ao cluster como somente leitura para o GCR | Pontuou | N1 | n/a |
6.1.4 | Minimizar os registros de contêiner para apenas aqueles aprovados | Não pontuou | N2 | n/a |
6.2 | Gerenciamento de identidade e acesso (IAM) | |||
6.2.1 | Não executar clusters do GKE usando a conta de serviço padrão do Compute Engine | Pontuou | N2 | OVER_PRIVILEGED_ACCOUNT e OVER_PRIVILEGED_SCOPES |
6.2.2 | Prefira usar as contas de serviço e o recurso Identidade da carga de trabalho do Google Cloud dedicadas | Não pontuou | N1 | WORKLOAD_IDENTITY_DISABLED |
6.3 | Cloud Key Management Service (Cloud KMS) | |||
6.3.1 | Criptografar secrets do Kubernetes usando chaves gerenciadas no Cloud KMS | Pontuou | N1 | n/a |
6.4 | Metadados do nó | |||
6.4.1 | Verificar se as APIs de metadados da instância legada do Compute Engine estão desativadas | Pontuou | N1 | LEGACY_METADATA_ENABLED |
6.4.2 | Verificar se o servidor de metadados do GKE está ativado | Não pontuou | N2 | n/a |
6.5 | Configuração e manutenção de nós | |||
6.5.1 | Verificar se o Container-Optimized OS (COS) é usado para imagens de nó do GKE | Pontuou | N2 | COS_NOT_USED |
6.5.2 | Verificar se o reparo automático de nós está ativado para os nós do GKE | Pontuou | N1 | AUTO_REPAIR_DISABLED |
6.5.3 | Verificar se o upgrade automático está ativado para os nós do GKE | Pontuou | N1 | AUTO_UPGRADE_DISABLED |
6.5.4 | Considerar automatizar o gerenciamento de versões do GKE usando canais de lançamento | Não pontuou | N1 | n/a |
6.5.5 | Verificar se os nós do GKE protegidos estão ativados | Não pontuou | N1 | n/a |
6.5.6 | Verificar se o monitoramento de integridade para os nós protegidos do GKE está ativado | Não pontuou | N1 | n/a |
6.5.7 | Verificar se a inicialização segura para os nós protegidos do GKE está ativada | Não pontuou | N2 | n/a |
6.6 | Rede de cluster | |||
6.6.1 | Considerar ativar os registros de fluxo de VPC e a visibilidade intranós | Não pontuou | N2 | FLOW_LOGS_DISABLED |
6.6.2 | Preferir clusters nativos de VPC | Pontuou | N1 | IP_ALIAS_DISABLED |
6.6.3 | Verificar se a rede autorizada principal está ativada | Pontuou | N1 | MASTER_AUTHORIZED_NETWORKS_DISABLED |
6.6.4 | Verificar se os clusters foram criados com o endpoint particular ativado e o acesso público desativado | Pontuou | N2 | n/a |
6.6.5 | Verificar se os clusters foram criados com os nós particulares | Pontuou | N1 | PRIVATE_CLUSTER_DISABLED |
6.6.6 | Usar firewall nos nós de trabalho do GKE | Não pontuou | N1 | n/a |
6.6.7 | Verificar se a política de rede está ativada e fazer as configurações adequadas | Não pontuou | N1 | NETWORK_POLICY_DISABLED |
6.6.8 | Usar certificados SSL gerenciados pelo Google | Não pontuou | N2 | n/a |
6.7 | Logging | |||
6.7.1 | Verificar se o Stackdriver Kubernetes Logging e Monitoring estão ativados | Pontuou | N1 | CLUSTER_LOGGING_DISABLED e CLUSTER_MONITORING_DISABLED |
6.7.2 | Ativar a geração de registros de auditoria do Linux | Não pontuou | N2 | n/a |
6.8 | Autenticação e autorização | |||
6.8.1 | Verificar se a autenticação básica com senhas estáticas está desativada | Pontuou | N1 | n/a |
6.8.2 | Verificar se a autenticação com certificados do cliente está desativada | Pontuou | N1 | n/a |
6.8.3 | Gerenciar usuários RBAC do Kubernetes com os Grupos do Google para RBAC | Não pontuou | N2 | n/a |
6.8.4 | Verificar se a autorização legada (ABAC) está desativada | Pontuou | N1 | LEGACY_AUTHORIZATION_ENABLED |
6.9 | Armazenamento | |||
6.9.1 | Considere ativar as chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) para discos permanentes (PDs, na sigla em inglês) do GKE | Não pontuou | N1 | n/a |
6.10 | Outras configurações de cluster | |||
6.10.1 | Verificar se a IU da Web do Kubernetes está desativada | Pontuou | N1 | WEB_UI_ENABLED |
6.10.2 | Verificar se os clusters Alfa não são usados para cargas de trabalho de produção | Pontuou | N1 | n/a |
6.10.3 | Verificar se a política de segurança de pods está ativada e fazer as configurações adequadas | Não pontuou | N1 | POD_SECURITY_POLICY_DISABLED |
6.10.4 | Considerar o GKE Sandbox para executar cargas de trabalho não confiáveis | Não pontuou | N2 | n/a |
6.10.5 | Ativar a autorização binária e configurar a política conforme apropriado | Não pontuou | N2 | n/a |
6.10.6 | Ativar o Cloud Security Command Center (Cloud SCC) | Não pontuou | N1 | n/a |
A seguir
- Leia a Visão geral de segurança do GKE.
- Siga as práticas recomendadas de segurança no guia de aumento da proteção do GKE.
- Saiba mais sobre o modelo de responsabilidade compartilhada no GKE.