Aumentar a segurança do cluster

Nesta página, orientamos você na implementação das práticas recomendadas 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.

Este documento é destinado a especialistas em segurança que definem, regem e implementam políticas e procedimentos para proteger os dados de uma organização contra acesso não autorizado. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.

Antes de ler esta página, confira se você conhece os seguintes conceitos:

Se você estiver criando novos clusters no GKE, muitas dessas proteções serão ativadas por padrão. Se você estiver atualizando clusters atuais, consulte regularmente este guia de reforço da proteção e ative os novos recursos.

Os clusters criados no modo Autopilot implementam muitos recursos de proteção do GKE por padrão.

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

Faça upgrade da sua infraestrutura do GKE regularmente

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 planos de controle são corrigidos e atualizados automaticamente. Também é possível manter os nós do cluster atualizados com upgrades automáticos.

O upgrade automático de nós é ativado por padrão para clusters criados com o consoleGoogle Cloud desde junho de 2019 e para clusters criados com a API a partir de 11 de novembro de 2019.

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 as redes autorizadas estão ativadas, 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

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.

Prática recomendada:

Limitar a exposição do plano de controle de cluster e nós à Internet.

Restringir o acesso ao plano de controle

Para restringir o acesso ao plano de controle do cluster do GKE, consulte Configurar o acesso ao plano de controle. Confira as opções de proteção no nível da rede:

  • Endpoint baseado em DNS ativado (recomendado): você pode controlar quem pode acessar o endpoint baseado em DNS com o VPC Service Controls. O VPC Service Controls permite definir um parâmetro de segurança para todas as APIs do Google no seu projeto com atributos sensíveis ao contexto, como origem da rede. Essas configurações podem ser controladas de forma centralizada para um projeto em todas as APIs do Google, reduzindo o número de lugares em que você precisaria configurar regras de acesso.

  • Acesso a endpoints externos e internos com base em IP desativado:isso impede todo o acesso ao plano de controle por endpoints com base em IP.

  • Acesso ao endpoint externo baseado em IP desativado:isso impede todo o acesso à Internet aos dois planos de controle. 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 ao endpoint externo baseado em IP ativado, redes autorizadas ativadas:essa opção fornece acesso restrito ao plano de controle a partir dos endereços IP de origem que você define. 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 externo ativado, redes autorizadas desativadas:isso permite que qualquer pessoa na Internet faça conexões de rede com o plano de controle.

Se você estiver usando endpoints baseados em IP, recomendamos que os clusters usem redes autorizadas.

Isso garante que o plano de controle seja acessível por:

  • CIDRs permitidos em redes autorizadas.
  • nós na VPC do cluster;
  • Endereços IP reservados pelo Google para fins de gerenciamento de cluster.

Restringir o acesso aos nós

Prática recomendada:

Ative os nós particulares nos clusters para impedir que clientes externos acessem os nós.

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

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

Restringir o acesso anônimo aos endpoints do cluster

Essa melhoria de segurança ajuda a reduzir os riscos associados à vinculação de papéis acidental ou maliciosa, limitando o acesso anônimo aos endpoints do cluster. Por padrão, o Kubernetes atribui o usuário system:anonymous e o grupo system:unauthenticated a solicitações anônimas para endpoints de cluster. Se esse usuário ou grupo tiver permissões no cluster por vinculações de RBAC, isso poderá dar a um usuário anônimo acesso não intencional a endpoints que podem ser usados para comprometer a segurança de um serviço ou do próprio cluster.

A menos que sejam explicitamente restritas por vinculações do RBAC, as solicitações de autenticação anônimas são aceitas para todos os endpoints do cluster. Na versão 1.32.2-gke.1234000 e mais recentes do GKE, ao criar ou atualizar um cluster, é possível limitar o conjunto de endpoints que solicitações anônimas podem acessar apenas aos três endpoints de verificação de integridade do servidor da API Kubernetes: /healthz, /livez e /readyz. O acesso anônimo a esses endpoints de verificação de integridade é necessário para verificar se um cluster está funcionando corretamente.

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

A flag --anonymous-authentication-config usa um valor de LIMITED ou ENABLED. O valor padrão é ENABLED. Quando você define o valor como LIMITED, as solicitações anônimas são rejeitadas durante a autenticação, mesmo que esse acesso seja permitido pelas vinculações de RBAC atuais. As solicitações rejeitadas retornam um status HTTP de 401.

Como mostrado no exemplo a seguir, é possível usar uma restrição de política da organização para aplicar essa restrição de acesso em todos os 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 organização, como 123456789.

Não confie apenas nesse recurso para proteger seu cluster. Considere outras medidas de segurança, como:

Para informações sobre a implementação do Kubernetes para essa melhoria, consulte Configuração do autenticador anônimo. Para mais informações sobre políticas de controle de acesso baseado em papéis (RBAC), consulte Práticas recomendadas para RBAC do GKE.

Usar regras de firewall de privilégio mínimo

Minimizar o risco de acesso não intencional usando o princípio do menor privilégio para regras de firewall

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

O GKE cria essas regras de firewall padrão com uma prioridade de 1.000. Se você criar regras de firewall permissivas com uma prioridade mais alta, como uma regra de firewall allow-all para depuração, seu cluster corre o risco de acesso não intencional.

Usar a autenticação de grupo

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

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 no Grupos do Google, ative Grupos do Google para RBAC no cluster. Isso permite que você gerencie usuários com as mesmas permissões e que os administradores de identidade gerenciem usuários de maneira centralizada e consistente.

Consulte Grupos do Google para RBAC para instruções sobre como ativar os Grupos do Google para RBAC.

Configurar a segurança para nós de contêiner

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

Ativar os 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ó confiável para aumentar a segurança dos nós do GKE e precisam ser ativados em todos os clusters do GKE.

É possível ativar os nós do GKE protegidos na criação ou atualização do cluster. 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 instruções sobre como ativar nós protegidos do GKE e como ativar a inicialização segura com nós protegidos do GKE, consulte Como usar nós protegidos do GKE.

Escolha 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, consulte Imagens de contêiner.

A imagem cos_containerd é a preferencial para o GKE porque foi personalizada, otimizada e reforçada com aumento da proteção especificamente para executar contêineres.

Ativar a federação de identidade da carga de trabalho do GKE

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

A federação de identidade da carga de trabalho do GKE é a maneira recomendada de autenticação nas APIs do Google Cloud .

A federação de identidade da carga de trabalho do GKE substitui a necessidade de usar a ocultação de metadados, e, por isso, as duas abordagens são incompatíveis. Os metadados confidenciais protegidos por ocultação de metadados também são protegidos pela federação de identidade da carga de trabalho do GKE.

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.

É possível executar contêineres em um ambiente sandbox para reduzir a maioria dos ataques de escape, também chamados de ataques de escalonamento de privilégios locais. Para vulnerabilidades de escape de contêineres anteriores, consulte os boletins de segurança. Esse tipo de ataque permite que um invasor tenha acesso à VM host do contêiner e, portanto, tenha acesso a outros contêineres na mesma VM. Um sandbox como o GKE Sandbox pode ajudar a limitar o impacto desses ataques.

Considere colocar uma carga de trabalho no sandbox em situações como estas:

  • A carga de trabalho executa um código não confiável
  • Você quer limitar o impacto se um invasor comprometer um contêiner na carga de trabalho.

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

Ativar notificações do boletim de segurança

Quando os boletins de segurança estão disponíveis e são relevantes para o cluster, o GKE publica notificações sobre esses eventos como mensagens para tópicos do Pub/Sub que você configura. É possível receber essas notificações em uma assinatura do Pub/Sub, fazer a integração com serviços de terceiros e filtrar os tipos de notificação que você quer receber.

Para mais informações sobre como receber boletins de segurança usando notificações de cluster do GKE, consulte Notificações de cluster.

Desativar a porta somente leitura do kubelet não segura

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

O processo kubelet em execução nos nós disponibiliza uma API somente leitura usando a porta não segura 10255. O Kubernetes não realiza nenhuma verificação de autenticação ou autorização nessa porta. O kubelet serve aos mesmos endpoints na porta 10250 mais segura e autenticada.

Para instruções, consulte Desativar a porta somente leitura do kubelet em clusters do GKE.

Conceder permissões de acesso

As seções a seguir descrevem como conceder acesso à sua infraestrutura do GKE.

Usar contas de serviço do IAM 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

O GKE usa contas de serviço do IAM anexadas aos nós para executar tarefas do sistema, como geração de registros e monitoramento. No mínimo, essas contas de serviço de nó precisam ter o papel Conta de serviço de nó padrão do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por padrão, o GKE usa a conta de serviço padrão do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.

Se você usar a conta de serviço padrão do Compute Engine para outras funções no projeto ou na organização, ela poderá ter mais permissões do que o GKE precisa, o que pode expor você a riscos de segurança.

A conta de serviço anexada aos nós só deve ser usada por cargas de trabalho do sistema que realizam tarefas como geração de registros e monitoramento. Para suas próprias cargas de trabalho, provisione identidades usando a Federação de Identidade da Carga de Trabalho para GKE.

Para criar uma conta de serviço personalizada e conceder a ela o papel necessário para o GKE, siga estas etapas:

Console

  1. Ative a API Cloud Resource Manager:

    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. Acessar a página Contas de serviço

    Acesse as Contas de serviço

  3. Clique em Criar conta de serviço.
  4. Insira 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 um papel, escolha o papel Conta de serviço de nó padrão 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 o papel Conta de serviço de nó padrão 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:

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

Terraform

Crie uma conta de serviço do IAM e conceda a ela o papel 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

Observação: esta etapa requer o Config Connector. Siga estas instruções 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: 
    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [SA_NAME]
spec:
  displayName: [DISPLAY_NAME]

    Substitua:

    • [SA_NAME]: o nome da nova conta de serviço.
    • [DISPLAY_NAME]: um nome de exibição para a conta de serviço.
  2. Crie a conta de serviço: 
    kubectl apply -f service-account.yaml
  3. Aplique o papel roles/logging.logWriter à conta de serviço:
    1. Faça o download do 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:

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

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

      • [SA_NAME]: o nome da conta de serviço.
      • [PROJECT_ID]: o ID do projeto Google Cloud .
    2. Aplique o papel à conta de serviço: 
      kubectl apply -f policy-monitoring.yaml
  6. Aplique o papel roles/autoscaling.metricsWriter à conta de serviço:
    1. Faça o download do 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:

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

Também é possível usar essa conta de serviço para recursos em outros projetos. Para instruções, consulte Como ativar a representação da conta de serviço em projetos.

Conceder acesso a repositórios de imagens particulares

Para usar imagens particulares 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 repositório do Artifact Registry.

Config Connector

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

  1. Salve 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:

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

  2. Conceda o papel de leitor do Artifact Registry à conta de serviço:

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

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

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 intervalo que armazena as imagens tem o nome BUCKET_NAME do formulário:

  • artifacts.PROJECT_ID.appspot.com para imagens enviadas para um registro no host gcr.io ou
  • STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

Substitua:

  • PROJECT_ID: o ID do projeto do console Google Cloud .
  • STORAGE_REGION: é o local do bucket de armazenamento:
    • us para registros no host us.gcr.io
    • eu para registros no host eu.gcr.io
    • asia para registros no host asia.gcr.io

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

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

Para clusters padrão atuais, agora é possível criar um novo pool de nós com essa nova conta de serviço. Para clusters do Autopilot, é necessário criar um novo cluster com a conta de serviço. Para acessar instruções, consulte Criar um cluster do Autopilot.

  • Crie um pool de nós 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 você precisar que o cluster do GKE tenha acesso a outros serviços do Google Cloud, use a federação de identidade da carga de trabalho para o GKE.

Restringir o acesso à descoberta de APIs do 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 mais informações, consulte Evitar papéis e grupos padrão.

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

  • Ative apenas o endpoint baseado em DNS para acesso ao plano de controle.
  • Configure redes autorizadas para restringir o acesso a intervalos de IP definidos.
  • Restrinja o acesso ao plano de controle e ative nós particulares.

Se nenhuma dessas opções for adequada ao caso de uso do GKE, trate todas as informações de descoberta de API (ou seja, o esquema de CustomResources, definições de APIService e informações de descoberta hospedadas pelos servidores da API de extensão) como divulgadas publicamente.

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. Para ver as práticas recomendadas ao planejar a configuração do RBAC, consulte Práticas recomendadas para o RBAC do GKE.

O IAM e o 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 IAM apropriados para o GKE relacionados a 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.

É possível usar as permissões do IAM e do RBAC juntas com namespaces para restringir interações de usuários com recursos de cluster no console Google Cloud . Saiba mais em Ativar acesso e visualização de recursos do cluster por namespace.

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. Consulte Como instalar o Istio no Google Kubernetes Engine se você tiver interesse 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. Consulte Como criar 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. Para implementar abordagens comuns a fim de restringir o tráfego usando políticas de rede, siga o guia de implementação dos blueprints de segurança do GKE Enterprise. Além disso, a documentação do Kubernetes tem um tutorial incrível para uma implantação simples do nginx. Use o registro de políticas de rede para verificar se as políticas de rede estão funcionando conforme o esperado.

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

Proteja seus dados com o 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

Use uma ferramenta externa de gerenciamento de secrets para armazenar dados sensíveis fora do cluster e acesse esses dados de forma programática.

No Kubernetes, é possível armazenar dados sensíveis em objetos Secret no cluster. Com os Secrets, você pode fornecer dados confidenciais aos aplicativos sem incluir essas informações no código do aplicativo. No entanto, armazenar esses dados no cluster tem riscos como os seguintes:

  • Qualquer pessoa que possa criar pods em um namespace pode ler os dados de qualquer secret nesse namespace.
  • Qualquer pessoa com acesso de leitura a todos os objetos da API do Kubernetes usando RBAC ou IAM pode ler secrets.

Quando possível, use um serviço externo de gerenciamento de secrets, como o Secret Manager, para armazenar seus dados sensíveis fora do cluster. Crie secrets no cluster apenas quando não for possível fornecer esses dados às cargas de trabalho de outra forma. Recomendamos os seguintes métodos, em ordem de preferência, para acessar seus segredos:

  • Bibliotecas de cliente do Secret Manager: acesse secrets de maneira programática no código do aplicativo usando a API Secret Manager com a federação de identidade da carga de trabalho do GKE. Para mais informações, consulte Acessar secrets armazenados fora dos clusters do GKE usando bibliotecas de cliente.
  • Dados do Secret Manager como volumes montados: forneça dados sensíveis aos seus pods como volumes montados usando o complemento do Secret Manager para GKE. Esse método é útil se você não puder modificar o código do aplicativo para usar as bibliotecas de cliente do Secret Manager. Para mais informações, consulte Usar o complemento do Secret Manager com o Google Kubernetes Engine.

  • Ferramentas de gerenciamento de secrets de terceiros: ferramentas de terceiros, como o HashiCorp Vault, oferecem recursos de gerenciamento de secrets para cargas de trabalho do Kubernetes. Essas ferramentas exigem mais configuração inicial 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 gerenciamento de secrets, consulte a documentação do provedor. Além disso, considere as seguintes recomendações:

    • Se a ferramenta de terceiros for executada em um cluster, use um cluster diferente daquele que executa suas cargas de trabalho.
    • Use o Cloud Storage ou o Spanner para armazenar os dados da ferramenta.
    • Use um balanceador de carga de rede de passagem interno para expor a ferramenta de gerenciamento de secrets de terceiros a pods que são executados na sua rede VPC.

  • Usar secrets do Kubernetes (não recomendado): se nenhuma das opções anteriores for adequada para seu caso de uso, armazene os dados como secrets do Kubernetes. OGoogle Cloud criptografa dados na camada de armazenamento por padrão. Essa criptografia padrão da camada de armazenamento inclui o banco de dados que armazena o estado do cluster, que é baseado em etcd ou Spanner. Além disso, é possível criptografar esses secrets na camada de aplicativo com uma chave gerenciada. Para mais informações, consulte Criptografar secrets na camada do aplicativo.

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

Os controladores de admissão 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 é compatível com vários controles para restringir a execução de pods com apenas recursos explicitamente concedidos. Por exemplo, o Policy Controller está disponível para clusters em frotas. O Kubernetes também tem o controlador de admissão do PodSecurity integrado, que permite aplicar os padrões de segurança do pod em clusters individuais.

O Controlador de Políticas é um recurso do GKE Enterprise que permite aplicar e validar a segurança de clusters do GKE em escala usando políticas declarativas. Para saber como usar o Policy Controller para aplicar controles declarativos no cluster do GKE, consulte Instalar o Policy Controller.

O controlador de admissão do PodSecurity permite aplicar políticas predefinidas em namespaces específicos ou em todo o cluster. Essas políticas correspondem aos diferentes padrões de segurança de pods.

Restringir a capacidade de automodificação das cargas de trabalho

Certas cargas de trabalho do Kubernetes, principalmente as cargas de trabalho do sistema, têm permissão para se automodificar. Por exemplo, algumas cargas de trabalho escalonam automaticamente na vertical. Embora seja conveniente, isso pode permitir que um invasor que já tenha comprometido um nó escalone ainda mais no cluster. Por exemplo, um invasor pode fazer com que uma carga de trabalho do nó se automodifique para ser executada como uma conta de serviço com mais privilégios que existe no mesmo namespace.

O ideal é que as cargas de trabalho não recebam permissão para se automodificar. Quando a automodificação for necessária, limite as permissões aplicando restrições do Gatekeeper ou do Policy Controller, como NoUpdateServiceAccount da biblioteca de código aberto do Gatekeeper, que fornece várias medidas de segurança úteis.

Ao implantar políticas, geralmente é necessário permitir que os controladores que gerenciam o ciclo de vida do cluster ignorem as políticas. Isso é necessário para que os controladores possam fazer alterações no cluster, como a aplicação de upgrades de cluster. Por exemplo, se você implantar a política NoUpdateServiceAccount no GKE, será necessário definir os seguintes parâmetros em Constraint:

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

Restringir o uso do tipo de volume gcePersistentDisk descontinuado

O tipo de volume gcePersistentDisk, descontinuado, permite montar um disco permanente do Compute Engine em pods. Recomendamos que você restrinja o uso do tipo de volume gcePersistentDisk nas cargas de trabalho. O GKE não realiza verificações de autorização do IAM no pod ao ativar esse tipo de volume, embora Google Cloud realize verificações de autorização ao anexar o disco à VM subjacente. Um invasor que já consegue criar pods em um namespace pode acessar o conteúdo dos discos permanentes do Compute Engine no seu projeto Google Cloud .

Para acessar e usar os discos permanentes do Compute Engine, use PersistentVolumes e PersistentVolumeClaims. Aplique políticas de segurança no cluster que evitem o uso do tipo de volume gcePersistentDisk.

Para evitar o uso dogcePersistentDisk volume, aplique a política de referência ou restrita com a Controlador de admissão do PodSecurity , ou defina uma restrição personalizada em Controlador de políticas ou no controlador de admissão Gatekeeper.

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

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

    Policy Controller

    Instale o Policy Controller no seu cluster.

    O Policy Controller é baseado no Gatekeeper de código aberto, mas você também tem acesso à biblioteca completa de modelos de restrição, pacotes de políticas e integração com os painéis do console do Google Cloud para ajudar a observar e fazer a manutenção dos clusters. Os pacotes de políticas são práticas recomendadas opinativas que podem ser aplicadas aos clusters, incluindo pacotes com base em recomendações como o Comparativo de mercado CIS do Kubernetes.

    Gatekeeper

    Instale o Gatekeeper no cluster.

    Para clusters do Autopilot, abra o manifesto gatekeeper.yaml do Gatekeeper em um editor de texto. Modifique o campo rules na especificação MutatingWebhookConfiguration para substituir caracteres curinga (*) por nomes de recursos e grupos de API específicos, como no exemplo a seguir:

    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. Isso é necessário porque, como medida de segurança integrada, o Autopilot não permite caracteres curinga na mutação de webhooks de admissão.

  2. Implante o ConstraintTemplate integrado aos tipos de volume da política de segurança de pods:

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

  3. Salve 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"]

    Essa restrição restringe os volumes à lista no campo spec.parameters.volumes.

  4. Implante a restrição:

    kubectl apply -f constraint.yaml

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.

Analisar as opções padrão seguras

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 metadados do nó

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 uso dos endpoints v0.1 e v1beta1 do servidor de metadados do Compute Engine foi suspenso e encerrado em 30 de setembro de 2020. Esses endpoints não impõem cabeçalhos de consulta de metadados. Para a programação de desativação, consulte Suspensão de uso dos endpoints dos servidores de metadados v0.1 e v1beta1.

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 a federação de identidade da carga de trabalho para o GKE ou a ocultação de metadados.

Deixar os métodos de autenticação do cliente legado desativados

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 no servidor da API Kubernetes. No GKE, os métodos compatíveis são tokens do portador da conta de serviço, tokens OAuth e certificados do cliente x509. 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 OAuth, um certificado x509 exclusivamente gerado ou uma senha estática eram os únicos métodos de autenticação disponíveis, mas agora não são recomendados e devem ser desativados. Esses métodos apresentam uma superfície mais ampla de ataque para comprometimento de cluster e foram desativados por padrão desde a versão 1.12 do GKE. Se você estiver usando métodos de autenticação legados, recomendamos desativá-los. A autenticação com uma senha estática está obsoleta e foi removida desde a versão 1.19 do GKE.

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, consulte Como desativar a autenticação com uma senha estática.

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

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 GKE Enterprise são integrados ao Cloud Logging por padrão e precisam 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 roteados do Cloud Logging para seus próprios sistemas de registro.

Deixar a IU da Web do Kubernetes (painel) desativada

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 doGoogle 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

Sair do ABAC desativado

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.

Por padrão, o ABAC está desativado para clusters criados com o GKE versão 1.8 e posterior. 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 em relação ao 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

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 é ativado por padrão em novos clusters criados nas versões 1.21 e mais recentes do GKE. Para clusters que fazem upgrade para as versões 1.21 e posteriores do GKE, ative o controlador de admissão usando este comando:

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

A seguir