Reforce a segurança do seu cluster

Esta página explica como implementar as práticas recomendadas atuais para proteger o seu cluster do Google Kubernetes Engine (GKE). Este guia dá prioridade a mitigações de segurança de elevado valor que requerem a ação do cliente no momento da criação do cluster. As funcionalidades menos críticas, as definições seguras por predefinição e as que podem ser ativadas após a criação são mencionadas mais tarde no documento.

Este documento destina-se a especialistas em segurança que definem, regem e implementam políticas e procedimentos para proteger os dados de uma organização contra o acesso não autorizado. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Antes de ler esta página, certifique-se de que conhece o seguinte:

Se estiver a criar novos clusters no GKE, muitas destas proteções são ativadas por predefinição. Se estiver a atualizar clusters existentes, certifique-se de que revê regularmente este guia de proteção e ativa novas funcionalidades.

Os clusters criados no modo Autopilot implementam muitas funcionalidades de reforço de segurança do GKE por predefinição.

Muitas destas recomendações, bem como outras configurações incorretas comuns, podem ser verificadas automaticamente através do Security Health Analytics.

Atualize a sua infraestrutura do GKE regularmente

Recomendação de referência do CIS GKE: 6.5.3. Certifique-se de que a atualização automática de nós está ativada para os nós do GKE

Manter a versão do Kubernetes atualizada é uma das coisas mais simples que pode fazer para melhorar a sua segurança. O Kubernetes introduz frequentemente novas funcionalidades de segurança e fornece patches de segurança.

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

No Google Kubernetes Engine, os planos de controlo são corrigidos e atualizados automaticamente. A atualização automática de nós também atualiza automaticamente os nós no seu cluster.

A atualização automática de nós está ativada por predefinição para clusters criados com a Google Cloud consola desde junho de 2019 e para clusters criados com a API a partir de 11 de novembro de 2019.

Se optar por desativar a atualização automática de nós, recomendamos que faça a atualização mensalmente de acordo com o seu próprio horário. Os clusters mais antigos devem ativar a atualização automática de nós e seguir atentamente os boletins de segurança do GKE para patches críticos.

Para saber mais, consulte o artigo Atualizar automaticamente os nós.

Restrinja o acesso à rede ao plano de controlo e aos nós

Recomendações de testes de referência do GKE da CIS: 6.6.2. Preferir clusters nativos de VPC, 6.6.3. Certifique-se de que a opção Redes autorizadas está ativada, 6.6.4. Certifique-se de que os clusters são criados com o ponto final privado ativado e o acesso público desativado, e com a versão 6.6.5. Certifique-se de que os clusters são criados com nós privados

Por predefinição, o painel de controlo e os nós do cluster do GKE têm endereços encaminháveis pela Internet que podem ser acedidos a partir de qualquer endereço IP.

Prática recomendada:

Limite a exposição do painel de controlo e dos nós do cluster à Internet.

Restrinja o acesso ao plano de controlo

Para restringir o acesso ao plano de controlo do cluster do GKE, consulte o artigo Configure o acesso ao plano de controlo. Seguem-se as opções disponíveis para a proteção ao nível da rede:

  • Ponto final baseado em DNS ativado (recomendado): pode controlar quem pode aceder ao ponto final baseado em DNS com os VPC Service Controls. O VPC Service Controls permite-lhe definir um parâmetro de segurança para todas as APIs Google no seu projeto com atributos sensíveis ao contexto, como a origem da rede. Estas definições podem ser controladas centralmente para um projeto em todas as APIs Google, reduzindo o número de locais onde teria de configurar regras de acesso.

  • Acesso aos pontos finais baseados em IP externos e internos desativado: isto impede todo o acesso ao painel de controlo através de pontos finais baseados em IP.

  • Acesso ao ponto final baseado em IP externo desativado: isto impede todo o acesso à Internet a ambos os planos de controlo. Esta é uma boa escolha se tiver configurado a sua rede nas instalações para se ligar ao Google CloudGoogle Cloud através do Cloud Interconnect e da Cloud VPN. Essas tecnologias ligam efetivamente a rede da sua empresa à sua VPC na nuvem.

  • Acesso ao ponto final baseado em IP externo ativado, redes autorizadas ativadas: esta opção oferece acesso restrito ao plano de controlo a partir de endereços IP de origem que define. Esta é uma boa escolha se não tiver uma infraestrutura de VPN existente ou tiver utilizadores remotos ou filiais que se liguem através da Internet pública em vez da VPN corporativa e do Cloud Interconnect ou Cloud VPN.

  • Acesso ao ponto final externo ativado, redes autorizadas desativadas: isto permite que qualquer pessoa na Internet faça ligações de rede ao plano de controlo.

Se usar pontos finais baseados em IP, recomendamos que os clusters usem redes autorizadas.

Isto garante que o plano de controlo é acessível através do seguinte:

  • Os CIDRs permitidos em redes autorizadas.
  • Nós na VPC do cluster.
  • Endereços IP reservados pela Google para fins de gestão de clusters.

Restrinja o acesso a nós

Prática recomendada:

Ative os nós privados nos seus clusters para impedir que os clientes externos acedam aos nós.

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

Isto indica ao GKE para aprovisionar nós com endereços IP internos, o que significa que os nós não são diretamente acessíveis através da Internet pública.

Restrinja o acesso anónimo a pontos finais do cluster

Esta melhoria de segurança ajuda a mitigar os riscos associados à associação de funções acidental ou maliciosa, limitando o acesso anónimo aos pontos finais do cluster. Por predefinição, o Kubernetes atribui o utilizador system:anonymous e o grupo system:unauthenticated a pedidos anónimos a pontos finais do cluster. Se esse utilizador ou grupo tiver autorizações no cluster através de associações RBAC, pode conceder a um utilizador anónimo acesso não intencional a pontos finais que podem ser usados para comprometer a segurança de um serviço ou do próprio cluster.

A menos que sejam explicitamente restritos através de associações RBAC, os pedidos de autenticação anónimos são aceites para todos os pontos finais do cluster. Na versão 1.32.2-gke.1234000 e posteriores do GKE, quando cria ou atualiza um cluster, pode limitar o conjunto de pontos finais que os pedidos anónimos podem alcançar apenas aos três pontos finais de verificação do estado do servidor da API Kubernetes: /healthz, /livez e /readyz. O acesso anónimo a estes pontos finais de verificação do estado é necessário para verificar se um cluster está a funcionar corretamente.

Para limitar o acesso anónimo aos pontos finais do cluster, especifique LIMITED para a flag --anonymous-authentication-config em qualquer um dos seguintes comandos da CLI gcloud:

A flag --anonymous-authentication-config assume o valor LIMITED ou ENABLED. O valor predefinido é ENABLED. Quando define o valor como LIMITED, os pedidos anónimos são rejeitados durante a autenticação, mesmo que esse acesso seja permitido por associações RBAC existentes. As solicitações rejeitadas devolvem um estado HTTP de 401.

Conforme mostrado no exemplo seguinte, pode usar uma restrição da política da organização para aplicar esta restrição de acesso nos clusters da sua organização:

name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeAnonymousAccessLimited
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    - UPDATE
    condition: "condition:resource.anonymousAuthenticationConfig.mode == "LIMITED"
    action: ALLOW
    displayName: Restrict anonymous access to cluster endpoints.
    description: All new and updated clusters must restrict anonymous access to cluster endpoints.

Substitua ORGANIZATION_ID pelo ID da sua organização, como 123456789.

Não dependa apenas desta capacidade para proteger o seu cluster. Considere medidas de segurança adicionais, como as seguintes:

Para informações sobre a implementação subjacente do Kubernetes para esta melhoria, consulte a configuração do autenticador anónimo. Para mais informações sobre as políticas de controlo de acesso baseado em funções (CABF), consulte as práticas recomendadas para o CABF do GKE.

Use regras de firewall de privilégio mínimo

Minimize o risco de acesso não intencional através do princípio do menor privilégio para regras de firewall

O GKE cria regras de firewall da VPC predefinidas para ativar a funcionalidade do sistema e aplicar boas práticas de segurança. Para ver uma lista completa das regras da firewall criadas automaticamente, consulte o artigo Regras da firewall criadas automaticamente.

O GKE cria estas regras de firewall predefinidas com uma prioridade de 1000. Se criar regras de firewall permissivas com uma prioridade mais alta, por exemplo, uma regra de firewall allow-all para depuração, o cluster corre o risco de acesso não intencional.

Use a autenticação de grupo

Recomendação do teste de referência do CIS GKE: 6.8.3. Considere gerir os utilizadores do RBAC do Kubernetes com o Grupos Google para RBAC

Deve usar grupos para gerir os seus utilizadores. A utilização de grupos permite que as identidades sejam controladas através do seu sistema de gestão de identidades e dos administradores de identidades. O ajuste da associação ao grupo elimina a necessidade de atualizar a configuração do RBAC sempre que alguém é adicionado ou removido do grupo.

Para gerir as autorizações dos utilizadores através dos Grupos Google, tem de ativar os Grupos Google para RBAC no seu cluster. Isto permite-lhe gerir utilizadores com as mesmas autorizações, ao mesmo tempo que permite aos administradores de identidade gerir os utilizadores de forma centralizada e consistente.

Consulte o artigo Grupos Google para RBAC para ver instruções sobre como ativar os Grupos Google para RBAC.

Configure a segurança para nós de contentores

As secções seguintes descrevem as opções de configuração de nós seguros.

Ative os nós do GKE protegidos

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

Os nós do GKE protegidos oferecem uma identidade e uma integridade do nó fortes e validáveis para aumentar a segurança dos nós do GKE e devem ser ativados em todos os clusters do GKE.

Pode ativar os nós do GKE protegidos durante a criação ou a atualização do cluster. Os nós do GKE protegidos devem estar ativados com o arranque seguro. Não deve usar o arranque seguro se precisar de módulos do kernel não assinados de terceiros. Para obter instruções sobre como ativar os nós do GKE protegidos e como ativar o arranque seguro com os nós do GKE protegidos, consulte o artigo Usar nós do GKE protegidos.

Escolha uma imagem de nó reforçada com o tempo de execução do containerd

A imagem do SO otimizado para contentores com o containerd (cos_containerd) é uma variante da imagem do SO otimizado para contentores com o containerd como o tempo de execução do contentor principal diretamente integrado com o Kubernetes.

O containerd é o componente de tempo de execução principal do Docker e foi concebido para fornecer a funcionalidade de contentor principal para a Kubernetes Container Runtime Interface (CRI). É significativamente menos complexo do que o daemon Docker completo e, por isso, tem uma superfície de ataque mais pequena.

Para usar a imagem cos_containerd no seu cluster, consulte Imagens do Containerd.

A imagem cos_containerd é a imagem preferencial para o GKE, porque foi criada, otimizada e protegida especificamente para a execução de contentores.

Ative a federação de identidades da carga de trabalho para o GKE

Recomendação de testes de referência do CIS GKE: 6.2.2. Prefira usar Google Cloud contas de serviço e o Workload Identity dedicados

A federação de identidade da carga de trabalho para o GKE é a forma recomendada de autenticar as Google Cloud APIs.

A Workload Identity Federation para o GKE substitui a necessidade de usar o ocultamento de metadados e, como tal, as duas abordagens são incompatíveis. Os metadados confidenciais protegidos pelo ocultamento de metadados também estão protegidos pela federação de identidade de cargas de trabalho para o GKE.

Reforce o isolamento de cargas de trabalho com o GKE Sandbox

Recomendação de testes de referência do GKE da CIS: 6.10.4. Considere usar a GKE Sandbox para reforçar o isolamento da carga de trabalho, especialmente para cargas de trabalho não fidedignas

O GKE Sandbox oferece uma camada adicional de segurança para impedir que código malicioso afete o kernel anfitrião nos nós do cluster.

Pode executar contentores num ambiente em sandbox para mitigar a maioria dos ataques de fuga de contentores, também denominados ataques de escalada de privilégios locais. Para ver as vulnerabilidades de fuga de contentores anteriores, consulte os boletins de segurança. Este tipo de ataque permite que um atacante aceda à VM anfitriã do contentor e, por conseguinte, aceda a outros contentores na mesma VM. Uma sandbox, como a GKE Sandbox, pode ajudar a limitar o impacto destes ataques.

Deve considerar a criação de uma sandbox para uma carga de trabalho em situações como:

  • A carga de trabalho executa código não fidedigno
  • Quer limitar o impacto se um atacante comprometer um contentor na carga de trabalho.

Saiba como usar o GKE Sandbox em Reforce o isolamento da carga de trabalho com o GKE Sandbox.

Ative as notificações de boletins de segurança

Quando estão disponíveis boletins de segurança relevantes para o seu cluster, o GKE publica notificações sobre esses eventos como mensagens em tópicos do Pub/Sub que configurar. Pode receber estas notificações numa subscrição do Pub/Sub, integrá-las com serviços de terceiros e filtrá-las pelos tipos de notificações que quer receber.

Para mais informações sobre como receber boletins de segurança através de notificações de clusters do GKE, consulte o artigo Notificações de clusters.

Desative a porta só de leitura do kubelet não segura

Desative a porta só de leitura do kubelet e mude todas as cargas de trabalho que usam a porta 10255 para usar a porta mais segura 10250.

O processo kubelet em execução nos nós publica uma API só de leitura através da porta não segura 10255. O Kubernetes não realiza verificações de autenticação nem de autorização nesta porta. O kubelet serve os mesmos pontos finais na porta autenticada 10250 mais segura.

Para ver instruções, consulte o artigo Desative a porta só de leitura do kubelet nos clusters do GKE.

Conceda autorizações de acesso

As secções seguintes descrevem como conceder acesso à sua infraestrutura do GKE.

Use contas de serviço IAM com o menor número possível de privilégios

Recomendação de referência do GKE da CIS: 6.2.1. Prefira não executar clusters do GKE com a conta de serviço predefinida do Compute Engine

O GKE usa contas de serviço da IAM anexadas aos seus nós para executar tarefas do sistema, como registo e monitorização. No mínimo, estas contas de serviço de nós têm de ter a função Conta de serviço de nós predefinida do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por predefinição, o GKE usa a conta de serviço predefinida do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.

Se usar a conta de serviço predefinida do Compute Engine para outras funções no seu projeto ou organização, a conta de serviço pode ter mais autorizações do que o GKE precisa, o que pode expô-lo a riscos de segurança.

A conta de serviço anexada aos seus nós deve ser usada apenas por cargas de trabalho do sistema que realizam tarefas como registo e monitorização. Para as suas próprias cargas de trabalho, aprovisione identidades através da federação de identidade da carga de trabalho para o GKE.

Para criar uma conta de serviço personalizada e conceder-lhe a função necessária para o GKE, conclua os seguintes passos:

Consola

  1. Ative a Cloud Resource Manager API:

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  2. Aceda à página Contas de serviço:

    Aceda a Contas de serviço

  3. Clique em Criar conta de serviço.
  4. Introduza um nome para a conta de serviço. O campo ID da conta de serviço gera automaticamente um ID exclusivo para a conta de serviço com base no nome.
  5. Clique em Criar e continuar.
  6. No menu Selecionar uma função, selecione a função Conta de serviço do nó predefinido do Kubernetes Engine.
  7. Clique em Concluído.

gcloud

  1. Ative a API Cloud Resource Manager: 
    gcloud services enable cloudresourcemanager.googleapis.com
  2. Crie a conta de serviço: 
    gcloud iam service-accounts create SA_NAME

    Substitua SA_NAME por um nome exclusivo que identifique a conta de serviço.

  3. Conceda a função Conta de serviço de nó predefinida do Kubernetes Engine (roles/container.defaultNodeServiceAccount) à conta de serviço: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role=roles/container.defaultNodeServiceAccount

    Substitua o seguinte:

    • PROJECT_ID: o ID do seu Google Cloud projeto.
    • SA_NAME: o nome da conta de serviço que criou.

Terraform

Crie uma conta de serviço de IAM e conceda-lhe a função roles/container.defaultNodeServiceAccount no projeto:

resource "google_service_account" "default" {
  account_id   = "gke-node-service-account"
  display_name = "GKE node service account"
}

data "google_project" "project" {
}

resource "google_project_iam_member" "default" {
  project = data.google_project.project.project_id
  role    = "roles/container.defaultNodeServiceAccount"
  member  = "serviceAccount:${google_service_account.default.email}"
}

Config Connector

Nota: este passo requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no seu cluster.

  1. Para criar a conta de serviço, transfira o seguinte recurso como service-account.yaml: 
    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [SA_NAME]
spec:
  displayName: [DISPLAY_NAME]

    Substitua o seguinte:

    • [SA_NAME]: o nome da nova conta de serviço.
    • [DISPLAY_NAME]: um nome a apresentar para a conta de serviço.
  2. Crie a conta de serviço: 
    kubectl apply -f service-account.yaml
  3. Aplique a função roles/logging.logWriter à conta de serviço:
    1. Transfira o seguinte recurso como policy-logging.yaml. 
      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]

      Substitua o seguinte:

      • [SA_NAME]: o nome da conta de serviço.
      • [PROJECT_ID]: o ID do seu Google Cloud projeto.
    2. Aplique a função à conta de serviço: 
      kubectl apply -f policy-logging.yaml
  4. Aplique a função roles/monitoring.metricWriter à conta de serviço:
    1. Transfira o seguinte recurso como policy-metrics-writer.yaml. Substitua [SA_NAME] e [PROJECT_ID] pelas 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]

      Substitua o seguinte:

      • [SA_NAME]: o nome da conta de serviço.
      • [PROJECT_ID]: o ID do seu Google Cloud projeto.
    2. Aplique a função à conta de serviço: 
      kubectl apply -f policy-metrics-writer.yaml
  5. Aplique a função roles/monitoring.viewer à conta de serviço:
    1. Transfira o seguinte recurso como policy-monitoring.yaml. 
      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]

      Substitua o seguinte:

      • [SA_NAME]: o nome da conta de serviço.
      • [PROJECT_ID]: o ID do seu Google Cloud projeto.
    2. Aplique a função à conta de serviço: 
      kubectl apply -f policy-monitoring.yaml
  6. Aplique a função roles/autoscaling.metricsWriter à conta de serviço:
    1. Transfira o seguinte recurso como policy-autoscaling-metrics-writer.yaml. 
      apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-autoscaling-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/autoscaling.metricsWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

      Substitua o seguinte:

      • [SA_NAME]: o nome da conta de serviço.
      • [PROJECT_ID]: o ID do seu Google Cloud projeto.
    2. Aplique a função à conta de serviço: 
      kubectl apply -f policy-autoscaling-metrics-writer.yaml

Também pode usar esta conta de serviço para recursos noutros projetos. Para ver instruções, consulte o artigo Ativar a representação de contas de serviço em vários projetos.

Conceda acesso a repositórios de imagens privados

Para usar imagens privadas no Artifact Registry, conceda o papel de leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço.

gcloud

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Substitua REPOSITORY_NAME pelo nome do seu repositório do Artifact Registry.

Config Connector

Nota: este passo requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no seu cluster.

  1. Guarde o seguinte manifesto como policy-artifact-registry-reader.yaml:

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-artifact-registry-reader
spec:
  member: serviceAccount:"SA_NAME"@"PROJECT_ID".iam.gserviceaccount.com
  role: roles/artifactregistry.reader
  resourceRef:
    apiVersion: artifactregistry.cnrm.cloud.google.com/v1beta1
    kind: ArtifactRegistryRepository
    name: "REPOSITORY_NAME"

    Substitua o seguinte:

    • SA_NAME: o nome da sua conta de serviço de IAM.
    • PROJECT_ID: o ID do seu Google Cloud projeto.
    • REPOSITORY_NAME: o nome do seu repositório do Artifact Registry.

  2. Conceda a função Leitor do Artifact Registry à conta de serviço:

    kubectl apply -f policy-artifact-registry-reader.yaml

Se usar imagens privadas no Container Registry, também tem de conceder acesso a essas imagens:

gcloud

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

O contentor que armazena as suas imagens tem o nome BUCKET_NAME no seguinte formato:

  • artifacts.PROJECT_ID.appspot.com para imagens enviadas para um registo no anfitrião gcr.io ou
  • STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

Substitua o seguinte:

  • PROJECT_ID: o ID do projeto da consola Google Cloud .
  • STORAGE_REGION: a localização do contentor de armazenamento:
    • us para registos no anfitrião us.gcr.io
    • eu para registos no anfitrião eu.gcr.io
    • asia para registos no anfitrião asia.gcr.io

Consulte a gcloud storage buckets add-iam-policy-binding documentação para mais informações sobre o comando.

Config Connector

Nota: este passo requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no seu cluster.

Aplique a função storage.objectViewer à sua conta de serviço. Transfira o seguinte recurso como policy-object-viewer.yaml. Substitua [SA_NAME] e [PROJECT_ID] pelas 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 utilizador humano possa criar novos clusters ou conjuntos de nós com esta conta de serviço, tem de lhe conceder a função Utilizador da 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

Nota: este passo requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no seu cluster.

Aplique a função iam.serviceAccountUser à sua conta de serviço. Transfira o seguinte recurso como policy-service-account-user.yaml. Substitua [SA_NAME] e [PROJECT_ID] pelas 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

Para clusters padrão existentes, já pode criar um novo conjunto de nós com esta nova conta de serviço. Para clusters do Autopilot, tem de criar um novo cluster com a conta de serviço. Para ver instruções, consulte o artigo Crie um cluster do Autopilot.

  • Crie um node pool que use a nova conta de serviço:

    gcloud container node-pools create NODE_POOL_NAME \
--service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--cluster=CLUSTER_NAME

Se precisar que o seu cluster do GKE tenha acesso a outros Google Cloud serviços, deve usar a Federação do Workload Identity para o GKE.

Restrinja o acesso à deteção da API de clusters

Por predefinição, o Kubernetes inicializa clusters com um conjunto permissivo de ClusterRoleBindings de descoberta que dão acesso amplo a informações sobre as APIs de um cluster, incluindo as de CustomResourceDefinitions.

Os utilizadores devem ter em atenção que o grupo system:authenticated incluído nos assuntos dos system:discovery e system:basic-user ClusterRoleBindings pode incluir qualquer utilizador autenticado (incluindo qualquer utilizador com uma Conta Google) e não representa um nível de segurança significativo para clusters no GKE. Para mais informações, consulte o artigo Evite funções e grupos predefinidos.

Os utilizadores que pretendam reforçar as APIs de descoberta do respetivo cluster devem considerar uma ou mais das seguintes opções:

  • Ative apenas o ponto final baseado em DNS para aceder ao plano de controlo.
  • Configure redes autorizadas para restringir o acesso a intervalos de IP definidos.
  • Restrinja o acesso ao plano de controlo e ative os nós privados.

Se nenhuma destas opções for adequada para o seu exemplo de utilização do GKE, deve tratar todas as informações de deteção de APIs (nomeadamente, o esquema de CustomResources, as definições de APIService e as informações de deteção alojadas por servidores de APIs de extensão) como divulgadas publicamente.

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

Recomendação de testes de referência do CIS GKE: 5.6.1. Crie limites administrativos entre recursos através de espaços de nomes

Conceda às equipas o acesso com privilégios mínimos ao Kubernetes criando espaços de nomes ou clusters separados para cada equipa e ambiente. Atribua centros de custos e etiquetas adequadas a cada espaço de nomes para responsabilidade e reembolso. Conceda apenas aos programadores o nível de acesso ao respetivo espaço de nomes de que precisam para implementar e gerir a respetiva aplicação, especialmente em produção. Mapeie as tarefas que os seus utilizadores têm de realizar em relação ao cluster e defina as autorizações de que precisam para realizar cada tarefa.

Para mais informações sobre a criação de espaços de nomes, consulte a documentação do Kubernetes. Para ver as práticas recomendadas ao planear a configuração do RBAC, consulte o artigo Práticas recomendadas para o RBAC do GKE.

O IAM e o controlo de acesso baseado em funções (CABF) funcionam em conjunto, e uma entidade tem de ter autorizações suficientes em qualquer um dos níveis para trabalhar com recursos no seu cluster.

Atribua as funções do IAM adequadas para o GKE a grupos e utilizadores para conceder autorizações ao nível do projeto e use o RBAC para conceder autorizações ao nível do cluster e do espaço de nomes. Para saber mais, consulte o artigo Controlo de acesso.

Pode usar as autorizações de IAM e CABF juntamente com os espaços de nomes para restringir as interações dos utilizadores com os recursos do cluster na Google Cloud consola. Para mais informações, consulte o artigo Ative o acesso e veja os recursos do cluster por espaço de nomes.

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

Recomendação de testes de referência do CIS GKE: 6.6.7. Certifique-se de que a política de rede está ativada e definida conforme adequado

Por predefinição, todos os pods num cluster podem comunicar entre si. Deve controlar a comunicação entre pods conforme necessário para as suas cargas de trabalho.

Restringir o acesso à rede aos serviços torna muito mais difícil para os atacantes moverem-se lateralmente no cluster e também oferece aos serviços alguma proteção contra a negação de serviço acidental ou deliberada. Duas formas recomendadas de controlar o tráfego são:

  1. Use Istio. Consulte o artigo Instalar o Istio no Google Kubernetes Engine se tiver interesse no balanceamento de carga, na autorização de serviços, na limitação, na quota, nas métricas e muito mais.
  2. Use políticas de rede do Kubernetes. Consulte o artigo Criar uma política de rede de cluster. Escolha esta opção se estiver à procura da funcionalidade de controlo de acesso básico exposta pelo Kubernetes. Para implementar abordagens comuns para restringir o tráfego através de políticas de rede, siga o guia de implementação dos GKE Enterprise Security Blueprints. Além disso, a documentação do Kubernetes tem um excelente tutorial para uma implementação simples do nginx. Considere usar o registo de políticas de rede para verificar se as políticas de rede estão a funcionar conforme esperado.

O Istio e a política de rede podem ser usados em conjunto, se necessário.

Proteja os seus dados com a gestão de segredos

Recomendação de testes de referência do CIS GKE: 6.3.1. Considere encriptar segredos do Kubernetes com chaves geridas no Cloud KMS

Use uma ferramenta de gestão de segredos externa para armazenar dados confidenciais fora do cluster e aceder a esses dados de forma programática.

No Kubernetes, pode armazenar dados confidenciais em objetos Secret no seu cluster. Os segredos permitem-lhe fornecer dados confidenciais às aplicações sem incluir esses dados no código da aplicação. No entanto, o armazenamento destes dados no seu cluster tem riscos, como os seguintes:

  • Qualquer pessoa que possa criar Pods num namespace pode ler os dados de qualquer Secret nesse namespace.
  • Qualquer pessoa com acesso RBAC ou IAM para ler todos os objetos da API Kubernetes pode ler segredos.

Sempre que possível, use um serviço de gestão de segredos externo, como o Secret Manager, para armazenar os seus dados confidenciais fora do cluster. Crie segredos no cluster apenas quando não puder fornecer esses dados às suas cargas de trabalho de outra forma. Recomendamos os seguintes métodos, por ordem de preferência, para aceder aos seus segredos:

  • Bibliotecas cliente do Secret Manager: aceda programaticamente a segredos a partir do código da sua aplicação através da API Secret Manager com a federação de identidade da força de trabalho para o GKE. Para mais informações, consulte o artigo Aceda a segredos armazenados fora dos clusters do GKE através de bibliotecas de cliente.
  • Dados do Secret Manager como volumes montados: forneça dados confidenciais aos seus pods como volumes montados através do suplemento Secret Manager para GKE. Este método é útil se não conseguir modificar o código da sua aplicação para usar as bibliotecas de cliente do Secret Manager. Para mais informações, consulte o artigo Use o suplemento Secret Manager com o Google Kubernetes Engine.

  • Ferramentas de gestão de segredos de terceiros: as ferramentas de terceiros, como o HashiCorp Vault, oferecem capacidades de gestão de segredos para cargas de trabalho do Kubernetes. Estas ferramentas requerem uma configuração inicial mais complexa do que o Secret Manager, mas são uma opção mais segura do que criar Secrets no cluster. Para configurar uma ferramenta de terceiros para a gestão de segredos, consulte a documentação do fornecedor. Além disso, considere as seguintes recomendações:

    • Se a ferramenta de terceiros for executada num cluster, use um cluster diferente do cluster que executa as suas cargas de trabalho.
    • Use o Cloud Storage ou o Spanner para armazenar os dados da ferramenta.
    • Use um Network Load Balancer de encaminhamento interno para expor a ferramenta de gestão de segredos de terceiros aos pods que são executados na sua rede VPC.

  • Usar segredos do Kubernetes (não recomendado): se nenhuma das opções anteriores for adequada para o seu exemplo de utilização, pode armazenar os dados como segredos do Kubernetes. Google Cloud Encripta os dados na camada de armazenamento por predefinição. Esta encriptação da camada de armazenamento predefinida inclui a base de dados que armazena o estado do seu cluster, que se baseia no etcd ou no Spanner. Além disso, pode encriptar estes segredos na camada de aplicação com uma chave que gere. Para mais informações, consulte o artigo Encriptar segredos na camada de aplicação.

Use controladores de admissão para aplicar a política

Os controladores de admissão são plug-ins que regem e aplicam a forma como o cluster é usado. Têm de estar ativadas para usar algumas das funcionalidades de segurança mais avançadas do Kubernetes e são uma parte importante da abordagem de defesa em profundidade para reforçar o seu cluster

Por predefinição, os pods no Kubernetes podem funcionar com capacidades além do que requerem. Deve restringir as capacidades do pod apenas àquelas necessárias para essa carga de trabalho.

O Kubernetes suporta vários controlos para restringir a execução dos seus pods apenas com capacidades concedidas explicitamente. Por exemplo, o Policy Controller está disponível para clusters em frotas. O Kubernetes também tem o controlador de admissão PodSecurity integrado que lhe permite aplicar as normas de segurança de pods em clusters individuais.

O Policy Controller é uma funcionalidade do GKE Enterprise que lhe permite aplicar e validar a segurança nos clusters do GKE em grande escala através de políticas declarativas. Para saber como usar o Policy Controller para aplicar controlos declarativos no seu cluster do GKE, consulte o artigo Instale o Policy Controller.

O controlador de admissão PodSecurity permite-lhe aplicar políticas predefinidas em espaços de nomes específicos ou em todo o cluster. Estas políticas correspondem às diferentes normas de segurança de pods.

Restrinja a capacidade de as cargas de trabalho se automodificarem

Determinadas cargas de trabalho do Kubernetes, especialmente cargas de trabalho do sistema, têm autorização para se automodificarem. Por exemplo, algumas cargas de trabalho são dimensionadas automaticamente na vertical. Embora seja conveniente, isto pode permitir que um atacante que já comprometeu um nó avance ainda mais no cluster. Por exemplo, um atacante pode ter uma carga de trabalho no próprio nó que se altera para ser executada como uma conta de serviço mais privilegiada que existe no mesmo espaço de nomes.

Idealmente, as cargas de trabalho não devem ter autorização para se modificarem a si próprias. Quando a automodificação é necessária, pode limitar as autorizações aplicando restrições do Gatekeeper ou do Policy Controller, como NoUpdateServiceAccount da biblioteca de código aberto do Gatekeeper, que fornece várias políticas de segurança úteis.

Quando implementa políticas, normalmente, é necessário permitir que os controladores que gerem o ciclo de vida do cluster ignorem as políticas. Isto é necessário para que os controladores possam fazer alterações ao cluster, como aplicar atualizações do cluster. Por exemplo, se implementar a política NoUpdateServiceAccount no GKE, tem de definir os seguintes parâmetros no Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Restrinja a utilização do gcePersistentDisk tipo de volume descontinuado

O tipo de volume gcePersistentDiskobsoleto permite-lhe montar um disco persistente do Compute Engine em pods. Recomendamos que restrinja a utilização do gcePersistentDisk tipo de volume nas suas cargas de trabalho. O GKE não efetua verificações de autorização da IAM no pod quando monta este tipo de volume, embora Google Cloud efetue verificações de autorização quando anexa o disco à VM subjacente. Por conseguinte, um atacante que já tenha a capacidade de criar pods num espaço de nomes pode aceder ao conteúdo dos discos persistentes do Compute Engine no seu projeto do Google Cloud .

Para aceder e usar discos persistentes do Compute Engine, use PersistentVolumes e PersistentVolumeClaims. Aplique políticas de segurança no seu cluster que impeçam a utilização do tipo de volume gcePersistentDisk.

Para impedir a utilização do tipo de volume gcePersistentDisk, aplique a política de base ou restrita com o controlador de admissão PodSecurity ou pode definir uma restrição personalizada no Policy Controller ou no controlador de admissão Gatekeeper.

Para definir uma restrição personalizada para restringir este tipo de volume, faça o seguinte:

  1. Instale um controlador de admissão baseado em políticas, como o Policy Controller ou o Gatekeeper OPA.

    Controlador de políticas

    Instale o Policy Controller no seu cluster.

    O Policy Controller é uma funcionalidade paga para utilizadores do GKE. O Policy Controller baseia-se no Gatekeeper de código aberto, mas também tem acesso à biblioteca completa de modelos de restrições, pacotes de políticas e integração com os painéis de controlo da consola Google Cloud para ajudar a observar e manter os seus clusters. Os pacotes de políticas são práticas recomendadas opinativas que pode aplicar aos seus clusters, incluindo pacotes baseados em recomendações como o CIS Kubernetes Benchmark.

    Gatekeeper

    Instale o Gatekeeper no seu cluster.

    Para clusters do Autopilot, abra o manifesto do Gatekeeper num editor de texto.gatekeeper.yaml Modifique o campo rules na especificação MutatingWebhookConfiguration para substituir os carateres universais (*) por grupos de API e nomes de recursos específicos, como no exemplo seguinte:

    apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- admissionReviewVersions:
  - v1
  - v1beta1
  ...
  rules:
  - apiGroups:
    - core
    - batch
    - apps
    apiVersions:
    - '*'
    operations:
    - CREATE
    - UPDATE
    resources:
    - Pod
    - Deployment
    - Job
    - Volume
    - Container
    - StatefulSet
    - StorageClass
    - Secret
    - ConfigMap
  sideEffects: None
  timeoutSeconds: 1

    Aplique o manifesto gatekeeper.yaml atualizado ao cluster do Autopilot para instalar o Gatekeeper. Isto é necessário porque, como medida de segurança integrada, o Autopilot não permite carateres universais em webhooks de admissão de mutação.

  2. Implemente o ConstraintTemplate de tipos de volumes da política de segurança de agrupamentos integrada:

    kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml

  3. Guarde a seguinte restrição com uma lista de tipos de volumes permitidos como constraint.yaml:

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: k8sPSPVolumeTypes
metadata:
  name: nogcepersistentdisk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pods"]
  parameters:
    volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]

    Esta restrição limita os volumes à lista no campo spec.parameters.volumes.

  4. Implemente a restrição:

    kubectl apply -f constraint.yaml

Monitorize a configuração do cluster

Deve auditar as configurações do cluster para verificar se existem desvios em relação às definições definidas.

Muitas das recomendações abordadas neste guia de reforço, bem como outras configurações incorretas comuns, podem ser verificadas automaticamente através da análise de segurança.

Reveja as opções predefinidas seguras

As secções seguintes descrevem as opções que são configuradas de forma segura por predefinição em novos clusters. Deve verificar se os clusters preexistentes estão configurados de forma segura.

Proteja os metadados dos nós

Recomendações de testes de referência do CIS GKE: 6.4.1. Certifique-se de que as APIs de metadados de instâncias do Compute Engine antigas estão desativadas e que a versão é 6.4.2. Certifique-se de que o servidor de metadados do GKE está ativado

Os pontos finais do servidor de metadados do Compute Engine v0.1 e v1beta1 foram descontinuados e encerrados a 30 de setembro de 2020. Estes pontos finais não aplicaram cabeçalhos de consulta de metadados. Para o cronograma de encerramento, consulte o artigo v0.1 e v1beta1 descontinuação dos pontos finais do servidor de metadados.

Alguns ataques práticos contra o Kubernetes baseiam-se no acesso ao servidor de metadados da VM para extrair credenciais. Estes ataques são bloqueados se estiver a usar a Federação de identidades de cargas de trabalho para o GKE ou a ocultação de metadados.

Deixe os métodos de autenticação de cliente antigos desativados

Recomendações de testes de referência do GKE da CIS: 6.8.1. Certifique-se de que a autenticação básica com palavras-passe estáticas está desativada e que tem a versão 6.8.2. Certifique-se de que a autenticação através de certificados de cliente está desativada

Existem vários métodos de autenticação no servidor da API Kubernetes. No GKE, os métodos suportados são tokens de portador de contas de serviço, tokens OAuth e certificados de cliente x509. O GKE gere a autenticação com o gcloud por si através do método de token OAuth, configurando a configuração do Kubernetes, obtendo um token de acesso e mantendo-o atualizado.

Antes da integração do GKE com o OAuth, um certificado x509 gerado uma vez ou uma palavra-passe estática eram os únicos métodos de autenticação disponíveis, mas agora não são recomendados e devem ser desativados. Estes métodos apresentam uma superfície de ataque mais ampla para comprometer o cluster e foram desativados por predefinição desde a versão 1.12 do GKE. Se estiver a usar métodos de autenticação antigos, recomendamos que os desative. A autenticação com uma palavra-passe estática foi descontinuada e removida desde a versão 1.19 do GKE.

Os clusters existentes devem mudar para o OAuth. Se um sistema externo ao cluster precisar de uma credencial de longa duração, recomendamos que crie uma conta de serviço Google ou uma conta de serviço Kubernetes com os privilégios necessários e exporte a chave.

Para atualizar um cluster existente e remover a palavra-passe estática, consulte o artigo Desativar a autenticação com uma palavra-passe estática.

Atualmente, não existe forma de remover o certificado de cliente pré-emitido de um cluster existente, mas não tem autorizações se o RBAC estiver ativado e o ABAC estiver desativado.

Manter o Cloud Logging ativado

Recomendação de testes de referência do CIS GKE: 6.7.1. Certifique-se de que o Stackdriver Kubernetes Logging and Monitoring está ativado

Para reduzir os custos operacionais e manter uma vista consolidada dos seus registos, implemente uma estratégia de registo consistente onde quer que os seus clusters estejam implementados. Os clusters do GKE Enterprise estão integrados com o Cloud Logging por predefinição e devem permanecer configurados.

Todos os clusters do GKE têm o registo de auditoria do Kubernetes ativado por predefinição, que mantém um registo cronológico das chamadas feitas ao servidor da API Kubernetes. As entradas do registo de auditoria do Kubernetes são úteis para investigar pedidos de API suspeitos, recolher estatísticas ou criar alertas de monitorização para chamadas API indesejadas.

Os clusters do GKE integram o registo de auditoria do Kubernetes com os registos de auditoria da nuvem e o Cloud Logging. Os registos podem ser encaminhados do Cloud Logging para os seus próprios sistemas de registo.

Deixe a IU da Web do Kubernetes (painel de controlo) desativada

Recomendação de testes de referência do CIS GKE: 6.10.1. Certifique-se de que a IU da Web do Kubernetes está desativada

Não deve ativar a IU Web do Kubernetes (painel de controlo) quando estiver em execução no GKE.

A IU Web do Kubernetes (painel de controlo) é suportada por uma conta de serviço do Kubernetes com privilégios elevados. A Google Cloud consola oferece grande parte da mesma funcionalidade, pelo que não precisa destas autorizações.

Para desativar a IU da Web do Kubernetes:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=KubernetesDashboard=DISABLED

Deixe o ABAC desativado

Recomendação de testes de referência do CIS GKE: 6.8.4. Certifique-se de que a autorização antiga (ABAC) está desativada

Deve desativar o controlo de acesso baseado em atributos (CABF) e, em alternativa, usar o controlo de acesso baseado em funções (CABF) no GKE.

Por predefinição, o ABAC está desativado para clusters criados com a versão 1.8 e posteriores do GKE. No Kubernetes, o RBAC é usado para conceder autorizações a recursos ao nível do cluster e do espaço de nomes. O RBAC permite-lhe definir funções com regras que contêm um conjunto de autorizações. O RBAC tem vantagens significativas em termos de segurança em relação ao ABAC.

Se ainda estiver a usar o ABAC, reveja primeiro os pré-requisitos para usar o RBAC. Se atualizou o cluster a partir de uma versão mais antiga e está a usar o ABAC, deve atualizar a configuração dos controlos 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

Deixe o controlador de admissão DenyServiceExternalIPs ativado

Não desative o controlador de admissão DenyServiceExternalIPs.

O controlador de admissão DenyServiceExternalIPs impede que os serviços usem ExternalIPs e mitiga uma vulnerabilidade de segurança conhecida.

O controlador de admissão DenyServiceExternalIPs está ativado por predefinição em novos clusters criados nas versões 1.21 e posteriores do GKE. Para clusters atualizados para as versões 1.21 e posteriores do GKE, pode ativar o controlador de admissão através do seguinte comando:

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips

O que se segue?