CIS Benchmarks

Este documento apresenta o CIS Benchmark do Kubernetes e explica como auditar sua compliance com o comparativo de mercado. Para recomendações que não podem ser implementadas por conta própria, o documento explica o que o GDCV para Bare Metal faz para lidar com a 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 comparativo de mercado CIS do Kubernetes apresenta um conjunto de recomendações para configurar o Kubernetes para ser compatível com uma forte postura de segurança. O comparativo de mercado está vinculado a uma versão específica do Kubernetes. O comparativo de mercado CIS 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.

Versões

A tabela a seguir lista as versões do GKE em Bare Metal, do Kubernetes e o comparativo de mercado CIS do Kubernetes que foram usados para realizar a avaliação descrita neste documento:

Versão Anthos Versão do Kubernetes Versão do comparativo de mercado CIS do Kubernetes
1.16.0 1.27.4 Versão 1.23 (1.0.1)

Os números de versão para diferentes comparativos de mercado podem não ser os mesmos.

CIS Benchmark 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:

  • sejam práticas e prudentes;
  • forneçam um benefício de segurança claro;
  • não inibam a utilidade da tecnologia para além dos meios aceitáveis.
  • Nível 2

    Amplia o perfil de nível 1.

    As recomendações exibem uma ou mais das seguintes características:

  • São destinadas a ambientes ou casos de uso em que a segurança é fundamental.
  • Atuam como medidas de defesa em profundidade.
  • podem inibir negativamente a utilidade ou o desempenho da tecnologia.
  • Status da avaliação

    O status da avaliação será incluído em todas as recomendações. O status da avaliação indica se a recomendação pode ser automatizada ou requer etapas manuais para a implementação. Ambos os status são igualmente importantes, e são determinados e têm suporte conforme definido abaixo:

    Pontuação Descrição
    Automatizado Representa recomendações para que avaliações de controle técnico possam ser totalmente automatizadas e validadas para um estado de aprovação/reprovação. As recomendações incluem as informações necessárias para implementar a automação.
    Manual Representa as recomendações para avaliações de controle técnico que não podem ser totalmente automatizadas e exige que todas ou algumas etapas manuais sejam feitas para confirmar se o estado configurado está definido como esperado. O estado esperado pode variar dependendo do ambiente.

    Avaliação no GKE em Bare Metal

    Usamos os seguintes valores para especificar o status das recomendações do Kubernetes no GKE em Bare Metal:

    Status Descrição
    Aprovado Está em conformidade com uma recomendação de comparativo de mercado.
    Reprovado Não está em conformidade com uma recomendação de comparativo de mercado.
    Controle equivalente Não está em conformidade com os termos exatos da recomendação de comparativo de mercado, mas há outros mecanismos no GKE em bare metal para fornecer controles de segurança equivalentes.
    Depende do ambiente O GKE em Bare Metal 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 de comparativo de mercado.

    GKE em arquitetura bare metal

    O GKE em Bare Metal oferece suporte a várias configurações e tipos de cluster. Cada tipo de cluster compatível, administrador, usuário, híbrido e independente, é avaliado em relação ao comparativo de mercado do CIS. As avaliações e justificativas a seguir se aplicam a todos os tipos de cluster compatíveis. Mais informações sobre as configurações de cluster com suporte do GKE em Bare Metal podem ser encontradas em Como escolher modelos de implantação.

    Status no GKE em Bare Metal

    As seções a seguir contêm as avaliações para novos clusters criados com a versão especificada do GKE em Bare Metal. Essas avaliações são um indicador do desempenho de novos clusters sem cargas de trabalho do usuário em relação ao comparativo de mercado CIS do Kubernetes. Se você implantar suas próprias cargas de trabalho antes de fazer a auditoria dos comparativos de mercado, os resultados poderão ser diferentes.

    Status dos clusters do GKE em Bare Metal:

    # Recomendação Nível Status
    1 cis-1.23
    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 (automatizado) L1 Pass
    1.1.2 Verificar se a propriedade do arquivo de especificação do pod do servidor de API está definida como root:root (automatizado) L1 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 (automatizado) L1 Aprovado
    1.1.4 Verificar se a propriedade do arquivo de especificação do pod do gerenciador de controladores está definida como root:root (automatizado) L1 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 (automatizado) L1 Aprovado
    1.1.6 Verificar se a propriedade do arquivo de especificação do pod do programador está definida como root:root (automatizado) L1 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 (automatizado) L1 Pass
    1.1.8 Verificar se a propriedade do arquivo de especificação do pod do etcd está definida como root:root (automatizado) L1 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 (manual) L1 Controle equivalente
    1.1.10 Verificar se a propriedade do arquivo da interface de rede do contêiner está definida como root:root (manual) L1 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 (automatizado) L1 Controle equivalente
    1.1.12 Verificar se a propriedade do diretório de dados do etcd está definida como etcd:etcd (automatizado) L1 Controle equivalente
    1.1.13 Verificar se as permissões do arquivo admin.conf estão definidas como 600 ou são mais restritivas (automatizado) L1 Aprovado
    1.1.14 Verificar se a propriedade do arquivo admin.conf está definida como root:root (automatizado) L1 Aprovado
    1.1.15 Verificar se as permissões do arquivo scheduler.conf estão definidas como 644 ou são mais restritivas (automatizado) L1 Aprovado
    1.1.16 Verificar se a propriedade do arquivo scheduler.conf está definida como root:root (automatizado) L1 Controle equivalente
    1.1.17 Verificar se as permissões do arquivo controller-manager.conf estão definidas como 644 ou são mais restritivas (automatizado) L1 Aprovado
    1.1.18 Verificar se a propriedade do arquivo controller-manager.conf está definida como root:root (automatizado) L1 Controle equivalente
    1.1.19 Verificar se o diretório PKI do Kubernetes e a propriedade do arquivo estão definidos como root:root (automatizado) L1 Controle equivalente
    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 (manual) L1 Aprovado
    1.1.21 Verificar se as permissões do arquivo de chave PKI do Kubernetes estão definidas como 600 (manual) L1 Controle equivalente
    1.2 Servidor de API
    1.2.1 Verificar se o argumento --anonymous-auth está definido como falso (manual) L1 Alerta
    1.2.2 Verificar se o parâmetro --token-auth-file não está definido (automatizado) L1 Aprovado
    1.2.3 Verificar se --DenyServiceExternalIPs não está definido (automatizado) L1 Pass
    1.2.4 Verificar se o argumento --kubelet-https está definido como verdadeiro (automatizado) L1 Aprovado
    1.2.5 Verificar se os argumentos --kubelet-client-certificate e --kubelet-client-key estão definidos conforme apropriado (automatizados) L1 Aprovado
    1.2.6 Verificar se o argumento --kubelet-certificate-authority está definido conforme apropriado (automatizado) L1 Aprovado
    1.2.7 Verificar se o argumento --authorization-mode não está definido como AlwaysAllow (automatizado) L1 Aprovado
    1.2.8 Verificar se o argumento --authorization-mode inclui o nó (automatizado) L1 Aprovado
    1.2.9 Verificar se o argumento --authorization-mode inclui o RBAC (automatizado) L1 Pass
    1.2.10 Verificar se o plug-in de controle de admissão EventRateLimit está definido (manual) L1 Alerta
    1.2.11 Verificar se o plug-in de controle de admissão AlwaysAdmit não está definido (automatizado) L1 Pass
    1.2.12 Verificar se o plug-in de controle de admissão AlwaysPullImages está definido (manual) L1 Alerta
    1.2.13 Verificar se o plug-in de controle de admissão SecurityContextDeny está definido, se PodSecurityPolicy não estiver sendo usado (manual) L1 Avisar
    1.2.14 Verificar se o plug-in de controle de admissão ServiceAccount está definido (automatizado) L1 Aprovado
    1.2.15 Verificar se o plug-in de controle de admissão NamespaceLifecycle está definido (automatizado) L1 Aprovado
    1.2.16 Verificar se o plug-in de controle de admissão NodeRestriction está definido (automatizado) L1 Aprovado
    1.2.17 Verificar se o argumento --secure-port não está definido como 0 (automatizado) L1 Aprovado
    1.2.18 Verificar se o argumento --profiling está definido como falso (automatizado) L1 Aprovado
    1.2.19 Verificar se o argumento --audit-log-path está definido (automatizado) L1 Reprovado
    1.2.20 Verificar se o argumento --audit-log-maxage está definido como 30 ou conforme apropriado (automatizado) L1 Reprovado
    1.2.21 Verificar se o argumento --audit-log-maxbackup está definido como 10 ou conforme apropriado (automatizado) L1 Reprovado
    1.2.22 Verificar se o argumento --audit-log-maxsize está definido como 100 ou conforme apropriado (automatizado) L1 Falha
    1.2.23 Verificar se o argumento --request-timeout está definido conforme apropriado (manual) L1 Aprovado
    1.2.24 Verificar se o argumento --service-account-lookup está definido como verdadeiro (automatizado) L1 Aprovado
    1.2.25 Verificar se o argumento --service-account-key-file está definido conforme apropriado (automatizado) L1 Aprovado
    1.2.26 Verificar se os argumentos --etcd-certfile e --etcd-keyfile estão definidos conforme apropriado (automatizados) L1 Aprovado
    1.2.27 Verificar se os argumentos --tls-cert-file e --tls-private-key-file estão definidos conforme apropriado (automatizados) L1 Aprovado
    1.2.28 Verificar se o argumento --client-ca-file está definido conforme apropriado (automatizado) L1 Aprovado
    1.2.29 Verificar se o argumento --etcd-cafile está definido conforme apropriado (automatizado) L1 Aprovado
    1.2.30 Verificar se o argumento --encryption-provider-config está definido conforme apropriado (manual) L1 Aprovado
    1.2.31 Verificar se os provedores de criptografia estão configurados corretamente (manual) L1 Aprovado
    1.2.32 Verificar se o servidor de API usa apenas códigos criptográficos fortes (manual) L1 Aprovado
    1.3 Controller Manager
    1.3.1 Verificar se o argumento --terminated-pod-gc-threshold está definido conforme apropriado (manual) L1 Aprovado
    1.3.2 Verificar se o argumento --profiling está definido como falso (automatizado) L1 Aprovado
    1.3.3 Verificar se o argumento --use-service-account-credentials está definido como verdadeiro (automatizado) L1 Aprovado
    1.3.4 Verificar se o argumento --service-account-private-key-file está definido conforme apropriado (automatizado) L1 Aprovado
    1.3.5 Verificar se o argumento --root-ca-file está definido conforme apropriado (automatizado) L1 Aprovado
    1.3.6 Verificar se o argumento RotateKubeletServerCertificate está definido como verdadeiro (automatizado) L2 Aprovado
    1.3.7 Verificar se o argumento --bind-address está definido como 127.0.0.1 (automatizado) L1 Aprovado
    1.4 Programador
    1.4.1 Verificar se o argumento --profiling está definido como falso (automatizado) L1 Aprovado
    1.4.2 Verificar se o argumento --bind-address está definido como 127.0.0.1 (automatizado) L1 Aprovado
    2 cis-1.23
    2 Configuração de nó do etct
    2.1 Verificar se os argumentos --cert-file e --key-file estão definidos conforme apropriado (automatizados) L1 Aprovado
    2.2 Verificar se o argumento --client-cert-auth está definido como verdadeiro (automatizado) L1 Aprovado
    2.3 Verificar se o argumento --auto-tls não está definido como verdadeiro (automatizado) L1 Aprovado
    2.4 Verificar se os argumentos --peer-cert-file e --peer-key-file estão definidos conforme apropriado (automatizados) L1 Aprovado
    2,5 Verificar se o argumento --peer-client-cert-auth está definido como verdadeiro (automatizado) L1 Aprovado
    2.6 Verificar se o argumento --peer-auto-tls não está definido como verdadeiro (automatizado) L1 Aprovado
    2.7 Verificar se uma autoridade de certificação exclusiva é usada para o etcd (manual) L2 Aprovado
    3 cis-1.23
    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 (manual) L2 Aprovado
    3.2 Logging
    3.2.1 Verificar se uma política de auditoria mínima foi criada (manual) L1 Aprovado
    3.2.2 Verificar se a política de auditoria abrange as principais preocupações de segurança (manual) L2 Controle equivalente
    4 cis-1.23
    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 (automatizado) L1 Pass
    4.1.2 Verificar se a propriedade do arquivo de serviço do Kubelet está definida como root:root (automatizado) L1 Aprovado
    4.1.3 Se houver um arquivo kubeconfig do proxy, verificar se as permissões estão definidas como 644 ou são mais restritivas (manual) L1 Aprovado
    4.1.4 Se o arquivo kubeconfig de proxy existir, verifique se a propriedade está definida como root:root (Manual) L1 Aprovado
    4.1.5 Verificar se as permissões do arquivo kubelet.conf --kubeconfig estão definidas como 644 ou são mais restritivas (automatizado) L1 Aprovado
    4.1.6 Verificar se a propriedade do arquivo --kubeconfig kubelet.conf está definida como root:root (automatizado) L1 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 (manual) L1 Aprovado
    4.1.8 Verificar se a propriedade do arquivo de autoridades de certificação do cliente está definida como root:root (manual) L1 Aprovado
    4.1.9 Verificar se o arquivo de configuração do kubelet --config tem permissões definidas como 644 ou são mais restritivas (automatizado) L1 Pass
    4.1.10 Verificar se a propriedade do arquivo de configuração do kubelet --config está definida como root:root (automatizado) L1 Aprovado
    4.2 Kubelet
    4.2.1 Verificar se o argumento --anonymous-auth está definido como falso (automatizado) L1 Aprovado
    4.2.2 Verificar se o argumento --authorization-mode não está definido como AlwaysAllow (automatizado) L1 Aprovado
    4.2.3 Verificar se o argumento --client-ca-file está definido conforme apropriado (automatizado) L1 Aprovado
    4.2.4 Verificar se o argumento --read-only-port está definido como 0 (manual) L1 Reprovado
    4.2.5 Verificar se o argumento --streaming-connection-idle-timeout não está definido como 0 (manual) L1 Aprovado
    4.2.6 Verificar se o argumento --protect-kernel-defaults está definido como verdadeiro (automatizado) L1 Reprovado
    4.2.7 Verificar se o argumento --make-iptables-util-chains está definido como verdadeiro (automatizado) L1 Aprovado
    4.2.8 Verificar se o argumento --hostname-override não está definido (manual) L1 Aprovado
    4.2.9 Verificar se o argumento --event-qps está definido como 0 ou em um nível que garanta a captura apropriada do evento (manual) L2 Alerta
    4.2.10 Verificar se os argumentos --tls-cert-file e --tls-private-key-file estão definidos conforme apropriado (manual) L1 Controle equivalente
    4.2.11 Verificar se o argumento --rotate-certificates não está definido como falso (automatizado) L1 Aprovado
    4.2.12 Verificar se o argumento RotateKubeletServerCertificate está definido como verdadeiro (manual) L1 Aprovado
    4.2.13 Verificar se o Kubelet usa somente códigos criptográficos fortes (manual) L1 Controle equivalente
    Descrições de falhas e controles equivalentes para GKE no cluster de administrador bare metal:
    # Recomendação Nível Status Valor Justificativa
    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 (manual) L1 Controle equivalente 755 O caminho da interface dos clusters do Anthos em bare metal é /opt/cni/bin, e a permissão dele é definida como 755 para a operação normal do cluster.
    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 (automatizado) L1 Controle equivalente 755 O diretório de dados do etcd tem as permissões 755 padrão, mas os subdiretórios são 700.
    1.1.12 Verificar se a propriedade do diretório de dados do etcd está definida como etcd:etcd (automatizado) L1 Controle equivalente 2003:2003 O diretório de dados etcd, /var/lib/etcd, pertence a 2003:2003 como resultado do plano de controle sem raiz para maior segurança.
    1.1.16 Verificar se a propriedade do arquivo scheduler.conf está definida como root:root (automatizado) L1 Controle equivalente 2002:2002 Os clusters do Anthos em bare metal, a partir da versão 1.9.0, implementam um plano de controle sem raiz para reforçar a segurança.
    1.1.18 Verificar se a propriedade do arquivo controller-manager.conf está definida como root:root (automatizado) L1 Controle equivalente 2001:2001 Os clusters do Anthos em bare metal, a partir da versão 1.9.0, implementam um plano de controle sem raiz para reforçar a segurança.
    1.1.19 Verificar se o diretório PKI do Kubernetes e a propriedade do arquivo estão definidos como root:root (automatizado) L1 Controle equivalente variable:variable Os clusters do Anthos em bare metal, a partir da versão 1.9.0, implementam um plano de controle sem raiz para reforçar a segurança.
    1.1.21 Verificar se as permissões do arquivo de chave PKI do Kubernetes estão definidas como 600 (manual) L1 Controle equivalente 600~640 Os clusters do Anthos em bare metal, a partir da versão 1.9.0, implementam um plano de controle sem raiz para reforçar a segurança.
    1.2.1 Verificar se o argumento --anonymous-auth está definido como falso (manual) L1 Avisar não definido Alguns clusters do Anthos em operações bare metal, como HA, exigem a autenticação anônima.
    1.2.10 Verificar se o plug-in de controle de admissão EventRateLimit está definido (manual) L1 Avisar
    1.2.12 Verificar se o plug-in de controle de admissão AlwaysPullImages está definido (manual) L1 Avisar não definido O controlador de admissão AlwaysPullImages oferece alguma proteção para imagens de registros particulares em clusters multilocatários não cooperativos. Mas isso faz com que os registros do contêiner se tornem um único ponto de falha para criar novos pods em todo o cluster. Os clusters do Anthos em bare metal não ativam 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.
    1.2.13 Verificar se o plug-in de controle de admissão SecurityContextDeny está definido, se PodSecurityPolicy não estiver sendo usado (manual) L1 Avisar não definido Clusters do Anthos em bare metal não ativam a política de segurança de pods. A admissão de segurança dos pods é ativada nos clusters do Kubernetes 1.23 por padrão. Consulte https://kubernetes.io/docs/concepts/security/pod-security-admission/ (em inglês).
    1.2.19 Verificar se o argumento --audit-log-path está definido (automatizado) L1 Falha não é definido por padrão; definir /var/log/apiserver/audit.log somente se os Registros de auditoria do Cloud estiverem desativados Por padrão, os Clusters do Anthos em clusters bare metal enviam registros de auditoria do servidor da API Kubernetes para o Google Cloud.
    1.2.20 Verificar se o argumento --audit-log-maxage está definido como 30 ou conforme apropriado (automatizado) L1 Falha não é definido por padrão; definir 30 somente se os Registros de auditoria do Cloud estiverem desativados Por padrão, os Clusters do Anthos em clusters bare metal enviam registros de auditoria do servidor da API Kubernetes para o Google Cloud.
    1.2.21 Verificar se o argumento --audit-log-maxbackup está definido como 10 ou conforme apropriado (automatizado) L1 Falha não é definido por padrão; definir 10 somente se os Registros de auditoria do Cloud estiverem desativados Por padrão, os Clusters do Anthos em clusters bare metal enviam registros de auditoria do servidor da API Kubernetes para o Google Cloud.
    1.2.22 Verificar se o argumento --audit-log-maxsize está definido como 100 ou conforme apropriado (automatizado) L1 Falha não é definido por padrão; definir 100 somente se os Registros de auditoria do Cloud estiverem desativados Por padrão, os Clusters do Anthos em clusters bare metal enviam registros de auditoria do servidor da API Kubernetes para o Google Cloud.
    3.2.2 Verificar se a política de auditoria abrange as principais preocupações de segurança (manual) L2 Controle equivalente não definido Os clusters do Anthos em bare metal capturam registros de auditoria, mas não usam essas sinalizações para auditoria. Saiba mais em geração de registros e monitoramento.
    4.2.4 Verificar se o argumento --read-only-port está definido como 0 (manual) L1 Fail 10255 Atualmente, os clusters do Anthos em Bare Metal definem o argumento --read-only-port como 10255 para coletar métricas do kubelet.
    4.2.6 Verificar se o argumento --protect-kernel-defaults está definido como verdadeiro (automatizado) L1 Fail false As máquinas com cluster do Anthos em bare metal não protegem os padrões do kernel do Kubernetes, porque as cargas de trabalho do cliente podem querer modificá-los.
    4.2.9 Verificar se o argumento --event-qps está definido como 0 ou em um nível que garanta a captura apropriada do evento (manual) L2 Alerta não definido 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) 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.
    4.2.10 Verificar se os argumentos --tls-cert-file e --tls-private-key-file estão definidos conforme apropriado (manual) L1 Controle equivalente não definido Os clusters do Anthos em Bare Metal gerenciam o TLS do servidor do kubelet usando a sinalização "rotate-server-certificates".
    4.2.13 Verificar se o Kubelet usa somente códigos criptográficos fortes (manual) L1 Controle equivalente Em nós de Clusters do Anthos em bare metal, o kubelet usa os pacotes de criptografia padrão do Go. Os clusters do Anthos em bare metal não oferecem opções de configuração para o usuário personalizar a seleção de pacotes de criptografia. Os clientes modernos negociam pacotes de criptografia e não usam as criptografias fracas se as criptografias fortes estiverem mutuamente disponíveis.

    Como auditar os comparativos de mercado

    Instruções específicas para a auditoria de cada recomendação estão disponíveis como parte do CIS Benchmark. 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.

    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 CIS Benchmark do Kubernetes.

    Especifique a versão apropriada, por exemplo

    kube-bench node --benchmark cis-1.23