Como aumentar a segurança do seu cluster

Com a velocidade do desenvolvimento no Kubernetes, muitas vezes há novos recursos de segurança para você usar. Nesta página, orientamos você na implementação de nossas diretrizes atuais para proteger seu cluster do Google Kubernetes Engine (GKE).

Neste guia, priorizamos as medidas de mitigação dos riscos de segurança em situações em que a segurança é particularmente importante e que exigem a intervenção do cliente no momento da criação do cluster. Recursos menos críticos, configurações de segurança padrão e funções que podem ser ativadas após a criação do cluster são mencionados posteriormente no documento. Para ver informações gerais sobre os tópicos de segurança, leia a Visão geral de segurança.

Muitas das recomendações deste documento, bem como outros erros de configuração comuns, podem ser verificadas automaticamente usando a análise de integridade de segurança.

Quando as recomendações abaixo forem referentes a uma recomendação de referência do CIS para GKE essas serão especificadas.

Fazer o upgrade da sua infraestrutura do GKE em tempo hábil (padrão 2019-11-11)

Recomendação de referência do CIS para GKE: 6.5.3. Verificar se o upgrade automático de nós está ativado para os nós do GKE

Manter a versão do Kubernetes atualizada é uma das ações mais simples para melhorar sua segurança. O Kubernetes apresenta frequentemente novos recursos de segurança e fornece patches de segurança.

Consulte os boletins de segurança do GKE para conferir informações sobre patches de segurança.

No Google Kubernetes Engine, os mestres recebem patches e upgrades automaticamente. Também é possível manter os nós do cluster atualizados com upgrades automáticos.

Se você optar por desativar o upgrade automático do nó, recomendamos fazer o upgrade mensal conforme sua programação. Os clusters mais antigos precisam ativar o upgrade automático de nós e acompanhar de perto os boletins de segurança do GKE para patches críticos.

Para saber mais, consulte Como fazer o upgrade automático dos nós.

Restringir o acesso à rede ao plano de controle e aos nós

Recomendações de referência do CIS para GKE: 6.6.2. Preferir clusters nativos de VPC, 6.6.3. Verificar se a rede autorizada principal está ativada, 6.6.4. Verificar se os clusters foram criados com o endpoint privado ativado e o acesso público desativado, e 6.6.5. Verificar se os clusters foram criados com os nós particulares

Limite a exposição do plano de controle de cluster e nós à Internet. Essas configurações só podem ser definidas no momento da criação do cluster.

Por padrão, os nós e o plano de controle do cluster do GKE têm endereços de Internet roteáveis que podem ser acessados de qualquer endereço IP.

Para o plano de controle do cluster do GKE, consulte Como criar um cluster particular. Há três tipos diferentes de clusters particulares que podem fornecer proteção no nível de rede:

  • Acesso ao endpoint público desativado: essa é a opção mais segura, já que evita todo o acesso à Internet para mestres e nós. Essa é uma boa opção se você configurou sua rede local para se conectar ao Google Cloud usando Cloud Interconnect e Cloud VPN. Essas tecnologias conectam efetivamente a rede da empresa à nuvem VPC.
  • Acesso de endpoint público ativado, redes principais autorizadas ativadas (recomendado): esta opção fornece acesso restrito à instância mestre dos endereços IP de origem definidos por você. Essa é uma ótima opção se você não tem uma infraestrutura de VPN ou se tem usuários remotos ou filiais que se conectam pela Internet pública em vez da VPN corporativa, do Cloud Interconnect ou do Cloud VPN.
  • Acesso ao endpoint público ativado, redes principais autorizadas desativadas: esse é o padrão e permite que qualquer pessoa na Internet faça conexões de rede com o plano de controle.

Para desativar o acesso direto à Internet nos nós, especifique a opção --enable-private-nodes da ferramenta gcloud na criação do cluster.

Isso informa ao GKE para provisionar os nós com endereços IP particulares RFC 1918, o que significa que os nós não são alcançáveis diretamente pela Internet pública.

Recomendamos que os clusters usem, pelo menos, redes principais autorizadas e nós particulares. Isso garante que o plano de controle seja acessível por:

  • CIDRs permitidos em redes principais autorizadas;
  • nós na VPC do cluster;
  • jobs de produção internos do Google que gerenciam seu mestre.

Isso corresponde às seguintes sinalizações gcloud no momento da criação do cluster:

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

Autenticação de grupo (Beta)

Recomendação de referência do CIS para GKE: 6.8.3. Gerenciar usuários RBAC do Kubernetes com os Grupos do Google para GKE

Esta configuração só pode ser ativada no momento da criação do cluster.

Use grupos para gerenciar seus usuários. Isso permite que as identidades sejam controladas usando seu sistema de gerenciamento de identidades e administradores de identidade. O ajuste da participação no grupo dispensa a atualização da configuração RBAC sempre que alguém for adicionado ou removido do grupo.

Para gerenciar permissões de usuário usando os Grupos do Google, ative Grupos do Google para o GKE ao criar seu cluster. Isso permite que você gerencie facilmente os usuários com as mesmas permissões e permite que os administradores de identidade gerenciem os usuários de maneira centralizada e consistente.

Para ativar o Grupos do Google para o GKE, crie um Grupo do Google, gke-security-groups, para gerenciar o acesso de usuários e especifique a sinalização gcloud --security-group no momento da criação do cluster.

Opções de nós do contêiner

As seções a seguir descrevem as opções de configuração de nós seguros.

Ativar nós protegidos do GKE

Recomendação de referência do CIS para GKE: 6.5.5. Verificar se os nós do GKE protegidos estão ativados

Os nós do GKE protegidos fornecem identidade e integridade de nó sólidas e confiáveis para aumentar a segurança dos nós do GKE. Eles precisam ser ativados em todos os clusters do GKE.

Para ativar os nós do GKE protegidos, especifique a opção gcloud --enable-shielded-nodes na criação ou atualização do cluster. Os nós do GKE protegidos precisam ser ativados com inicialização segura. A inicialização segura não poderá ser usada se você precisar de módulos de kernel não assinados de terceiros. Para ativar a inicialização segura, especifique a sinalização gcloud --shielded-secure-boot na criação do cluster.

Escolher uma imagem de nó com aumento da proteção junto com o ambiente de execução containerd

A imagem do Container-Optimized OS com containerd (cos_containerd) é uma variante da imagem que usa o containerd como ambiente de execução principal de contêineres e tem integração direta com o Kubernetes.

O containerd (em inglês) é o principal componente do ambiente de execução do Docker e foi projetado para fornecer a funcionalidade central da interface de ambiente de execução de contêiner (CRI, na sigla em inglês) do Kubernetes. Ele é significativamente menos complexo que o daemon Docker completo e, portanto, tem uma superfície de ataque menor.

Para usar a imagem cos_containerd no cluster, especifique a sinalização gcloud --image-type=cos_containerd na criação do cluster ou no momento da atualização.

A cos_containerd é a imagem preferencial do GKE, já que foi personalizada, otimizada e reforçada especificamente para executar contêineres.

Ativar o recurso Identidade da carga de trabalho

Recomendação de referência do CIS para GKE: 6.2.2. Prefira usar as contas de serviço e o recurso Identidade da carga de trabalho do Google Cloud dedicadas

O recurso Identidade da carga de trabalho é a maneira recomendada de autenticação para as APIs do Google. Esse recurso substitui as práticas anteriores que consistiam em usar a conta de serviço do nó ou exportar chaves de contas de serviço para secrets, conforme descrito em Como se autenticar no Google Cloud com contas de serviço.

O recurso Identidade da carga de trabalho também dispensa o uso de ocultação de metadados, e as duas abordagens são incompatíveis. Os metadados confidenciais protegidos por ocultação de metadados também são protegidos pelo recurso Identidade da carga de trabalho.

Como aumentar a proteção do isolamento da carga de trabalho com o GKE Sandbox

Recomendação de referência do CIS para GKE: 6.10.4. Considere o GKE Sandbox para aumentar o isolamento da carga de trabalho, especialmente para cargas de trabalho não confiáveis

O GKE Sandbox fornece uma camada extra de segurança para evitar que códigos maliciosos afetem o kernel do host nos nós do cluster.

Saiba como usar o GKE Sandbox em Como aumentar o isolamento de cargas de trabalho com o GKE Sandbox.

Permissões

Usar contas de serviço do Google com privilégios mínimos

Recomendação de referência do CIS para GKE: 6.2.1. Preferir não executar clusters do GKE usando a conta de serviço padrão do Compute Engine

Cada nó do GKE tem uma conta de serviço do gerenciamento de identidade e acesso (IAM) associada a ele. Por padrão, os nós recebem a conta de serviço padrão do Compute Engine, que pode ser encontrada navegando até a seção "Cloud IAM" no Console do Cloud. Essa conta tem acesso amplo por padrão, o que a torna útil para uma grande variedade de aplicativos, mas tem mais permissões do que as necessárias para executar o cluster do Kubernetes Engine. Crie e use uma conta de serviço com privilégios mínimos para executar seu cluster GKE em vez de usar a conta de serviço padrão do Compute Engine.

Com o lançamento do recurso Identidade da carga de trabalho, sugerimos um caso de uso mais limitado para a conta de serviço do nó. Esperamos que a conta de serviço do nó seja usada pelos daemons do sistema responsáveis pela geração de registros, pelo monitoramento e por tarefas semelhantes. As cargas de trabalho em pods precisam ser provisionadas como identidades do Google com o recurso Identidade da carga de trabalho.

O GKE exige, no mínimo, que a conta de serviço tenha os papéis monitoring.viewer, monitoring.metricWriter e logging.logWriter. Leia mais sobre papéis de monitoramento e de geração de registros.

Os seguintes comandos criam uma conta de serviço do IAM com as permissões mínimas necessárias para operar o GKE:

gcloud

gcloud iam service-accounts create sa-name \
  --display-name=sa-name

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/logging.logWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.viewer

Config Connector

Observação: esta etapa requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no cluster.

  1. Para criar a conta de serviço, faça o download do seguinte recurso como service-account.yaml. Substitua [SA_NAME] pelo nome que você quer usar para a conta de serviço.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    metadata:
      name: [SA_NAME]
    spec:
      displayName: [SA_NAME]
    Depois, execute:
    kubectl apply -f service-account.yaml

  2. Aplique o papel logging.logWriter à conta de serviço. Faça o download do seguinte recurso como policy-logging.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-logging
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/logging.logWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  3. Aplique o papel monitoring.metricWriter. Faça o download do seguinte recurso como policy-metrics-writer.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-metrics-writer
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.metricWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-metrics-writer.yaml

  4. Aplique o papel monitoring.viewer. Faça o download do seguinte recurso como policy-monitoring.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-monitoring
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.viewer
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-monitoring.yaml

Se você usa imagens particulares no Google Container Registry, também precisa conceder acesso a elas:

gcloud

gcloud projects add-iam-policy-binding project-id \
--member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
--role roles/storage.objectViewer

Config Connector

Observação: esta etapa requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no cluster.

Aplique o papel storage.objectViewer à sua conta de serviço. Faça o download do seguinte recurso como policy-object-viewer.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-object-viewer.yaml

Se quiser que outro usuário humano possa criar novos clusters ou pools de nós com essa conta de serviço, conceda a ele o papel Usuário de conta de serviço nesta conta de serviço:

gcloud

gcloud iam service-accounts add-iam-policy-binding \
sa-name@project-id.iam.gserviceaccount.com \
--member=user:user \
--role=roles/iam.serviceAccountUser

Config Connector

Observação: esta etapa requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no cluster.

Aplique o papel iam,serviceAccountUser à sua conta de serviço. Faça o download do seguinte recurso como policy-service-account-user.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-service-account-user.yaml

Se o cluster já existir, crie um novo pool de nós com essa nova conta de serviço:

gcloud container node-pools create node-pool \
  --service-account=sa-name@project-id.iam.gserviceaccount.com \
  --cluster=cluster-name

Se você precisar que seu cluster do GKE tenha acesso a outros serviços do Google Cloud, crie uma conta de serviço adicional e conceda acesso às cargas de trabalho usando a identidade da carga de trabalho.

Restringir permissões de RBAC na detecção de cluster

Por padrão, o Kubernetes inicializa clusters com um conjunto permissivo de ClusterRoleBindings de detecção, que fornece amplo acesso a informações sobre as APIs de um cluster, incluindo aquelas de CustomResourceDefinitions (em inglês).

Os usuários precisam estar cientes de que o grupo system:authenticated incluído nos assuntos dos ClusterRoleBindings system:discovery e system:basic-user pode incluir qualquer usuário autenticado (incluindo qualquer pessoa com uma Conta do Google) e não representa um nível significativo de segurança para clusters no GKE.

Para usar as APIs de descoberta do cluster, considere uma ou mais das seguintes opções:

  • Configurar redes autorizadas para restringir o acesso a intervalos de IP definidos.
  • Configurar um cluster particular para restringir o acesso a um VPC.
  • Selecione os assuntos dos clustersRoleBindings system:discovery e system:basic-user padrão. Por exemplo, em vez de permitir acesso a system:(un)authenticated padrão do Kubernetes, considere permitir somente o acesso ao grupo system:serviceaccounts mais outros Usuários e Grupos.

Usar namespaces e RBAC para restringir o acesso aos recursos do cluster

Recomendação de referência do CIS para GKE: 5.6.1. Criar limites administrativos entre recursos usando namespaces

Conceda aos grupos privilégios mínimos de acesso ao Kubernetes criando namespaces ou clusters separados para cada equipe e ambiente. Atribua centros de custo e rótulos apropriados a cada namespace para responsabilidade e estorno. Forneça aos desenvolvedores o nível de acesso ao namespace necessário para implantar e gerenciar o aplicativo, especialmente na produção. Mapeie as tarefas que os usuários precisam executar no cluster e defina as permissões necessárias para executar cada tarefa.

Para saber mais sobre a criação de namespaces, consulte a documentação do Kubernetes.

O Cloud IAM e Controle de acesso baseado em papéis (RBAC, na sigla em inglês) trabalham em conjunto e uma entidade precisa ter permissões suficientes em qualquer nível para trabalhar com recursos no cluster.

Atribua os Papéis do Cloud IAM apropriados para o GKE para grupos e usuários para fornecer permissões no nível do projeto e usar RBAC para conceder permissões em um nível de cluster e de namespace. Para saber mais, consulte Controle de acesso.

Para mais informações, consulte Como preparar um ambiente do Kubernetes Engine para produção.

Restringir o tráfego entre pods com uma política de rede

Recomendação de referência do CIS para GKE: 6.6.7. Verificar se a política de rede está ativada e fazer as configurações adequadas

Por padrão, todos os pods em um cluster podem se comunicar uns com os outros. Controle a comunicação de pod para o pod conforme necessário para suas cargas de trabalho.

Restringir o acesso à rede aos serviços dificulta muito a migração lateral dos invasores dentro do cluster, além de oferecer aos serviços alguma proteção contra negação de serviço acidental ou deliberada. Veja as duas maneiras recomendadas de controlar o tráfego:

  1. Use o Istio (em inglês). Consulte Como instalar o Istio no GKE e escolha esta opção se você estiver interessado em balanceamento de carga, autorização de serviço, limitação, cota, métricas e muito mais.
  2. Use políticas de rede do Kubernetes (em inglês). Consulte Como configurar uma política de rede de cluster. Escolha essa opção se você estiver procurando a funcionalidade básica de controle de acesso exposta pelo Kubernetes. A documentação do Kubernetes tem um excelente tutorial (em inglês) para uma implantação simples do nginx.

O Istio e a Política de rede podem ser usados em conjunto se isso for necessário.

Gerenciamento de secrets

Recomendação de referência do CIS para GKE: 6.3.1. Criptografar secrets do Kubernetes usando chaves gerenciadas no Cloud KMS

Forneça uma camada adicional de proteção para dados confidenciais, como secrets, armazenados em etcd (em inglês). Para fazer isso, configure um gerenciador de secrets integrado aos clusters do GKE. Algumas soluções funcionarão no GKE e no Anthos GKE On-prem. Portanto, pode ser mais desejável se você estiver executando cargas de trabalho em vários ambientes. Se você optar por usar um gerenciador de secrets externos, como o HashiCorp Vault, convém ter essa configuração antes de criar seu cluster.

Há várias opções de gerenciamento de secrets.

  • É possível usar os secrets do Kubernetes nativamente no GKE. Como alternativa, é possível criptografá-los na camada de aplicativos com uma chave gerenciada, usando a criptografia de secrets da camada de aplicativos.
  • É possível usar um gerenciador de secrets, como HashiCorp Vault. Quando executado em um modo de HA aprimorado, isso fornecerá uma maneira consistente e pronta para produção para gerenciar secrets. É possível se autenticar no HashiCorp Vault usando uma conta de serviço do Kubernetes ou uma conta de serviço do Google Cloud. Para saber mais sobre como usar o GKE com o Vault, consulte Como executar e conectar ao HashiCorp Vault no Kubernetes.

As VMs do GKE são criptografadas na camada de armazenamento por padrão, o que inclui o etcd.

Usar os controladores de admissão para aplicar a política

Recomendação de referência do CIS para GKE: 6.10.3. Verificar se a política de segurança de pods está ativada e fazer as configurações adequadas

Os controladores de admissão (em inglês) são plug-ins que regem e impõem o modo como o cluster é usado. Eles precisam ser ativados para usar alguns dos recursos de segurança mais avançados do Kubernetes e são uma parte importante da defesa em profundidade para proteger seu cluster

Por padrão, os pods no Kubernetes podem operar com recursos além do que eles exigem. Restrinja os recursos do pod apenas àqueles necessários para essa carga de trabalho.

O Kubernetes oferece controles para restringir a execução de pods com apenas recursos explicitamente concedidos. A política de segurança (em inglês) de pods permite que você defina padrões inteligentes para seus pods e imponha controles que você quer ativar em toda sua frota. As políticas que você define precisam ser específicas para as necessidades do seu aplicativo. A política de exemplo restricted-psp.yaml é um bom ponto de partida.

Para saber mais sobre a política de segurança de pods, consulte Como usar PodSecurityPolicies.

Se você estiver usando uma NetworkPolicy, e tiver um pod sujeito à PodSecurityPolicy, crie um papel RBAC ou ClusterRole (em inglês) que tenha permissão para usar a PodSecurityPolicy Em seguida, vincule-o à conta de serviço do pod. Nesse caso, conceder permissões a contas de usuários não é suficiente. Para mais informações, consulte Como autorizar políticas.

Monitorar a configuração do cluster

Audite as configurações do seu cluster para desvios das configurações definidas.

Muitas das recomendações abordadas neste guia de proteção, bem como outras configurações incorretas comuns, podem ser verificadas automaticamente usando Security Health Analytics.

Padrões seguros

As seções a seguir descrevem opções que são configuradas com segurança por padrão em novos clusters. Verifique se os clusters preexistentes estão configurados com segurança.

Proteger os metadados do nó (padrão para 1.12+)

Recomendações de referência do CIS para GKE: 6.4.1. Verificar se as APIs de metadados da instância legada do Compute Engine estão desativadas e 6.4.2. Verificar se o servidor de metadados do GKE está ativado

O servidor de metadados da instância do Compute Engine expõe endpoints /0.1/ e /v1beta1/ herdados, que não impõem cabeçalhos de consulta de metadados. Essas APIs foram desativadas por padrão para novos clusters 1.12+. Se você fez upgrade de clusters de versões mais antigas, precisará desativar essas APIs legadas manualmente.

Alguns ataques práticos contra o Kubernetes dependem do acesso ao servidor de metadados da VM para extrair credenciais. Esses ataques serão bloqueados se você estiver usando o recurso Identidade da carga de trabalho ou ocultação de metadados.

Os endpoints do servidor de metadados Compute Engine v1beta1 e v0.1 estão suspensos e programados para o encerramento. Certifique-se de atualizar todas as solicitações para usar o endpoint v1.

Para saber mais, consulte Como proteger metadados de cluster.

Deixar os métodos de autenticação do cliente legado desativados (padrão 1.12+)

Recomendações de referência do CIS para GKE: 6.8.1. Verificar se a autenticação básica com senhas estáticas está desativada e 6.8.2. Verificar se a autenticação com certificados do cliente está desativada

Há vários métodos de autenticação (em inglês) no servidor da API Kubernetes.

No GKE, os métodos compatíveis são tokens de suporte de conta de serviço, tokens OAuth, certificados de cliente x509 e senhas estáticas. O GKE gerencia a autenticação com gcloud para você por meio do método de token OAuth, da configuração do Kubernetes, de um token de acesso e mantendo-o atualizado.

Antes da integração do GKE com o Google OAuth, o certificado x509 pré-provisionado ou a senha estática eram os únicos métodos de autenticação disponíveis, mas agora não são recomendados e desativados por padrão em novos clusters desde 1.12+.

Os clusters atuais precisam ser movidos para o OAuth. Se uma credencial de longa duração for necessária por um sistema externo ao cluster, recomendamos que você crie uma conta de serviço do Google ou uma conta de serviço do Kubernetes com os privilégios necessários e exporte a chave.

Para atualizar um cluster atual e remover a senha estática:

gcloud container clusters update cluster-name \
  --no-enable-basic-auth

Atualmente, não é possível remover o certificado de cliente emitido de um cluster atual, mas ele não tem permissões se o RBAC estiver ativado e o ABAC estiver desativado.

Deixar o Cloud Logging ativado (padrão)

Recomendação de referência do CIS para GKE: 6.7.1. Verificar se o Stackdriver Kubernetes Logging e Monitoring estão ativados

Para reduzir a sobrecarga operacional e manter uma visualização consolidada dos registros, implemente uma estratégia de registro que seja consistente sempre que seus clusters forem implantados. Os clusters do Anthos são integrados ao Cloud Logging por padrão e devem permanecer configurados.

Todos os clusters do GKE têm registros de auditoria do Kubernetes ativados por padrão, o que mantém um registro cronológico das chamadas feitas ao servidor da API do Kubernetes. As entradas de registro de auditoria do Kubernetes são úteis para investigar solicitações de API suspeitas, coletar estatísticas ou criar alertas de monitoramento para chamadas de API indesejadas.

Os clusters do GKE integram o Kubernetes Audit Logging com os registros de auditoria do Cloud e com o Cloud Logging. Os registros podem ser exportados do Cloud Logging para seus próprios sistemas de registro.

Deixar a IU da Web do Kubernetes (painel) desativada (padrão para 1.10+)

Recomendação de referência do CIS para GKE: 6.10.1. Verificar se a IU da Web do Kubernetes está desativada

Não ative a IU da Web do Kubernetes (painel) ao executar no GKE.

A IU da web do Kubernetes (painel) é apoiada por uma conta de serviço do Kubernetes altamente privilegiada. O Console do Cloud fornece grande parte da mesma funcionalidade. Portanto, você não precisa dessas permissões.

Para desativar a interface do usuário da Web do Kubernetes:

gcloud container clusters update cluster-name \
    --update-addons=KubernetesDashboard=DISABLED

Deixar o ABAC desativado (padrão para 1.10+)

Recomendação de referência do CIS para GKE: 6.8.4. Verificar se a autorização legada (ABAC) está desativada

Desative o controle de acesso baseado em atributos (ABAC) e, em vez disso, use o controle de acesso baseado em papéis (RBAC) no GKE.

No Kubernetes, o RBAC é usado para conceder permissões a recursos no nível do cluster e do namespace. O RBAC permite definir funções com regras que contêm um conjunto de permissões. O RBAC tem vantagens significativas de segurança e agora está estável no Kubernetes, então é hora de desativar o ABAC.

Se você ainda depende do ABAC, primeiro examine os pré-requisitos para usar o RBAC. Se você atualizou seu cluster de uma versão mais antiga e está usando o ABAC, atualize sua configuração de controles de acesso:

gcloud container clusters update cluster-name \
    --no-enable-legacy-authorization

Para criar um novo cluster com a recomendação acima:

gcloud container clusters create cluster-name \
    --no-enable-legacy-authorization

A seguir