Neste documento, descrevemos como aumentar a segurança dos clusters do GKE em bare metal.
Proteger os contêineres usando o SELinux
Para proteger seus contêineres, ative o SELinux, que é compatível com o Red Hat Enterprise Linux (RHEL). Se as máquinas host estiverem executando o RHEL e você quiser ativar o SELinux para o cluster, ative o SELinux em todas as máquinas host. Consulte Proteger seus contêineres usando o SELinux para mais detalhes.
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 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 para o kernel. Isso reduz a chance de exploração de
vulnerabilidades do kernel.
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 root 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á o valor 2000. Os valores permitidos para startUIDRangeRootlessContainers são de 1000 a 57000. O valor de startUIDRangeRootlessContainers só pode ser alterado durante os upgrades. Os contêineres do sistema usam os UIDs e GIDs no intervalo
startUIDRangeRootlessContainers a startUIDRangeRootlessContainers + 2999.
O exemplo a seguir mostra um trecho de um arquivo de manifesto para um recurso 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 os espaços de UID e GID
usados pelos contêineres do sistema não se sobreponham aos 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
2000-4999. No entanto, essa atribuição poderá causar problemas se esses UIDs e
GIDs já tiverem sido alocados para processos em execução no 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 seguinte seção
clusterSecurityao 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 modificar. 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
10255, a porta somente leitura do kubelet. Todas as cargas de trabalho do cliente configuradas para
ler dados dessa porta não segura do kubelet 10255 precisam migrar para usar a porta
segura do kubelet 10250.
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 do kubelet 10255 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 pela porta 10255, que não está 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 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.
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 os clusters do GKE em Bare Metal atualizados. Para cada versão, consulte as notas da versão. Para minimizar os riscos de segurança dos clusters, atualize para novos lançamentos de patch todos os meses 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 do cluster. 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 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 sua rede com peering à rede de nuvem privada virtual (VPC) por meio de 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.
Para proteger totalmente o GKE em bare metal, use o VIP restrito e adicione 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 sinalização --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.