Como aumentar a segurança do cluster

Neste documento, descrevemos como aumentar a segurança dos clusters do GKE em bare metal.

Proteger os contêineres usando o SELinux

É possível proteger seus contêineres ativando o SELinux, que é compatível com o Red Hat Enterprise Linux (RHEL) e o CentOS. Se as máquinas host estiverem executando o RHEL ou o CentOS 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

O modo de computação segura (seccomp) está disponível na versão 1.11 do GKE em bare metal. 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 é ativado por padrão na versão 1.11 do GKE em bare metal. 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 raiz na 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 GKE em bare metal 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 for especificado, terá um valor de 2000. Os valores permitidos para startUIDRangeRootlessContainers são 1000–57000. O valor de startUIDRangeRootlessContainers pode ser alterado apenas durante os upgrades. 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 cluster:

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

O valor de startUIDRangeRootlessContainers precisa ser escolhido de forma que o espaço UID e GID usado pelos contêineres do sistema não se sobreponham àqueles atribuídos às cargas de trabalho do usuário.

Como desativar o modo sem raiz

A partir da versão 1.10 do GKE em bare metal, os contêineres do plano de controle e do sistema do Kubernetes são executados como usuários não raiz por padrão. O GKE em bare metal atribui UIDs e GIDs a esses usuários no intervalo 2.000 a 4.999. No entanto, essa atribuição poderá causar problemas se esses UIDs e GIDs já tiverem sido alocados para processos em execução no seu ambiente.

A partir da versão 1.11 do GKE em bare metal, é possível desativar o modo sem raiz ao fazer 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:

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

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 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. Por exemplo, se você implantar a política NoUpdateServiceAccount no GKE em bare metal, será necessário definir 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 GKE em Bare Metal 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. Para desativar manualmente a porta na versão 1.14, consulte Desativar porta somente leitura do kubelet.

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 Enterprise publica boletins de segurança sobre vulnerabilidades de gravidade alta e crítica.

Estes boletins seguem um esquema de numeração de vulnerabilidade comum do Google Cloud e estão vinculados na página principal de boletins do Google Cloud e nas notas da versão do GKE em bare metal. Use este feed XML para se inscrever em boletins de segurança do GKE em bare metal e produtos relacionados: https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml

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 e patches de segurança 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 GKE em bare metal incorporam melhorias de segurança do Kubernetes que abordam vulnerabilidades de segurança que podem afetar os clusters.

Você é responsável por manter seus clusters do GKE atualizados. A cada versão, leia as notas da versão. Para minimizar os riscos de segurança aos clusters do GKE, planeje a atualização para novas versões de patch a cada mês e versões secundárias a cada três 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.

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