Referências do CIS

Esta página descreve a abordagem que o Google Kubernetes Engine (GKE) adota para melhorar a conformidade com as referências do Centro para a Segurança da Internet (CIS) para o Kubernetes e o GKE. Esta página inclui as seguintes informações:

  • Como configuramos o plano de controlo do GKE gerido para estar em conformidade com a referência do CIS Kubernetes
  • Como pode configurar os seus nós e cargas de trabalho do GKE para estarem em conformidade com a referência do CIS Google Kubernetes Engine (GKE)

Acerca das referências do CIS

O CIS lança as seguintes referências que contêm diretrizes de configuração segura para o Kubernetes:

  • CIS Kubernetes Benchmark: aplica-se ao projeto Kubernetes de código aberto. Destinadas a fornecer orientações para uma variedade de implementações do Kubernetes autogeridas e alojadas.
  • Referência do GKE do CIS: estabelece diretrizes para a configuração segura de componentes que pode controlar em clusters do GKE. Inclui recomendações específicas do GKE no Trusted Cloud by S3NS.

Recomendamos que dê prioridade à norma de referência do GKE do CIS, porque é específica do GKE no Trusted Cloud. A norma CIS Kubernetes contém muitas recomendações para controlos que não pode ver nem modificar no GKE. A nossa abordagem à segurança dos clusters inclui mitigações que vão além do âmbito da referência do Kubernetes de código aberto e podem resultar em conflitos com essas recomendações.

Outros testes de referência aplicáveis ao GKE

Além da CIS GKE Benchmark e da CIS Kubernetes Benchmark, as seguintes referências aplicam-se aos sistemas operativos disponíveis no GKE. Mesmo que uma referência específica do SO não aborde explicitamente a utilização do Kubernetes, deve continuar a consultar essa referência para obter orientações de segurança adicionais.

O tempo de execução do contentor predefinido, o containerd, não tem um teste de referência.

Modelo de responsabilidade partilhada

Com base no modelo de responsabilidade partilhada do GKE, gerimos os seguintes componentes por si:

  • O plano de controlo, incluindo as VMs do plano de controlo, o servidor da API e os componentes, como a base de dados do estado do cluster (baseada em etcd ou Spanner), o kube-controller-manager e o kube-scheduler.
  • O sistema operativo do nó.

Estes componentes existem num projeto pertencente ao GKE, pelo que não pode modificar nem avaliar nenhum destes componentes em relação aos controlos de referência da CIS correspondentes. No entanto, pode avaliar e corrigir quaisquer controlos de testes de referência da CIS que se apliquem aos seus nós de trabalho e cargas de trabalho. Com base no modelo de responsabilidade partilhada do GKE, estes componentes são da sua responsabilidade.

A nossa abordagem à proteção do GKE para a referência CIS

O GKE é uma implementação gerida do Kubernetes de código aberto. Gerimos totalmente o plano de controlo e somos responsáveis por proteger a configuração dos componentes do plano de controlo. A tabela seguinte descreve algumas das nossas decisões que podem afetar a classificação das referências do CIS:

Abordagem de segurança do GKE
Autenticação
  • Alguns componentes de monitorização do GKE usam a autenticação anónima para obter métricas.
  • Alguns componentes do plano de controlo são inicializados através de tokens estáticos, que são depois usados para autenticar no servidor da API. Estes 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: esta é uma funcionalidade alfa no Kubernetes
  • AlwaysPullImages: este controlador oferece alguma proteção para imagens de registo privado em clusters multiinquilinos não cooperativos, ao custo de tornar os registos de imagens um único ponto de falha para criar novos pods no cluster.
  • SecurityContextDeny: o controlador de admissão de segurança de pods é preferível e está disponível em todas as edições do GKE. Também pode ativar a aplicação das normas de segurança de pods através do Policy Controller.
  • ImagePolicyWebhook: o GKE desativa o ImagePolicyWebhook por predefinição porque tem os seus próprios mecanismos para gestão e segurança de imagens. Isto permite que o GKE mantenha um controlo mais rigoroso sobre o ambiente e garante que as respetivas práticas de segurança são aplicadas de forma consistente. No entanto, pode usar a autorização binária ou o Policy Controller para a gestão de políticas.
Registo de auditoria O GKE captura registos de auditoria através da política de auditoria do GKE. Como resultado, não precisamos de definir nenhuma flag de registo de auditoria do servidor da API Kubernetes.
Depuração O GKE usa a criação de perfis para a depuração.
Encriptação
etcd

No Kubernetes de código aberto, a base de dados de estado do cluster usa o etcd. No GKE, a base de dados de back-end que armazena o estado do cluster é uma das seguintes tecnologias:

  • etcd: o cluster executa instâncias do etcd no plano de controlo.
  • Spanner: o GKE armazena o estado do cluster numa base de dados baseada no Spanner que está separada das VMs do plano de controlo.

Todos os clusters do GKE publicam a API etcd em VMs do plano de controlo. Todas as interações do cliente com a API Kubernetes são iguais às do Kubernetes de código aberto. Consoante a tecnologia de base de dados que é o back-end para a API etcd no seu cluster, pode notar discrepâncias em qualquer classificação relacionada com o etcd no teste de referência do CIS Kubernetes de código aberto.
kubelet
  • O GKE ativa a porta só de leitura do kubelet não autenticada. Pode desativar a porta definindo --no-autoprovisioning-enable-insecure-kubelet-readonly-port. A porta só de leitura vai ser desativada por predefinição numa versão futura, depois de lhe concedermos algum tempo para fazer a migração.
  • O modo Standard do GKE permite que as suas cargas de trabalho modifiquem as predefiniçõ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 o mTLS para proteger o tráfego entre o kubelet e o servidor da API.
  • Por predefinição, o GKE roda os certificados do servidor e roda os certificados de cliente quando os nós do GKE protegidos estão ativados.
  • O GKE usa o conjunto de cifras permitidas predefinido do golang, que também é a predefinição do Kubernetes.

Avalie o GKE em função das referências da CIS

Pode automatizar a avaliação dos seus clusters em relação às referências através de um dos seguintes métodos:

  • CIS GKE Benchmark:
    • Execute kube-bench para avaliar os nós de trabalho em comparação com a referência. Para mais detalhes, consulte o repositório do GitHub kube-bench.
    • Use uma ferramenta de terceiros, como o Twistlock Defender, para avaliar os nós em comparação com a referência.
  • Referência do CIS Kubernetes: execute kube-bench para avaliar os nós de trabalho em comparação com a referência. Não pode avaliar o plano de controlo gerido em função dessas recomendações no teste de referência.

O que se segue?