Comparativos do CIS

Autopilot Standard

Nesta página, descrevemos a abordagem do Google Kubernetes Engine (GKE) para melhorar a conformidade com os comparativos de mercado do Center for Internet Security (CIS) para Kubernetes e para GKE. Esta página inclui as seguintes informações:

Como configuramos o plano de controle do GKE gerenciado para estar em conformidade com o comparativo de mercado CIS do Kubernetes
Como configurar os nós e as cargas de trabalho do GKE para estar em conformidade com o comparativo de mercado CIS do Google Kubernetes Engine (GKE)

Sobre os comparativos de mercado CIS

O CIS lança os seguintes comparativos de mercado que contêm diretrizes de configuração seguras para o Kubernetes:

Comparativo de mercado CIS do Kubernetes: aplica-se ao projeto de código aberto do Kubernetes. Fornece orientação sobre várias implementações autogerenciadas e hospedadas do Kubernetes.
Comparativo de mercado CIS do GKE: define diretrizes para a configuração segura dos componentes que podem ser controlados nos clusters do GKE. Inclui recomendações específicas para o GKE no Google Cloud.

Recomendamos que você priorize o comparativo de mercado CIS do GKE, porque ele é específico para o GKE no Google Cloud. O comparativo de mercado CIS do Kubernetes contém muitas recomendações para controles que não é possível visualizar ou modificar no GKE. Nossa abordagem de segurança de cluster inclui mitigações que vão além do escopo do comparativo de mercado de código aberto do Kubernetes e podem resultar em conflitos com essas recomendações.

Outros comparativos de mercado que se aplicam ao GKE

Além do comparativo de mercado CIS do GKE e do Kubernetes, os comparativos de mercado a seguir se aplicam aos sistemas operacionais disponíveis no GKE. Mesmo que um comparativo de mercado específico não aborde explicitamente o uso do Kubernetes, ainda é necessário fazer referência a ele para orientações adicionais de segurança.

Container-Optimized OS Benchmark: o sistema operacional padrão instalado em todos os nós do GKE Linux
Comparativo de mercado do Linux do Ubuntu: disponível para o GKE Standard
Comparativo de mercado do Windows Server: disponível para o GKE Standard

O ambiente de execução padrão do contêiner, o containerd, não tem uma comparação.

Modelo de responsabilidade compartilhada

Com base no modelo de responsabilidade compartilhada do GKE, gerenciamos os seguintes componentes para você:

O plano de controle, incluindo as VMs do plano de controle, o servidor de API e componentes como etcd, kube-controller-manager e kube-scheduler.
O sistema operacional do nó.

Esses componentes existem em um projeto do GKE. Por isso, não é possível modificar ou avaliar nenhum deles em relação aos controles correspondentes do comparativo de mercado CIS. No entanto, é possível avaliar e corrigir todos os controles do comparativo de mercado CIS se aplicam aos nós de trabalho e às cargas de trabalho. Com base no modelo de responsabilidade compartilhada do GKE, esses componentes são de sua responsabilidade.

Nossa abordagem para proteger o GKE no comparativo de mercado CIS

O GKE é uma implementação gerenciada do Kubernetes de código aberto. Nós gerenciamos totalmente o plano de controle e somos responsáveis por proteger a configuração dos componentes dele. A tabela a seguir descreve algumas de nossas decisões que podem afetar a pontuação dos comparativos de mercado do CIS:

Abordagem de segurança do GKE
Proporção de Eficiência Energética (EER)	Alguns componentes de monitoramento do GKE usam autenticação anônima para conseguir as métricas. O GKE permite a autenticação anônima para o kubelet, mas essa exposição é idêntica à porta somente leitura porque desativamos outros gerenciadores de depuração. Alguns componentes do plano de controle são inicializados usando tokens estáticos, que são usados para autenticação no servidor de API. Esses tokens são gerados sempre que uma VM é iniciada ou reiniciada.
Controladores de admissão	O GKE desativa os seguintes controladores de admissão: EventRateLimit: este é um recurso alfa no Kubernetes AlwaysPullImages: esse controlador fornece alguma proteção para imagens de registro particulares em clusters multilocatários não cooperativos, ao custo de tornar os registros de imagem um único ponto de falha para criar novos pods na cluster especificado. SecurityContextDeny: é recomendável usar o controlador de admissão de segurança do pod. Disponível em todas as edições do GKE. Se você usa o GKE Enterprise, também pode ativar a aplicação dos padrões de segurança de pods usando o Policy Controller. ImagePolicyWebhook o GKE desativa o ImagePolicyWebhook por padrão porque tem seus próprios mecanismos para gerenciamento e segurança de imagens. Isso permite que o GKE tenha um controle mais rigoroso sobre o ambiente e garanta que as práticas de segurança sejam aplicadas de maneira consistente. No entanto, é possível usar a autorização binária ou o Policy Controller para gerenciamento de políticas.
Registro de auditoria	O GKE captura registros de auditoria usando a política de auditoria do GKE. Como resultado, não precisamos definir nenhuma flag de geração de registros de auditoria do servidor da API Kubernetes.
Depuração	O GKE usa a criação de perfil para depuração.
Criptografia	O GKE criptografa o conteúdo do cliente em repouso por padrão. Também é possível usar uma chave gerenciada para criptografar seus dados. Para detalhes, consulte Criptografar secrets na camada do aplicativo. O GKE usa mTLS para tráfego entre instâncias do etcd, entre o servidor da API e o etcd e entre o plano de controle e os nós. Para detalhes, consulte Confiança do cluster.
kubelet	O GKE ativa a porta somente leitura do kubelet não autenticada. O modo GKE Standard permite que as cargas de trabalho modifiquem os padrões do kernel, se necessário. O GKE limita o número de eventos do Kubernetes no kubelet para reduzir o risco de ataques de negação de serviço. O GKE usa mTLS para proteger o tráfego entre o kubelet e o servidor da API. O GKE alterna os certificados do servidor por padrão e alterna os certificados do cliente quando os nós protegidos do GKE estão ativados. O GKE usa o conjunto de criptografia padrão permitida da golang, que também é o padrão para o Kubernetes.

Avalie o GKE em relação aos comparativos de mercado CIS

É possível automatizar a avaliação dos clusters em relação aos comparativos de mercado usando um dos seguintes métodos:

CIS Benchmark do GKE:
- Edição GKE Enterprise: use o painel "Compliance" para avaliar a conformidade de todos os clusters com o comparativo de mercado CIS do GKE. Para detalhes, consulte Sobre o painel de conformidade do GKE.
- Todas as edições do GKE:
- Execute kube-bench para avaliar os nós de trabalho em relação ao comparativo de mercado. Para mais detalhes, consulte o repositório kube-bench do GitHub.
- Use uma ferramenta de terceiros, como o Twistlock Defender, para avaliar os nós em relação ao comparativo de mercado.
Comparativo de mercado CIS do Kubernetes: execute kube-bench para avaliar os nós de trabalho em relação ao comparativo de mercado.

Observação: não é possível avaliar o plano de controle gerenciado em relação a essas recomendações no comparativo de mercado.

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 como monitorar seus clusters em busca de problemas de segurança com a postura de segurança do GKE.
Saiba como avaliar seus clusters em busca de problemas de conformidade no painel de conformidade do GKE para o GKE Enterprise.