Aumente a segurança do seu cluster

Neste documento, descrevemos como aumentar a segurança da sua nuvem distribuída do Google. do Google Cloud.

Proteger os contêineres usando o SELinux

Para proteger seus contêineres, ative o SELinux, que tem suporte para Hat Enterprise Linux (RHEL). Se as máquinas host estiverem executando o RHEL e você quiser ativar o SELinux no cluster, ative o SELinux em todas as máquinas host. Para mais detalhes, veja proteger seus contêineres usando o SELinux.

Usar seccomp para restringir contêineres

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

O modo de computação segura (seccomp) está disponível na versão 1.11 do Google Distributed Cloud e versões mais recentes. A execução de contêineres com um perfil seccomp melhora a segurança do cluster, porque restringe as chamadas do sistema que os contêineres podem fazer no kernel. Isso reduz a chance de vulnerabilidades do kernel serem exploradas.

O perfil seccomp padrão contém uma lista de chamadas do sistema que um contêiner pode fazer. Não é permitido fazer chamadas do sistema que não estejam na lista. seccomp está ativado por padrão na versão 1.11 do Google Distributed Cloud. Isso significa que todos os contêineres do sistema e cargas de trabalho do cliente são executados com o perfil seccomp padrão do ambiente de execução do contêiner. Até os contêineres e as cargas de trabalho que não especificam um perfil seccomp nos arquivos de configuração estão sujeitos a restrições seccomp.

Como desativar seccomp em todo o cluster ou em determinadas cargas de trabalho

É possível desativar seccomp durante a criação ou o upgrade do cluster. Não é possível usar bmctl update para desativar este recurso. Se você quiser desativar seccomp em um cluster, adicione a seguinte seção clusterSecurity ao arquivo de configuração do cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: example
  namespace: cluster-example
spec:
...
  clusterSecurity:
    enableSeccomp: false
...

No caso improvável de algumas das suas cargas de trabalho precisarem executar chamadas do sistema que seccomp bloqueia por padrão, não é necessário desativar seccomp em todo o cluster. Em vez disso, é possível separar cargas de trabalho específicas para serem executadas em unconfined mode. A execução de uma carga de trabalho em unconfined mode libera essa carga de trabalho das restrições que o perfil seccomp impõe ao restante do cluster.

Para executar um contêiner em unconfined mode, adicione a seguinte seção securityContext ao manifesto do pod:

apiVersion: v1
kind: Pod
....
spec:
  securityContext:
    seccompProfile:
      type: Unconfined
....

Não execute contêineres como usuário root

Por padrão, os processos em contêineres são executados como root. Isso representa um possível problema de segurança porque, se um processo sair do contêiner, ele será executado como rootna máquina host. Portanto, é aconselhável executar todas as cargas de trabalho como um usuário não raiz.

As seções a seguir descrevem duas maneiras de executar contêineres como um usuário não raiz.

Método 1: adicionar a instrução USER em Dockerfile

Esse método usa um Dockerfile para garantir que os contêineres não sejam executados como um usuário root. Em um Dockerfile, é possível especificar em qual usuário o processo em um contêiner será executado. O snippet a seguir de um Dockerfile mostra como fazer isso:

....

#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot

#Run Container as nonroot
USER nonroot
....

Neste exemplo, o comando useradd -u do Linux cria um usuário chamado nonroot dentro do contêiner. O usuário tem um ID de usuário (UID) 8877.

A próxima linha no Dockerfile executa o comando USER nonroot. Esse comando especifica que, a partir desse ponto, na imagem, os comandos são executados como o usuário nonroot.

Conceda permissões ao UID 8877 para que os processos de contêiner possam ser executados corretamente para nonroot.

Método 2: adicionar campos "securityContext" ao arquivo de manifesto do Kubernetes

Esse método usa um arquivo de manifesto do Kubernetes para garantir que os contêineres não sejam executados como um usuário root. As configurações de segurança são especificadas para um pod e, por sua vez, essas configurações são aplicadas a todos os contêineres dentro do pod.

O exemplo a seguir mostra um trecho de um arquivo de manifesto de um determinado pod:

apiVersion: v1
kind: Pod
metadata:
  name: name-of-pod
spec:
  securityContext:
    runAsUser: 8877
    runAsGroup: 8877
....

O campo runAsUser especifica que, para qualquer contêiner no pod, todos os processos são executados com o ID do usuário 8877. O campo runAsGroup especifica que esses processos têm um ID do grupo principal (GID) de 8877. Lembre-se de conceder as permissões necessárias e suficientes para o UID 8877 para que os processos de contêiner possam ser executados corretamente.

Isso garante que os processos dentro de um contêiner sejam executados como UID 8877, que tem menos privilégios que a raiz.

Os contêineres do sistema no Google Distributed Cloud ajudam a instalar e gerenciar clusters. Os UIDs e GIDs usados por esses contêineres podem ser controlados pelo campo startUIDRangeRootlessContainers na especificação do cluster. O startUIDRangeRootlessContainers é um campo opcional que, se não especificado, tem o valor 2000. Os valores permitidos para startUIDRangeRootlessContainers são 1000 a 57000 O valor startUIDRangeRootlessContainers pode ser alterado. durante upgrades apenas. Os contêineres do sistema usarão os UIDs e os GIDs no intervalo startUIDRangeRootlessContainers–startUIDRangeRootlessContainers + 2999.

O exemplo a seguir mostra um trecho de um arquivo de manifesto para um recurso do cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: name-of-cluster
spec:
 clusterSecurity:
    startUIDRangeRootlessContainers: 5000
...

Escolha o valor de startUIDRangeRootlessContainers para que o UID e o GID os espaços usados pelos contêineres do sistema não se sobrepõem aos atribuídos ao usuário cargas de trabalho.

Como desativar o modo sem raiz

A partir da versão 1.10 do Google Distributed Cloud, o plano de controle do Kubernetes os contêineres e os contêineres do sistema são executados como usuários não raiz por padrão. O Google Distributed Cloud atribui UIDs e GIDs a esses usuários no intervalo De 2000 a 4999. No entanto, essa atribuição pode causar problemas se esses UIDs e Os GIDs já foram alocados para processos em execução no seu ambiente.

A partir da versão 1.11 do Google Distributed Cloud, é possível desativar o acesso quando você fizer upgrade do cluster. Quando o modo sem raiz está desativado, os contêineres do plano de controle e do sistema do Kubernetes são executados como o usuário raiz.

Para desativar o modo sem raiz, siga estas etapas:

1. Adicione a seção clusterSecurity a seguir ao arquivo de configuração do cluster:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: example
     namespace: cluster-example
   spec:
   ...
     clusterSecurity:
       enableRootlessContainers: false
   ...
   

2. Fazer upgrade do cluster. Para detalhes, consulte Fazer upgrade de clusters.

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 modificar em primeiro lugar. 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. Por exemplo, se você implantar a política NoUpdateServiceAccount em Google Distributed Cloud, defina os seguintes parâmetros no Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers: []

Desativar porta somente leitura do Kubelet

A partir da versão 1.15.0, o Google Distributed Cloud desativa por padrão a porta 10255, a porta somente leitura do kubelet. Todas as cargas de trabalho do cliente configuradas para ler dados dessa porta 10255 não segura do Kubelet precisam migrar para usar a porta 10250 do Kubelet segura.

Somente os clusters criados com a versão 1.15.0 ou posterior têm essa porta desativada por padrão. A porta somente leitura 10255 do Kubelet permanece acessível para clusters criados com uma versão anterior à 1.15.0, mesmo após um upgrade do cluster para a versão 1.15.0 ou mais recente.

Essa alteração foi feita porque o Kubelet vaza informações de baixa confidencialidade na porta 10255, que não é autenticada, incluindo todas as informações de configuração de todos os pods em execução em um nó, o que pode ser valioso para um invasor. Além disso, expõe métricas e informações de status, que podem fornecer insights sensíveis para os negócios.

A desativação da porta somente leitura do kubelet é recomendada pelo comparativo de mercado CIS do Kubernetes.

Manutenção

O monitoramento de boletins de segurança e o upgrade dos clusters são medidas importantes de segurança depois que os clusters estiverem funcionando.

Monitorar boletins de segurança

A equipe de segurança do GKE publica boletins de segurança para vulnerabilidades de gravidade alta e crítica.

Esses boletins seguem a numeração de vulnerabilidades comuns e estão vinculados à página principal de boletins do Google Cloud e ao Notas de lançamento do Google Distributed Cloud.

Use este feed XML para se inscrever para receber boletins de segurança do Google Distributed Cloud e de produtos relacionados.

Quando a ação do cliente for necessária para resolver essas vulnerabilidades desse tipo, o Google entrará em contato com os clientes por e-mail. Além disso, o Google também pode entrar em contato com os clientes com contratos de suporte pelos canais de suporte.

Para mais informações sobre como o Google gerencia vulnerabilidades de segurança e para o GKE e o GKE Enterprise, consulte Patch de segurança:

Fazer upgrade de clusters

O Kubernetes apresenta frequentemente novos recursos de segurança e fornece patches de segurança. As versões do Google Distributed Cloud incorporam a segurança do Kubernetes melhorias que resolvem vulnerabilidades de segurança que podem afetar seus clusters.

Você é responsável por manter seus clusters do Google Distributed Cloud atualizados. Para cada versão, leia as notas da versão. Para minimizar os riscos de segurança aos clusters, planeje a atualização para novas versões de patch a cada mês e versões secundárias a cada quatro meses.

Uma das muitas vantagens de fazer upgrade de um cluster é que ele atualiza automaticamente o arquivo kubeconfig dele. O arquivo kubeconfig autentica um usuário em um cluster. O arquivo kubeconfig é adicionado ao diretório do cluster quando você cria um cluster com bmctl. O nome e o caminho padrão são bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig. Quando você faz o upgrade de um cluster, o arquivo kubeconfig dele é renovado automaticamente. Caso contrário, o arquivo kubeconfig expira um ano após a criação.

Observação: apenas o arquivo kubeconfig do cluster atualizado está sendo renovado. Se, por exemplo, você fizer upgrade de um cluster de administrador que gerencie três clusters de usuário, apenas o arquivo kubeconfig do cluster de administrador será atualizado. É necessário fazer upgrade de cada um dos clusters de usuário separadamente para atualizar os respectivos arquivos kubeconfig.

Para informações sobre como fazer upgrade dos clusters, consulte Fazer upgrade dos clusters.

Usar o VPC Service Controls com o Cloud Interconnect ou o Cloud VPN

O Cloud Interconnect fornece conexões de baixa latência e alta disponibilidade que permitem transferir dados de maneira confiável entre máquinas bare metal locais e redes de nuvem privada virtual (VPC, na sigla em inglês) do Google Cloud. Para saber mais sobre o Cloud Interconnect, consulte Informações gerais do provisionamento da Interconexão dedicada.

O Cloud VPN conecta com segurança uma rede de peering a uma rede de nuvem privada virtual (VPC) usando uma conexão IPsec VPN. Para saber mais sobre o Cloud VPN, consulte VInformações gerais do Cloud VPN.

O VPC Service Controls funciona com o Cloud Interconnect ou o Cloud VPN para fornecer mais segurança aos clusters. O VPC Service Controls ajuda a reduzir o risco de exfiltração de dados. Ao usá-lo, é possível adicionar projetos a perímetros de serviço. Isso protege recursos e serviços contra solicitações que vêm de fora desses perímetros. Para saber mais sobre perímetros de serviço, consulte Detalhes e configuração do perímetro de serviço.

Cuidado: o VPC Service Controls não é compatível com o proxy do cluster do Terraform. Se você usar o VPC Service Controls, não especifique Configurações do proxy na especificações do cluster.

Para proteger totalmente o Google Distributed Cloud, você precisa usar o VIP restrito e adicionar as seguintes APIs ao perímetro de serviço:

• API Artifact Registry (artifactregistry.googleapis.com)
• API Resource Manager (cloudresourcemanager.googleapis.com)
• API Compute Engine (compute.googleapis.com)
• API Connect Gateway (connectgateway.googleapis.com)
• API Google Container Registry (containerregistry.googleapis.com)
• API GKE Connect (gkeconnect.googleapis.com)
• API GKE Hub (gkehub.googleapis.com)
• API GKE On-Prem (gkeonprem.googleapis.com)
• API Identity and Access Manager (IAM) (iam.googleapis.com)
• API Cloud Logging (logging.googleapis.com)
• API Cloud Monitoring (monitoring.googleapis.com)
• API Config Monitoring for Ops (opsconfigmonitoring.googleapis.com)
• API Service Control (servicecontrol.googleapis.com)
• API Cloud Storage (storage.googleapis.com)

Ao usar bmctl para criar ou fazer upgrade de um cluster, use a flag --skip-api-check para ignorar a chamada da API Service Usage (serviceusage.googleapis.com). A API Service Usage não é compatível com o VPC Service Controls.

Observação: não é possível criar ou fazer upgrade de um cluster no console do Google Cloud quando o VPC Service Controls está ativado. A operação falha porque o comando bmctl register bootstrap não tem a flag --skip-api-check. Se você usar o VPC Service Controls, utilize bmctl create cluster para criar clusters ou bmctl upgrade cluster para fazer upgrade de clusters.