Partilhar via

Benchmark do Kubernetes do Centro de Segurança da Internet (CIS)

Como um serviço seguro, o Serviço Kubernetes do Azure (AKS) está em conformidade com os padrões SOC, ISO, PCI DSS e HIPAA. Este artigo aborda a proteção de segurança aplicada ao AKS com base no benchmark do Kubernetes do CIS. Para obter mais informações sobre a segurança do AKS, consulte Conceitos de segurança para aplicativos e clusters no Serviço Kubernetes do Azure (AKS). Para obter mais informações sobre o benchmark CIS, consulte Center for Internet Security (CIS) Benchmarks.

Benchmark do Kubernetes CIS

Seguem-se os resultados das recomendações do CIS Kubernetes Benchmark v1.12.0 sobre AKS. Os resultados aplicam-se ao AKS 1.32.x até ao AKS 1.34.x. Para obter linhas do tempo de suporte, consulte as versões suportadas do Kubernetes.

Nota

Além do benchmark CIS do Kubernetes, há um benchmark CIS AKS disponível também.

Níveis de segurança

Os benchmarks CIS fornecem dois níveis de configurações de segurança:

  • L1, ou Nível 1, recomenda requisitos básicos essenciais de segurança que podem ser configurados em qualquer sistema e devem causar pouca ou nenhuma interrupção do serviço ou funcionalidade reduzida.
  • L2, ou Nível 2, recomenda configurações de segurança para ambientes que exigem maior segurança e que podem resultar em alguma funcionalidade reduzida.

Estado da avaliação

Um status de avaliação é incluído para cada recomendação. O status da avaliação indica se a recomendação dada pode ser automatizada ou requer etapas manuais para ser implementada. Ambos os estatutos são igualmente importantes e são determinados e suportados da seguinte forma:

  • Automatizado: Representa recomendações para as quais a avaliação de um controle técnico pode ser totalmente automatizada e validada para um estado de aprovação/reprovação. As recomendações incluem as informações necessárias para implementar a automação.
  • Manual: Representa recomendações para as quais a avaliação de um controle técnico não pode ser totalmente automatizada e requer todas ou algumas etapas manuais para validar se o estado configurado está definido conforme o esperado. O estado esperado pode variar dependendo do ambiente.

As recomendações automatizadas afetam a pontuação de referência se não forem aplicadas, enquanto as recomendações manuais não.

Estado do atestado

As recomendações podem ter um dos seguintes status de atestado:

  • Pass: A recomendação foi aplicada.
  • Falha: A recomendação não foi aplicada.
  • N/A: A recomendação está relacionada aos requisitos de permissão de arquivo de manifesto que não são relevantes para o AKS. Por padrão, os clusters de Kubernetes usam um modelo de manifesto para implantar os pods do plano de controlo, que dependem de ficheiros da VM do nó. O benchmark do Kubernetes do CIS recomenda que esses arquivos devem ter certos requisitos de permissão. Os clusters AKS usam um chart Helm para implantar os pods do plano de controlo e não dependem de ficheiros na VM do nó.
  • Depende do ambiente: A recomendação é aplicada no ambiente específico do usuário e não é controlada pelo AKS. As recomendações automatizadas afetam a pontuação de referência, quer a recomendação se aplique ao ambiente específico do usuário ou não.
  • Controle equivalente: A recomendação foi implementada de maneira diferente e equivalente.

Detalhes do benchmark

CIS ID Descrição da recomendação Estado da avaliação Nível Estado Motivo
1 Componentes do plano de controle
1.1 Arquivos de configuração do nó do plano de controle
1.1.1 Verifique se as permissões do arquivo de especificação do pod do servidor API estão definidas como 600 ou mais restritivas Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.2 Verifique se a propriedade do arquivo de especificação do pod do servidor de API está definida como root: root Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.3 Verifique se as permissões do arquivo de especificação do pod do gerenciador do controlador estão definidas como 600 ou mais restritivas Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.4 Verifique se a propriedade do arquivo de especificação do pod do gestor do controlador está definida como root: root Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.5 Verifique se as permissões do arquivo de especificação do pod do agendador estão definidas como 600 ou mais restritivas Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.6 Verifique se a propriedade do arquivo de especificação do pod do scheduler está definida como root: root Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.7 Verifique se as permissões do arquivo de especificação do pod etcd estão definidas como 600 ou mais restritivas Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.8 Certifique-se de que a propriedade do arquivo de especificação do pod etcd esteja definida como root: root Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.9 Verifique se as permissões do arquivo da Interface de Rede de Contêiner estão definidas como 600 ou mais restritivas Manual L1 N/A N/D porque o AKS é uma solução gerida
1.1.10 Verifique se a propriedade do arquivo da Interface de Rede de Contêiner está definida como root: root Manual L1 N/A N/D porque o AKS é uma solução gerida
1.1.11 Certifique-se de que as permissões do diretório de dados etcd estejam definidas como 700 ou mais restritivas Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.12 Verifique se a propriedade do diretório de dados etcd está definida como etcd:etcd Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.13 Verifique se as permissões do arquivo admin.conf estão definidas como 600 ou mais restritivas Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.14 Verifique se a propriedade do arquivo admin.conf está definida como root: root Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.15 Verifique se as permissões do arquivo scheduler.conf estão definidas como 600 ou mais restritivas Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.16 Verifique se a propriedade do arquivo scheduler.conf está definida como root: root Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.17 Verifique se as permissões do arquivo controller-manager.conf estão definidas como 600 ou mais restritivas Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.18 Verifique se a propriedade do arquivo controller-manager.conf está definida como root: root Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.19 Verifique se o diretório PKI do Kubernetes e a propriedade do arquivo estão definidos como root: root Automatizado L1 N/A N/D porque o AKS é uma solução gerida
1.1.20 Verifique se as permissões do arquivo de certificado PKI do Kubernetes estão definidas como 600 ou mais restritivas Manual L1 N/A N/D porque o AKS é uma solução gerida
1.1.21 Verifique se as permissões do arquivo de chave PKI do Kubernetes estão definidas como 600 Manual L1 N/A N/D porque o AKS é uma solução gerida
1.2 Servidor de API
1.2.1 Verifique se o --anonymous-auth argumento está definido como false Manual L1 Aprovação
1.2.2 Certifique-se de que o --token-auth-file parâmetro não está definido Automatizado L1 Falha Auto-girado pelo AKS, atualmente o parâmetro está definido
1.2.3 Certifique-se de que --DenyServiceExternalIPs não está definido Manual L1 Falha Os clientes podem usar a Política do Azure para Kubernetes para negar serviços com IP Externo.
1.2.4 Certifique-se de que os --kubelet-client-certificate argumentos e --kubelet-client-key são definidos conforme apropriado Automatizado L1 Aprovação
1.2.5 Certifique-se de que o --kubelet-certificate-authority argumento está definido conforme apropriado Automatizado L1 Falha Certificado de serviço Kubelet usa certificado autoassinado
1.2.6 Certifique-se de que o --authorization-mode argumento não está definido como AlwaysAllow Automatizado L1 Aprovação
1.2.7 Certifique-se de que o --authorization-mode argumento inclui Node Automatizado L1 Aprovação
1.2.8 Certifique-se de que o --authorization-mode argumento inclui RBAC Automatizado L1 Aprovação
1.2.9 Certifique-se de que o plug-in de controle de admissão EventRateLimit esteja definido Manual L1 Falha Impacto operacional
1.2.10 Certifique-se de que o plug-in de controle de admissão AlwaysAdmit não está definido Automatizado L1 Aprovação
1.2.11 Certifique-se de que o plug-in de controle de admissão AlwaysPullImages está definido Manual L1 Falha Impacto operacional
1.2.12 Certifique-se de que o plug-in de controle de admissão ServiceAccount está definido Automatizado L2 Aprovação
1.2.13 Certifique-se de que o plug-in de controle de admissão NamespaceLifecycle esteja definido Automatizado L2 Aprovação
1.2.14 Certifique-se de que o plug-in de controle de admissão NodeRestriction esteja definido Automatizado L2 Aprovação
1.2.15 Verifique se o --profiling argumento está definido como false Automatizado L1 Aprovação
1.2.16 Certifique-se de que o --audit-log-path argumento está definido Automatizado L1 Aprovação
1.2.17 Certifique-se de que o --audit-log-maxage argumento está definido como 30 ou conforme apropriado Automatizado L1 Controlo Equivalente O AKS armazena o log de auditoria por 14 dias, Deployment.yaml tem valor 0.
1.2.18 Certifique-se de que o --audit-log-maxbackup argumento está definido como 10 ou conforme apropriado Automatizado L1 Controlo Equivalente O AKS armazena o log de auditoria por 14 dias, Deployment.yaml tem valor 0.
1.2.19 Certifique-se de que o --audit-log-maxsize argumento está definido como 100 ou conforme apropriado Automatizado L1 Aprovação
1.2.20 Certifique-se de que o --request-timeout argumento está definido conforme apropriado Manual L1 Aprovação O parâmetro não está definido, o que definirá o valor padrão = 60s (que é compatível)
1.2.21 Certifique-se de que o --service-account-lookup argumento está definido como true Automatizado L1 Aprovação O parâmetro não está definido, o que definirá o valor padrão como true (que é compatível)
1.2.22 Certifique-se de que o --service-account-key-file argumento está definido conforme apropriado Automatizado L1 Aprovação
1.2.23 Certifique-se de que os --etcd-certfile argumentos e --etcd-keyfile são definidos conforme apropriado Automatizado L1 Aprovação
1.2.24 Certifique-se de que os --tls-cert-file argumentos e --tls-private-key-file são definidos conforme apropriado Automatizado L1 Aprovação
1.2.25 Certifique-se de que o --client-ca-file argumento está definido conforme apropriado Automatizado L1 Aprovação
1.2.26 Certifique-se de que o --etcd-cafile argumento está definido conforme apropriado Automatizado L1 Aprovação
1.2.27 Certifique-se de que o --encryption-provider-config argumento está definido conforme apropriado Manual L1 Depende do ambiente O argumento é definido quando o KMS do Azure está habilitado
1.2.28 Verifique se os provedores de criptografia estão configurados adequadamente Manual L1 Depende do ambiente O argumento é definido quando o KMS do Azure está habilitado
1.2.29 Certifique-se de que o Servidor de API use apenas Cifras Criptográficas Fortes Manual L1 Aprovação O AKS suporta um subconjunto de 4 Strong Ciphersuites de um total de 21 recomendados pela CIS
1.2.30 Verifique se o --service-account-extend-token-expiration parâmetro está definido como false Automatizado L1 Depende do ambiente Este parâmetro é definido como false quando o OIDC está habilitado no cluster
1.3 Gerente de Controladoria
1.3.1 Certifique-se de que o --terminated-pod-gc-threshold argumento está definido conforme apropriado Manual L1 Aprovação O AKS define o valor padrão como 6000 em vez de 12500
1.3.2 Verifique se o --profiling argumento está definido como false Automatizado L1 Aprovação
1.3.3 Certifique-se de que o --use-service-account-credentials argumento está definido como true Automatizado L1 Aprovação
1.3.4 Certifique-se de que o --service-account-private-key-file argumento está definido conforme apropriado Automatizado L1 Aprovação
1.3.5 Certifique-se de que o --root-ca-file argumento está definido conforme apropriado Automatizado L1 Aprovação
1.3.6 Verifique se o argumento RotateKubeletServerCertificate está definido como true Automatizado L2 Aprovação O parâmetro está definido como true, consulte Kubelet Serving Certificate Rotation
1.3.7 Verifique se o --bind-address argumento está definido como 127.0.0.1 Automatizado L1 Controlo Equivalente O IP do Pod é usado
1.4 Agendador
1.4.1 Verifique se o --profiling argumento está definido como false Automatizado L1 Aprovação
1.4.2 Verifique se o --bind-address argumento está definido como 127.0.0.1 Automatizado L1 Controlo Equivalente O IP do Pod é usado
2 etcd
2.1 Certifique-se de que os --cert-file argumentos e --key-file são definidos conforme apropriado Automatizado L1 Aprovação
2.2 Certifique-se de que o --client-cert-auth argumento está definido como true Automatizado L1 Aprovação
2.3 Certifique-se de que o --auto-tls argumento não está definido como true Automatizado L1 Aprovação O parâmetro não está definido, o que definirá o valor padrão como false (que é compatível)
2,4 Certifique-se de que os --peer-cert-file argumentos e --peer-key-file são definidos conforme apropriado Automatizado L1 Aprovação
2,5 Certifique-se de que o --peer-client-cert-auth argumento está definido como true Automatizado L1 Aprovação
2.6 Certifique-se de que o --peer-auto-tls argumento não está definido como true Automatizado L1 Aprovação O parâmetro não está definido, o que definirá o valor padrão como false (que é compatível)
2,7 Certifique-se de que uma Autoridade de Certificação exclusiva seja usada para etcd Manual L2 Aprovação --client-ca-file para api-server é diferente de --trusted-ca-file para etcd
3 Configuração do plano de controle
3.1 Autenticação e Autorização
3.1.1 A autenticação de certificado de cliente não deve ser usada para usuários Manual L1 Aprovação Quando você implanta um cluster AKS, as contas locais são habilitadas por padrão. Você pode desabilitar contas locais para desabilitar certificados de cliente para autenticação.
3.1.2 A autenticação de token de conta de serviço não deve ser usada para usuários Manual L1 Aprovação O AKS fornece suporte para autenticação Microsoft Entra para solicitações enviadas ao plano de controle de cluster. O uso de tokens de contagem de serviço é deixado para o cliente (para impor uma prática recomendada, conforme necessário)
3.1.3 A autenticação de token de bootstrap não deve ser usada para usuários Manual L1 Aprovação Os tokens de bootstrap não podem ser usados pelos usuários
3.2 Registo
3.2.1 Garantir que uma política de auditoria mínima seja criada Manual L1 Aprovação
3.2.2 Garantir que a política de auditoria cobre as principais preocupações de segurança Manual L2 Aprovação
4 Nós de Trabalho
4.1 Arquivos de configuração do nó de trabalho
4.1.1 Verifique se as permissões do arquivo de serviço kubelet estão definidas como 600 ou mais restritivas Automatizado L1 Aprovação
4.1.2 Verifique se a propriedade do arquivo de serviço kubelet está definida como root: root Automatizado L1 Aprovação
4.1.3 Se existir um arquivo kubeconfig proxy, verifique se as permissões estão definidas como 600 ou mais restritivas Manual L1 N/A
4.1.4 Se existir um arquivo kubeconfig proxy, verifique se a propriedade está definida como root: root Manual L1 N/A
4.1.5 Verifique se as permissões do --kubeconfig arquivo kubelet.conf estão definidas como 600 ou mais restritivas Automatizado L1 Aprovação
4.1.6 Verifique se a propriedade do --kubeconfig arquivo kubelet.conf está definida como root: root Automatizado L1 Aprovação
4.1.7 Verifique se as permissões de arquivo das autoridades de certificação estão definidas como 600 ou mais restritivas Manual L1 Aprovação
4.1.8 Verifique se a propriedade do arquivo das autoridades de certificação do cliente está definida para root: root Manual L1 Aprovação
4.1.9 Se o arquivo de configuração kubelet config.yaml estiver sendo usado, verifique as permissões definidas como 600 ou mais restritivas Automatizado L1 Aprovação
4.1.10 Se o arquivo de configuração kubelet config.yaml estiver sendo usado, verifique se a propriedade do arquivo está definida como root: root Automatizado L1 Aprovação
4.2 Kubelet
4.2.1 Verifique se o --anonymous-auth argumento está definido como false Automatizado L1 Aprovação
4.2.2 Certifique-se de que o --authorization-mode argumento não está definido como AlwaysAllow Automatizado L1 Aprovação
4.2.3 Certifique-se de que o --client-ca-file argumento está definido conforme apropriado Automatizado L1 Aprovação
4.2.4 Verifique se o --read-only-port argumento está definido como 0 Manual L1 Aprovação
4.2.5 Verifique se o --streaming-connection-idle-timeout argumento não está definido como 0 Manual L1 Aprovação
4.2.6 Certifique-se de que o --make-iptables-util-chains argumento está definido como true Automatizado L1 Aprovação
4.2.7 Certifique-se de que o --hostname-override argumento não está definido Manual L1 Aprovação
4.2.8 Certifique-se de que o --eventRecordQPS argumento esteja definido para um nível que garanta a captura de eventos apropriada Manual L2 Aprovação
4.2.9 Certifique-se de que os --tls-cert-file argumentos e --tls-private-key-file são definidos conforme apropriado Manual L1 Aprovação
4.2.10 Certifique-se de que o --rotate-certificates argumento não está definido como false Automatizado L1 Aprovação
4.2.11 Verifique se o argumento RotateKubeletServerCertificate está definido como true Manual L1 Aprovação
4.2.12 Certifique-se de que o Kubelet faça uso apenas de Cifras Criptográficas Fortes Manual L1 Aprovação
4.2.13 Certifique-se de que um limite está definido para PIDs de pod Manual L1 Aprovação
4.2.14 Garantir que o Kubelet imponha a utilização do perfil seccomp RuntimeDefault Manual L1 Depende do ambiente O AKS padrão é Unconfined. A Configuração Personalizada do Nodo pode ser usada para ativar o perfil seccomp.
4.3 kube-proxy
4.3.1 Certifique-se de que o serviço de métricas kube-proxy esteja vinculado ao localhost Automatizado L1 Falha O AKS tem raspagem central do Prometheus para kube-proxy e aplica alerta e remediação automática quando KubeProxyStale detetado. O metrics-bind-address é definido para esse fim.
5 Políticas
5.1 RBAC e Contas de Serviço
5.1.1 Verifique se a função de administrador de cluster só é usada quando necessário Automatizado L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.1.2 Minimizar o acesso a segredos Automatizado L1 Depende do ambiente
5.1.3 Minimizar o uso de curingas em Roles e ClusterRoles Automatizado L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.1.4 Minimize o acesso para criar pods Automatizado L1 Depende do ambiente
5.1.5 Verifique se as contas de serviço padrão não são usadas ativamente Automatizado L1 Depende do ambiente
5.1.6 Certifique-se de que os Tokens de Conta de Serviço sejam montados apenas quando necessário Automatizado L1 Depende do ambiente
5.1.7 Evite o uso do sistema: grupo de administradores Manual L1 Depende do ambiente
5.1.8 Limitar uso das permissões Associar, Personificar e Aumentar no cluster do Kubernetes Manual L1 Depende do ambiente
5.1.9 Minimize o acesso para criar volumes persistentes Manual L1 Depende do ambiente
5.1.10 Minimizar o acesso ao subrecurso proxy dos nós Manual L1 Depende do ambiente
5.1.11 Minimizar o acesso ao subrecurso de aprovação dos objetos certificatesigningrequests Manual L1 Depende do ambiente
5.1.12 Minimizar o acesso a objetos de configuração do webhook Manual L1 Depende do ambiente
5.1.13 Minimizar o acesso à criação de tokens para contas de serviço Manual L1 Depende do ambiente
5,2 Padrões de Segurança do Pod
5.2.1 Verifique se o cluster tem pelo menos um mecanismo de controle de política ativa em vigor Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.2 Minimizar a admissão de contentores privilegiados Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.3 Minimize a admissão de contêineres que desejam compartilhar o namespace de ID do processo do host Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.4 Minimizar a admissão de contêineres que desejam compartilhar o namespace IPC do host Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.5 Minimizar a admissão de contêineres que desejam compartilhar o namespace de rede do host Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.6 Minimize a admissão de contêineres com allowPrivilegeEscalation Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.7 Minimizar a admissão de recipientes raiz Manual L2 Depende do ambiente
5.2.8 Minimizar a admissão de contenedores com a capacidade NET_RAW Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.9 Minimize a admissão de contêineres com recursos adicionais Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.10 Minimizar a admissão de contêineres com recursos atribuídos Manual L2 Depende do ambiente
5.2.11 Minimizar a admissão de contêineres do Windows HostProcess Manual L1 Depende do ambiente
5.2.12 Minimizar a admissão de volumes do HostPath Manual L1 Depende do ambiente Usar definições de política internas da Política do Azure para o Serviço Kubernetes do Azure
5.2.13 Minimizar a admissão de contêineres que usam HostPorts Manual L1 Depende do ambiente
5.3 Políticas de Rede e CNI
5.3.1 Garantir que a CNI em uso ofereça suporte às Políticas de Rede Manual L1 Aprovação
5.3.2 Verifique se todos os namespaces têm políticas de rede definidas Manual L2 Depende do ambiente
5.4 Gestão de segredos
5.4.1 Prefira usar segredos como arquivos em vez de segredos como variáveis de ambiente Manual L2 Depende do ambiente
5.4.2 Considere o armazenamento de segredos externos Manual L2 Depende do ambiente
5,5 Controlo de admissão extensível
5.5.1 Configurar a proveniência da imagem usando o controlador de admissão ImagePolicyWebhook Manual L2 Falha Controlo equivalente implementado
5,6 Políticas Gerais
5.6.1 Criar limites administrativos entre recursos usando namespaces Manual L1 Depende do ambiente
5.6.2 Verifique se o perfil seccomp está definido como docker/default nas definições do pod Manual L2 Depende do ambiente
5.6.3 Aplique o contexto de segurança aos seus pods e contêineres Manual L2 Depende do ambiente
5.6.4 O namespace padrão não deve ser usado Manual L2 Depende do ambiente

Outras notas

  • O sistema operativo robusto em termos de segurança é construído e mantido especificamente para o AKS e não é suportado fora da plataforma AKS.
  • Para reduzir ainda mais a área da superfície de ataque, alguns drivers de módulo do kernel desnecessários são desativados no sistema operacional.

Próximos passos

Para obter mais informações sobre a segurança do AKS, consulte os seguintes artigos:

  • Last updated on